devopsy.kinsta.cloud

Category: DevSecOps

  • Google Makes Fuzz Testing Integration Tool Available

    Google Makes Fuzz Testing Integration Tool Available

    Google today made available a ClusterFuzzLite tool that makes it simpler to incorporate fuzz testing into a DevOps workflow.

    Fuzz testing refers to an automated software testing technique that involves providing invalid, unexpected or random data as inputs to an application to discover issues such as potential memory leaks.

    Jonathan Metzman, a senior software engineer for Google, said ClusterFuzzLite is a lighter-weight version of a tool that Google makes available to its internal development teams. It is not a fuzz testing tool itself, but rather a tool that makes it easier to surface the results of a fuzz test within a DevOps workflow. Once those results are surfaced, it then becomes easier for developers to address issues before an application is deployed in a production environment.

    Core capabilities enabled by ClusterFuzzLite include continuous fuzzing, sanitizer support, corpus management and report generation tools. The goal is to make fuzz testing more accessible to a broader range of developers as part of an overall effort to embrace DevSecOps best practices, noted Metzman.

    ClusterFuzzLite currently supports GitHub Actions and Google Cloud Build, but Metzman said it is easily extensible to other DevOps platforms. It is designed to run as part of a DevOps workflow by adding a few lines of code to a continuous integration/continuous delivery (CI/CD) workflow.

    Google has already made ClusterFuzzLite available to open source projects, but is now providing additional access for commercial developers. Since its release in 2016, over 500 critical open source projects have integrated into the Google fuzz testing program for open source software, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed.

    In the wake of recent guidelines issued by the U.S. National Institute of Standards and Technology (NIST) that were themselves in response to an executive order issued by president Biden, the number of organizations using fuzz testing is expected to increase now that NIST has determined that fuzz testing is a minimum standard requirement for code verification.

    For several years, Google has been making a concerted effort to improve the security of open source software. The challenge for all developers is finding a way to build more secure applications without slowing down the rate at which they are deployed. Fuzz testing makes it possible to identify issues much earlier in the application development life cycle versus just before an application is deployed.

    Less clear, of course, is whether developers are starting to use these tools on their own or if the increased adoption is because of a concerted effort by their organization to embrace DevSecOps best practices. Regardless of the motivation, however, the overall state of application security should continue to improve as it becomes simpler for developers to invoke more advanced testing tools.

    In the meantime, organizations of all sizes are reviewing how they construct software in the wake of a series of high-profile security breaches. In theory, at least, increased focus on software supply chains should prevent issues from arising after deployment when they become much more costly to remediate.

  • Akamai Brings Web Application and API Security Together

    Akamai Brings Web Application and API Security Together

    Akamai Technologies, Inc. this week launched a service that consolidates the process of securing both web applications and application programming interfaces (APIs).

    Amol Mathur, vice president of product management and strategy for Akamai, said with the launch of App & API Protector the managed security services provider is making it easier for IT teams to embrace DevSecOps best practices via a converged web application and API (WAAP) service rather than using separate tools and services to secure them individually.

    The service is also designed to continuously discover API requests that are then automatically inspected for malicious code. Optional API security controls can be enforced based on policies defined by internal IT teams.

    In addition, the company provides access to a multidimensional threat scoring model, dubbed Adaptive, that combines data collected by Akamai with data and metadata from each web and API request to help organizations better understand which threats require immediate attention. Security events are also continuously analyzed using machine learning algorithms to deliver highly accurate policy-by-policy tuning recommendations that can be implemented via a single click.

    Akamai security researchers also make use of machine learning and data mining techniques to continuously analyze over 303TB of daily attack data that is used to automatically update protections. Alternatively, organizations can opt to manually evaluate that data themselves to minimize any unexpected impacts those updates might have on their applications.

    Other capabilities include built-in bot mitigation tools that are informed by a directory of more than 1,500 known bots, integrations with the Akamai command-line interface (CLI), Terraform or scripts used to drive automated pipelines spanning a continuous integration/continuous delivery (CI/CD) platform.

    Akamai

    A recent report published by Akamai found that between January 2020 and June 2021 there were more than 11 billion total attempted attacks made over an 18-month period. The most common attack vector was SQL injection (SQLi) at 6 billion attacks, followed by local file inclusion (LFI) with 3.3 billion attacks and cross-site scripting (XSS) with 1.019 billion attacks.

    The report also found credential stuffing attacks reached more than one billion attacks and peaked between January 2021 and May 2021. Distributed denial-of-service (DDoS) attacks reached a peak of 90 in January of 2021.

    Akamai has been making a case for outsourcing the management of web application and API security via the content delivery network (CDN) it created. Its CDN provides a layer of isolation between web-facing applications and the rest of the enterprise. The challenge organizations now routinely face is that, as they move to deploy cloud-native applications based on microservices, responsibility for security has become more decentralized. The security services provided by Akamai create an opportunity to better manage application security via a single pane of glass at a time when there is more focus than ever on securing software supply chains, said Mathur.

    It’s not clear to what degree organizations are going to rely more on managed security services as part of a larger effort to embrace DevSecOps best practices. However, at a time when application security expertise is hard to come by, it’s becoming apparent that, in many instances, relying on an external service provider to secure application environments is the simplest way to quickly improve the overall security posture of any organization.

  • Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem Adds Runtime Protection Enabled by Observability

    Data Theorem, Inc. this week added an Active Protection offering to its portfolio of application security services that makes it possible for DevOps teams to embed observability and runtime defenses in their applications via a software development kit (SDK).

    The Data Theorem cloud services are based on Trustkit, an open source framework the company created to make it easier to employ secure socket layer (SSL) to encrypt connections and Analyzer Engine, its runtime analytics engine.

    The company is now extending its services to make it possible to embed observability capabilities by collecting logs and traces. Those logs and traces are then used to enforce runtime security policies that protect applications from known attacks from malicious sources and other common attack vectors as defined by the Open Web Application Security Project (OWASP) Foundation. It also prevents violations of encryption levels, authentication types and authorization rules along with a variety of custom rule checks, including preventing broken object-level authorization (BOLA) attacks.

    Doug Dooley, Data Theorem COO, said Active Protection can be applied across any application stack, including microservices applications based on cloud-native frameworks. In contrast, existing approaches to securing application runtimes based on web application firewalls (WAFs), runtime application self-protection (RASPs) or endpoint detection and response (EDR) agents cannot be applied to cloud-native applications based on containers and serverless computing frameworks.

    Active Protection solves that issue because it is designed to be applied via the Data Theorem software development kit (SDK) or using application extensions made available via a serverless computing framework or as a container sidecar.

    Dooley noted that the Active Protection service is also designed to be fully integrated with DevSecOps workflows that are increasingly being driven via continuous integration/continuous delivery (CI/CD) platforms to enable continuous, automated security inspection and remediation. The company claims to have detected more than one billion application incidents and is currently used by more than 8,000 applications.

    Developers don’t generally set out to build and deploy insecure applications. The issue is most developers don’t have a lot of security expertise, so it’s easy for mistakes to be made. Organizations looking to embrace DevSecOps best practices need to find a way to achieve that goal in a way that developers can easily embrace. The more automated the checks for security issues become during the application development process, the more likely it is developers will make additional efforts to remediate vulnerabilities long before an application is ever deployed in a production environment. In effect, DevSecOps is easier to achieve when addressed from the bottom up rather than via an edict from above without any real implementation plan in place.

    It’s still early days as far as DevSecOps is concerned, but as best practices for DevOps continue to evolve, there may come a day when security is just another gate that needs to be passed within the context of a larger DevOps workflow. In the meantime, DevOps teams and cybersecurity teams should put aside their differences and work together as the number of attacks launched against applications increases.

  • Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace today added a security gates capability to its observability platform to make it easier to automatically embrace DevSecOps best practices within an application delivery pipeline.

    Steve Tack, senior vice president for product management at Dynatrace, said the security gates function much the same as the quality gates that Dynatrace previously added to that platform in that each release is now also automatically assessed to ensure only secure code is being deployed.

    The Dynatrace platform now uses a Davis artificial intelligence (AI) engine to scan for vulnerabilities in application workloads in real-time and then prioritizes them based on the risk they pose, noted Tack. The goal is to make it simpler for organizations to incorporate security reviews in application development processes in a way that doesn’t necessarily require developers to become security experts, he added.

    Instead, the core DevOps platforms should be capable of identifying issues that can be remediated before an application is ever deployed in a production environment, said Tack.

    Dynatrace earlier added an ability to automatically identify the software libraries and open source packages that present the greatest security risk. The security gates capability now extends the scope of that effort to include applications as they are constructed using custom code.

    In general, most organizations are looking for ways to embrace DevSecOps best practices. The challenge is achieving that goal without unduly slowing down the rate at which applications are developed. In fact, a recent survey commissioned by Dynatrace found, on average, organizations expect to increase the frequency of their software releases by 58% over the next two years. However, nearly a quarter (22%) of respondents admit they’re often under so much pressure to meet the demand for application deployments that they must sacrifice code quality, which broadly includes security issues.

    It’s not clear to what degree security reviews will automatically be included within a quality assurance process, but Tack said the goal should be to limit human involvement in the application deployment process as much as possible. The issue many development teams encounter today is that applications are being rejected by cybersecurity teams that are reviewing applications just before they are deployed, noted Tack. As a result, developers are racing to build applications faster only to see them rejected and returned to them at the last possible moment, he added.

    In the wake of a series of high-profile software supply chain breaches, the focus on DevSecOps has increased substantially within most organizations. It’s often not precisely clear who is responsible for application security, but as DevOps platforms continue to evolve, there may come a day when security issues are routinely addressed within every DevOps workflow.

    In the meantime, there needs to be a lot more focus on bridging the divide between DevOps and security teams. Given the chronic shortage of security professionals, there’s no doubt DevOps teams need to assume more responsibility for application security. The challenge and the opportunity is finding a way to achieve that goal with the least amount of friction possible.

  • Oxeye Platform Helps Fix Code Vulnerabilities

    Oxeye Platform Helps Fix Code Vulnerabilities

    Fresh from raising $5.3 million in seed funding, Oxeye emerged this week from stealth to launch a namesake application security testing platform that, in addition to pinpointing issues in code, also provides advice to best remediate the issues it found.

    The Oxeye platform requires developers to download an observer tool that scans code for vulnerabilities. Once pinpointed, the Oxeye platform guides developers through the remediation process without requiring them to inject agent software into every application.

    Oxeye CEO Dean Agron noted developers don’t typically have a lot of cybersecurity expertise. As application environments become more complex—thanks to the rise of microservices-based applications—it only becomes more likely that mistakes will be made. The only way to resolve security issues before applications are deployed in a production environment is to augment developers using a platform that finds vulnerabilities all the way down to specific lines of code, he said.

    In theory, responsibility for application security is being pushed further left toward developers as organizations embrace DevSecOps best practices. However, making developers more accountable for security without providing them the tools required to achieve that goal is not going to improve the overall state of application security.

    The challenge organizations face today is finding a way to empower developers to address security issues without slowing down the rate at which applications are built and deployed. The best way to achieve that goal is to give developers access to a security tool designed to both analyze code for vulnerabilities and explain how to avoid encountering that issue again, said Agron.

    Left unaddressed, the current software supply chain crises will only deepen, added Agron. According to International Data Corp. (IDC), more than 500 million digital applications and services will be developed and deployed using cloud-native platforms by 2023. That’s roughly equal to the total number of applications and services deployed over the last 40 years, according to IDC.

    It’s not clear to what degree the rise of digital applications might force the DevSecOps issue within more organizations. It’s is clear that a new generation of more complex applications based on microservices is being rolled out to drive a wide range of mission-critical applications. The more business value an application has the more attention it inevitably attracts from cybercriminals.

    Regardless of the type of application, it’s apparent that there is a pressing need for a way to better secure applications. The further left that process starts the less costly it becomes to achieve and maintain security. Cybersecurity teams have a vested interest in helping developers do the right security thing as early as possible if no other reason than to reduce the number of vulnerabilities they will inevitably discover later.

    Making developers more aware of security issues is, of course, only the first step. However, in the absence of any tools that can be easily incorporated within an application development workflow, the concerns being raised will amount to little more than yet another sermon that will be ignored as developers once again rush to meet yet another application delivery deadline.

  • DevSecOps Progress: Slow and Steady

    DevSecOps Progress: Slow and Steady

    [pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/02/devsecops-progress-slow-and-steady.pdf”]

  • DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    The DevSecOps Technology Radar showcases the opinions cloud-native groups have about DevSecOps tools. To review, The Technology Radar is a periodic report from the Cloud Native Computing Foundation (CNCF), a burgeoning host for new open source projects that are becoming pivotal underpinnings to cloud-native architecture at large.

    Just like previous radars, the DevSecOps Technology Radar was assembled using feedback from the CNCF end-user community, which is a group of over 155 organizations that use cloud-native technologies to build and distribute their services, spanning startups and enterprises. The Radar report organizes popular tools into adopt, trial and/or assess status, based on a technology’s active use and its maturity.

    ‘Adopt’ means these tools are stable and come highly recommended for use in production systems.

    ‘Trial’ means users have had some success with these tools, and it is recommended that others consider them.

    ‘Assess’ means these are promising tools that are good for solving specific needs.

    So, why was DevSecOps selected as this Radar’s theme? According to the Radar team, DevSecOps was chosen because it is highly relevant to current development focuses. “We realized that more than half of the tools we were using in CI/CD were actually security-oriented,” said Sergiu Petean, head of DevOps at Allianz Direct. This goes beyond DevOps—”this is definitely an uppercase ‘Sec’,” he said.

    “More than half of our time is spent discussing designs around security,” said Keith Nielsen, director, cloud architecture at Discover Financial Services. Financial services especially must find innovative methods to balance speed-to-market with security. Nielsen also cited the rapid rate of change in this space, which requires companies to continually reevaluate their security posture.

    DevSecOps Radar Results

    So, where did the CNCF end-user community place popular DevSecOps tools? The Radar ended up rating 16 tools across the three different levels:

    • Adopt: Istio, Sonarqube, Artifactory, Hashicorp Vault, Calico/Tigera, Terraform, ArgoCD and OPA.
    • Trial: XRay.
    • Assess: Cilium, Harness, SonaType Nexus, Hashicorp Sentinel, GitHub Actions, Linkerd and Trivy.

    The above results were based on 252 votes from end users across 35 tools, with most respondents coming from large companies across multiple sectors.

    Out of these tools, Terraform collected the highest number of ‘Adopt’ votes. This technology aids the move toward infrastructure-as-code (IaC) with declarative configuration files, which is important for DevSecOps automation. Tied for second place were Hashicorp Vault and Artifactory, indicating that secrets management, access control and continuous updates for security are pressing requirements.

    Other open source tools on the Radar are providing impressive ways to unify security controls. For example, OPA is a universal layer for applying policies that could help unite fragmented authorization across applications. Or, service mesh options like Linkerd and Istio place a sidecar proxy around applications to centrally manage access control, observability and networking across a large microservices ecosystem. Such projects are programmable to fit into the DevSecOps pipeline.

    Analysis

    In general, the radar team was somewhat surprised to see such a high number of security tools in use today. Some tools compete in the same arena, making hunting for the right tool challenging. “The sheer number of products is a bit staggering … what we’re seeing is a highly fractured strategy from different companies,” explained Nielsen, who said he expected more consolidation on capabilities.

    After evaluating the DevSecOps tooling landscape, The Radar team organized their core findings into three main takeaways:

    Usability is compromised at the expense of security. Security features are necessary, but they often come at the cost of usability. The DevSecOps Radar team found that the developer experience for most tools is poor. Many disparate tools must be stitched together to have a truly automated pipeline which is cumbersome to implement. “The tools are getting better, but still there’s not a cohesive, prescriptive way to develop for the cloud,” said Nielsen.

    The pace of change in the security space is rapid. Major cloud providers continue to rapidly release new services, which has led to an explosion in new tools. Simultaneously, the speed of innovation is accelerating within companies, opening up unique security needs. Combined, this means the security landscape is constantly shifting. “Security tools are trying to keep up with the services and how you host them and run them,” Nielsen said. “We definitely weren’t expecting to see so many newcomers in the security space,” Petean agreed. Though DevSecOps is spoiled for choice these days, “it’s always better to have options,” he added.

    Microsegmentation is important but presents a significant challenge. Many great tools enable companies to improve how they segment traffic, such as service mesh tools like Linkerd and Istio. However, implementing cloud-native microsegmentation is bumping against legacy implementations for established companies. Between API gateways, service mesh, edge firewalls and Kubernetes federated firewall functions, DevSecOps has much complexity to deal with, Nielsen said.

    The DevSecOps Technology Radar: In Review

    In recent years, cloud-native technology has placed increasing emphasis on solving the security puzzle. Companies continue to reevaluate their security approach in light of cloud-native strategies, novel vulnerabilities and new compliance requirements. DevSecOps is proving to be a useful, if not necessary, practice to maintain both security and rapid software delivery.

    With new security tools and unique approaches coming out so frequently, it’s easy to have “analysis paralysis.” However, DevSecOps must start somewhere. And, for those who trust the opinions of the CNCF Technology Radar, you now have some helpful insights on where to begin.

  • Securing Your Software Development Pipelines

    Securing Your Software Development Pipelines

    Earlier this year, it was announced that the attack on IT management software provider SolarWinds had been used to compromise other organizations, including parts of the United States government. There were several reasons for alarm because of this news, but one of the biggest was the revelation that attackers breached SolarWinds’ software development process and pipeline. The level of concern was such that it led to a first-of-its-kind executive order on cybersecurity.

    The security of the software development process has been a concern for development teams for decades, beginning with Ken Thompson’s thought experiment around hacking compilers to inject vulnerable code (PDF). As the software development process becomes increasingly automated, this means there is more to secure. Indeed, the biggest difference between Thompson’s “Reflections on Trusting Trust” and today is that much of our concern stems from just how much we, as development teams, must trust code that was not written by us.

    The issue of code ‘not written here’ is bigger than just open source libraries – though those are a big part of the issue since a typical Java application is 97% third-party code by weight, according to the Veracode State of Software Security, 2020. Moreover, modern cloud-native applications are also comprised of additional types of code written by others, including container images, serverless code and other cloud-native artifacts.

    As a result, an attacker could compromise a development pipeline by one of a variety of means:

    • Poisoning an upstream open source repository by taking over an open source project, or by typosquatting
    • Compromising a container image repository
    • Gaining access to the continuous integration server and making changes in the pipeline to incorporate malicious code
    • Gaining access to the source repository, identifying an existing vulnerability (zero-day) in an application, and exploiting it in production

    So, what must be done to mitigate these threats? A lot of the answer comes down to testing, managing the chain of custody and monitoring access to internal resources.

    • Managing access—Systems that touch your software development process provide a door that, if not properly secured, may allow an attacker to walk in and compromise the software you ship to your customers. Things to be aware of here include the source control system, the continuous integration server and other tools (including quality and security tools) that have access to the source repository. Similarly, any activity that touches the source code, especially commits to the source code repository, must be properly authenticated with a developer GPG key. This prevents spoofing a user’s identity by setting git configuration parameters (this blog post from Alessandro Segala describes the problem nicely) or by stealing credentials.
    • Manage the chain of custody for software dependencies—Most modern software dependency managers allow connections to multiple software registries, including public registries that can be easily attacked or compromised. Configuring dependency managers to only allow connections to an authorized list of registries can help keep compromised packages from entering the build pipeline. This can also help to ensure that only dependencies that are free of critical and high vulnerabilities can be used in the application. This topic also relates to the next one on testing for vulnerabilities. Part of managing code coming from other parts of the software supply chain is looking for security vulnerabilities in the code. Consider a security scanning tool that can look for vulnerable open source libraries or container images with vulnerabilities and security misconfigurations.
    • Testing for vulnerabilities —Code introduced by an attacker may introduce new vulnerabilities. Using static application security testing (SAST) can help to identify serious security issues, including poor cryptographic practices, hard-coded credentials, and injection vulnerabilities. Performing SAST in the pipeline allows for the identification of critical and high severity defects early, enabling you to fail a pipeline upon their discovery and preventing insecure code from being deployed into production. Likewise, as noted above, testing for vulnerable containers and open source libraries can prevent vulnerabilities from being introduced via the software supply chain. Finally, using dynamic application security testing (DAST) to perform an end-to-end runtime test for a web application in a pre-production environment can help identify other exploitable issues in the end-to-end application. It can also find problems with application configuration that are only observable in the deployed environment. Both SAST and SCA might identify weaknesses in software that, while indicative of poor coding processes, may not be vulnerabilities. So, selecting tools that allow you to set a baseline of acceptable findings can help to ensure this control is adopted successfully.

    Solving all these problems requires thinking about different parts of the application development process as a complete system. To that end, Veracode collaborated with Venafi, Sophos and CloudBees earlier this year to put together a proposed blueprint for secure software development pipelines. The proposal is maintained on GitHub and is available for users to raise issues or propose pull requests on the blueprint—all input is welcome.

    The importance of getting this right cannot be underestimated. Hacks and breaches continue to hit the headlines, and putting in place the right tools, technologies and processes to minimize security risk in the software development pipeline is more critical than ever. 

  • Sysdig Adds Cloud Access Controls to DevSecOps Platform

    Sysdig Adds Cloud Access Controls to DevSecOps Platform

    Sysdig announced today that it is adding a Cloud Infrastructure Entitlements Management (CIEM) capability to its Secure DevOps platform as part of an effort to better enforce least-privilege access within the context of a larger zero-trust approach to cybersecurity.

    Nick Fisher, vice president of product marketing for Sysdig, said this addition to the company’s core DevSecOps platform for securing cloud services will prevent organizations from inadvertently providing individuals with excessive permissions that result in cybercriminals gaining widespread access to applications and systems when the credentials those individuals have are compromised.

    A recent report from the Sysdig Threat Team found that nearly 80% of users have excessive entitlements due to overly permissive policies. Similarly, Gartner forecasted that 75% of security failures will result from inadequate management of identities, access and privileges by 2023, up from 50% last year.

    The CIEM offering from Sysdig enables cybersecurity and IT operations teams to resolve that issue across multiple clouds in under two minutes once installed, said Fisher. The Sysdig platform achieves that goal by making it possible to leverage templates as a set of infrastructure-as-code (IaC) tools that enable DevOps teams to integrate security within their existing workflows.

    CIEM also simplifies access control auditing by making it easier to discover who in the organization has permission to access cloud infrastructure services. As part of that capability, Sysdig also provides out-of-the-box compliance policies and access to reports that can be generated on-demand to surface a detailed audit trail of all cloud permission changes.

    Finally, CIEM will generate an alert any time someone is denied permission to access a cloud resource, noted Fisher. That capability provides cybersecurity teams with an opportunity to then review what permissions might need to be granted or whether a bad actor is attempting to compromise a cloud environment.

    Most of the cloud security issues that organizations encounter can be traced back to developers that have misconfigured one cloud resource in a way that allows cybercriminals to access, for example, a port that has been left open. CIEM extends the Sysdig platform so that, in addition to scanning for vulnerabilities and misconfigurations, it can detect and respond to attacks across containers and virtual machines deployed in a cloud environment.

    Thanks, in part, to recent high-profile breaches of software supply chains, there’s a lot more focus on cloud security as the rate at which applications are being deployed on these platforms steadily increases. While the cloud platforms themselves are fundamentally secure, the challenge most organizations are encountering is they have immature processes in place for securing the workloads running in the cloud.

    Of course, being able to limit access to those cloud resources is only the first step toward implementing a set of DevSecOps best practices to ensure the integrity of the cloud platforms being employed. Unfortunately, too many developers still tend to assume the cloud service provider is taking steps to secure workloads on their behalf. In reality, cloud service providers have adopted a shared responsibility model that, from their perspective, limits their cybersecurity responsibility to the core infrastructure they provide. It’s up to the DevOps team responsible for the workloads running on those platforms to figure out how to secure the rest of that IT environment.

  • Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary today unfurled a free notarization and verification service for open source artifacts and containers to enable IT organizations to track the provenance of the components that make up their applications.

    Dennis Zimmer, Codenotary CTO, said the Community Attestation Service is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. Additionally, the Community Attestation Service can be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams employ to build and deploy applications using those artifacts, added Zimmer.

    The identities created by the Community Attestation Service can then be used to verify a software bill of materials (SBOM) that will soon be required by not only every U.S. federal agency but also organizations that are trying to better secure their software supply chains in the wake of a series of high-profile breaches, said Zimmer. The Community Attestation Service will also encourage developers to reuse source code, builds, repositories and Docker container images that they know they can reliably employ within a zero-trust IT environment, noted Zimmer.

    Some developers have, of course, been signing their code for years, while others simply didn’t see the need. With its free service, Codenotary is trying to expand the pool of developers that will not only sign their code but do so in a way that can’t be tampered with later, noted Zimmer.

    Unlike blockchain databases that are employed to provide immutable records of transactions, Zimmer said the immudb platform was created to provide an immutable database capable of processing millions of transactions per second. That database is also being used to build a wide range of applications that go beyond the scope of the Community Attestation Service so DevOps teams can have confidence in the viability of the underlying platform, noted Zimmer.

    In the wake of some troubling security breaches, it’s now only a matter of time before security teams start to ask more difficult questions about how applications are built. Developers could wait for those cybersecurity teams to eventually create policies that DevOps teams would be required to enforce, or they can more proactively embrace a service that tracks the provenance of code that hopefully, has been scanned for all known vulnerabilities. In fact, it may not be too long before organizations decide not to employ code that has not been verified. There may even be a backlash against using code that is unsigned that could result in many existing applications either being updated or outright replaced.

    On the plus side, Zimmer noted there’s a lot more awareness of the need to sign code. The challenge is most organizations don’t have the processes in place. Fortunately, there’s a lot more interest in DevSecOps best practices to ensure the integrity of code. However, awareness of the need for something doesn’t always result in concrete actions being taken unless DevOps teams can simply make it easy for developers to do the right thing. After all, it’s not as though developers want to employ insecure code, it’s just that they are often simply too busy to make sure every last artifact employed is verified as secure.