devopsy.kinsta.cloud

Tag: Codenotary

Codenotary Previews AI Platform to Autonomously Detect and Remediate IT Issues

Codenotary is previewing a software-as–a-service (SaaS) platform that enables artificial intelligence (AI) agents it has developed to autonomously detect, prioritize, and fix security, configuration, and performance issues.

Company CEO Moshe Bar said the Codenotary Trust platform also enables continuous vulnerability tracking at both the Linux operating system and application level. Once an issue is detected, AI agents will automatically address security, configuration, and optimization issues without any manual intervention required, he added.

In the event the updates applied create another issue, Codenotary Trust also provides an automated rollback capability that restores the IT environment to its previous state, he added.

In general, DevOps teams are moving away from needing to review every patch before it is applied to apply them automatically to resolve issues as fast as possible, said Bar. That shift is becoming more feasible because AI coding tools have reduced the time required to not just create a patch but also test it before being automatically applied, he added. Anytime a patch creates an issue it can now be replaced in a matter of minutes, noted Bar.

Scheduled to be made generally available in the second quarter, pilot users of Codenotary Trust are already reporting an 80% reduction in manual security remediation time while at the same time seeing significant improvements in compliance audit pass rates.

Designed to be installed in minutes without any configuration wizards being required, the Codenotary Trust platform continuously analyzes system behavior to detect inefficiencies, including compliance issues using benchmarks created by the Center for Internet Security (CIS) without having to deploy external scanners.

The overall goal is to make automation accessible to application developers, software engineers and IT administrators of almost any skill level, said Bar. That’s critical because even in the age of AI there is still a critical shortage of IT expertise, he added.

Auto remediation has for decades been an aspirational goal for many IT teams but there has always been a reluctance to apply patches without thoroughly testing them for months. The concern has always been that the “cure” might be worse than the disease if the patch winds up taking an application offline.

The issue that approach creates is that a known vulnerability might not be remediated for months, which then provides malicious actors with plenty of time to develop the exploit needed to launch a cyberattack. However, as cyberattacks become more costly many organizations are concluding that the risks associated with not patching as quickly as possible might be greater than any disruption to application availability that might ensue.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said legacy scan-and-fix-later solutions are increasing under pressure from AI that solves problems at the source. Autonomous remediation shifts security from a review process to an execution loop, he added.

Codenotary Trust signals that the constraint holding back automated patching was never technical; it was trust: trust that the fix would not break something else. Rollback capability addresses that constraint directly, which changes the calculus for teams still running manual review cycles, noted Ashley.

The operational consequences are significant as autonomous agents, self-healing pipelines, and AI-driven remediation gain footholds in IT workflows. Known vulnerabilities sitting unpatched for months because teams fear regression are the attack surface malicious actors depend on, said Ashley. That loop is finally tightening, he added.

In fact, the ability to fix a patch in a matter of minutes might mean organizations are finally ready to embrace auto remediation.

March 4, 2026
Codenotary’s Free SBOM Service Tackles the AI Software Supply Chain
Just because AI is writing your code doesn’t mean you can stop worrying about software bills of materials.

While the quality of AI coding remains open to debate, there’s no question that everyone and their dog is using it. That means, if you’re serious about using AI in production, you must track its code in a Software Bill of Materials (SBOM). Don’t believe me? Just try to sell your program in the European Union (EU) now that the Cyber Resilience Act (CRA) is taking effect.

That’s why Codenotary’s extension of its free SBOM.sh service with new capabilities aimed squarely at tracking the fast‑growing but opaque AI software supply chain is a big deal. This service treats datasets and models as first‑class supply chain artifacts rather than afterthoughts. Codenotary positions this as an evolution of the SBOM concept to reflect how AI‑native systems are actually built, deployed, and run in production.

Codenotary’s SBOM.sh is a free, cloud‑based service for creating, storing, analyzing, and sharing SBOM. You use it by uploading SBOM JSON files, and you get back a unique URL that can be used to retrieve and share that SBOM at any time via a browser or command‑line tools such as cURL. It supports the standard SBOM formats CycloneDX and System Package Data Exchange (SPDX). These can then be included in development pipelines via container images, filesystems, and Git repositories, using companion tools and GitHub Actions.

At the heart of the release is the idea that the data used to train and run models is part of the software supply chain and deserves the same scrutiny as libraries and containers. By treating datasets as artifacts, the company says SBOM.sh can help organizations close a critical visibility gap affecting governance, regulatory compliance, and risk management for AI workloads.

Moshe Bar, Codenotary’s CEO and co-founder, in a statement, said, “Traditional SBOM tools were built for an earlier era – focusing primarily on source code to improve visibility into the software supply chain. Security teams are swimming in SBOMs, but they’re not getting the actionable clarity they need, especially as AI transforms software with AI applications built on datasets, which are entirely ignored by traditional SBOMs.”

To deal with this, Codenotary’s expanded service introduces several AI‑specific capabilities designed to support audits and emerging regulations:
- Data provenance and governance: SBOM.sh documents dataset sources, associated licensing terms, and governance controls to help reduce exposure from improperly sourced or governed data. You can then use this information to demonstrate data handling practices during audits or regulatory reviews.
- Model lineage and training transparency: The service captures metadata about base model origins, fine‑tuning history, version identifiers, and update paths, building a traceable record of how models evolve over time.
- Inference operations and integrations: SBOM.sh provides visibility into inference endpoints, access controls, runtime integrations, and monitoring hooks, showing how models are actually invoked in production environments.
- Ownership and accountability: Ownership and approval context are embedded across AI artifacts to clarify who is responsible for particular datasets, models, and operational components.
Put it all together, and Codenotary claims these additions transform what has often been a static SBOM snapshot into a “living, behavioral inventory” of AI data, models, and operations.

Despite the new AI‑centric capabilities, SBOM.sh remains a free service that developers, DevOps teams, and security organizations can use to upload, analyze, and share SBOMs alongside their AI-powered software supply chain data. The web‑based, API‑driven service is designed to operate at scale and to integrate with existing CI/CD pipelines and workflows.

Codenotary says its broader platform is already used by hundreds of customers worldwide, including major banks, governments, and defense organizations, to protect the software development lifecycle with integrity verification and tamper detection. The company also emphasizes its use of advanced AI models to recognize attack patterns in modern software pipelines. This should appeal to any enterprise struggling to bring AI under the same governance umbrella as the rest of its software.

If this AI-savvy SBOM.sh delivers on its promises, it could become a key piece of infrastructure for teams trying to answer a deceptively simple question that regulators, customers, and boards alike are now asking: “What exactly is inside your AI code?”
January 26, 2026
Codenotary Previews Secure SBOM Creation Service

Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

April 27, 2023
Opvizor Extends Monitoring Reach to the Cloud

Opvizor, a unit of Codenotary, has extended its monitoring capabilities to cloud computing environments starting with support for Amazon Web Services (AWS) and Microsoft Azure.

Codenotary CTO Dennis Zimmer said Opvizor aggregates data to provide a more efficient approach to applying analytics to surface performance and risk issues.

Previously, Opvizor was optimized for instances of VMware vSphere running in an on-premises IT environment. Now the unit of Codenotary, a provider of a service for generating software bills of materials (SBOMs), is extending those monitoring capabilities to the cloud.

That transition comes as many organizations are looking to strike a balance between monitoring pre-defined metrics and observability platforms that make it possible to surface unknown potential issues that could adversely affect IT environments.
It’s still early days as far as observability is concerned, so Opvizor is focused on meeting most IT teams where they are today as they further embrace cloud computing, said Zimmer.

Observability, in general, promises to query not just logs and metrics but also distributed traces that are applied to specific processes. In that way, observability allows organizations to detect patterns that have not been predefined. In effect, an observability platform makes it simpler to debug application environments where the number of dependencies that exist between services are becoming too complex to track manually, much less decipher. Without the aid of an observability platform it can take weeks to discover the exact cause of an application’s performance degradation.

Of course, those applications will need to be instrumented using agent software capable of generating the data observability platforms require. Fortunately, open source projects such as OpenTelemetry are helping to drive down the total cost of instrumentation.

However, in the absence of observability, most IT teams will rely on existing monitoring tools. Opvizor is making a case for centralizing monitoring across multiple platforms to reduce costs, noted Zimmer.

Heading into 2023, each IT team will need to decide how and when to rely on traditional monitoring tools versus observability platforms. Many observability platform providers are justifying the acquisition of a new platform based on cost and the ability to eliminate the need for multiple monitoring tools. However, it remains to be seen whether IT organizations will prefer to employ both monitoring tools to track predefined metrics alongside observability platforms.

Regardless of approach, the reality is that IT environments are becoming more complex to manage. In addition to running workloads in multiple cloud platforms and on-premises IT environments, organizations are deploying emerging cloud-native applications based on containers alongside existing monolithic applications deployed on legacy virtual machines. As workloads are deployed on multiple platforms, the total cost of IT starts to rise. One way to contain those costs is to standardize on a set of tools that can be applied to multiple platforms.

The pressure to rationalize toolsets only increases during any period of economic uncertainty. The challenge, of course, is convincing one team to give up their preferred tool in favor of another to reduce costs.

December 20, 2022
Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

Codenotary has extended the reach of its platform for automatically generating software bills of materials (SBOMs) to serverless computing platforms running software constructed using functions.

Codenotary CTO Dennis Zimmer said because serverless apps are dynamically created, it’s not possible to generate SBOMs using traditional approaches. The TrueSBOM platform makes it possible to create an SBOM in real-time by adding one line to the source code of any application. The TrueSBOM for Serverless edition of the platform now extends that capability to the serverless computing frameworks made available in the cloud by Amazon Web Services (AWS), Microsoft and Google.

That approach makes the SBOM a part of the application itself rather than a text file that is stored separately, he noted. Each time an application is updated or a scanner discovers a new vulnerability, a new SBOM is automatically generated, added Zimmer.

Awareness of the need for SBOMs has skyrocketed since an executive order issued by the Biden administration made it clear that federal agencies would require them from software providers starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

Most internal DevOps teams already have a good handle on what software components are used within the applications they deploy. The issue is that the organizations that use that software can’t easily verify what components are being used, noted Zimmer. That’s problematic because an organization may prohibit deployment of a specific software component because of a known vulnerability. TrueSBOM allows organizations that use an application to maintain control over their software environment regardless of what software artifacts are used to build closed or open source components, Zimmer added.

It’s unclear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software with components that have been verified as secure.

As SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to manage effectively. As a result, many organizations are now putting together dedicated teams made up of cybersecurity professionals and software developers to manage SBOM processes, said Zimmer.

Of course, there is a massive amount of code that has already been deployed that today doesn’t show up in an SBOM. While many emerging applications—created using artifacts such as functions and containers—are likely to be increasingly instrumented to dynamically generate an SBOM, the number of legacy applications that might need to be similarly instrumented is several orders of magnitude greater. As a consequence, the amount of effort required to generate SBOMs for every application in use might be greater than teams first anticipated.

December 9, 2022
Codenotary Automates SBOM Creation

Codenotary today launched a tool that enables an application to automatically generate a software bill of materials (SBOM) by adding a single line to its source code.

Codenotary CEO Moshe Bar said TrueSBOM makes it possible to self-report the components used to construct applications to any organization that uses them for the first time. In contrast, existing SBOMs only provide a snapshot of the components of an application at the time it was initially created, he added.

IT organizations are being asked to trust application providers that all the modules specified in the SBOM are the only components being used. Codenotary is making a case for an approach that enables the organization consuming that software to spin up an SBOM in real-time on demand.

From a DevSecOps perspective, adding a single line of code to the application to enable TrueSBOM should also eliminate the need to create and maintain separate text files to generate an SBOM.

Awareness of the need for SBOMs has skyrocketed since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

That approach also makes it a lot simpler for organizations to accurately pinpoint where components are actually running any time a new zero-day vulnerability is discovered, added Bar.

Priced at $1,450 per application stack per year, there are also lower-cost instances of TrueSBOM available for applications based on either a serverless framework or using the portable WebAssembly (Wasm) format.

Most internal DevOps teams already have a good handle on what software components are being employed with the applications they deploy, said Bar. The issue is that the organizations that use that software can’t easily verify what components are being employed, he added. That’s problematic because an organization may have decided to prohibit deployment of a specific software component because of a known vulnerability. Rather than trust a text file created by the provider of an application, TrueSBOM allows the user of an application to maintain control over their software environment, noted Bar.

It’s not yet clear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software that has components that have been verified to be secure. Armed with those insights, over time, it should become simpler to start reducing security technical debt with more secure applications, added Bar.

The challenge, of course, is that the Codenotary solution requires the addition of one line of code to an application. However, as SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to effectively manage.

November 14, 2022
Codenotary Adds SLSA Framework Support to Advance App Security

Codenotary this week announced it has integrated support for the Supply-Chain Levels for Software Artifacts (SLSA) framework in its free notarization and verification service for ensuring the integrity of code.

Moshe Bar, Code Notary CEO, said as the first application security platform to attain SLSA compliance, the company is making it easier for organizations to secure their software supply chains.

SLSA is a framework defined by Google that it uses to attach binary authorization to code. In its current form, SLSA is a set of guidelines that identify how to attain four different levels of application security. The long-term goal is to create a framework that will automatically generate auditable metadata that can be fed into policy engines to create a SLSA certification.

Codenotary provides tools for cataloging and verifying the authenticity of components used with a software development life cycle. At the core of that platform is an immutable open source immudb database that cryptographically attaches an identity to each software artifact. That capability can also be used to dynamically generate a software bill of materials (SBOM).

The Codenotary Attestation Service can also be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams use to build and deploy applications using those artifacts. Ideally, DevOps teams should construct a security pipeline that runs alongside their existing DevOps pipelines, noted Bar.

In the wake of recent high-profile software supply chain breaches, the level of scrutiny being applied to how software is constructed has increased significantly. In theory, at least, developers have assumed more responsibility for application security as part of an overall shift left that provided them with more programmatic control over IT environments. Cybercriminals, however, are now becoming more adept at compromising developers’ credentials and insert malware as an app is developed.

DevSecOps best practices are, of course, being adopted to teach developers how to better secure their application environments. The issue is that not enough developers are learning how to secure applications fast enough. The volume of attacks against the software supply chain continues to grow at a rate that is now much faster than organizations can thwart simply by educating developers.

There is a now clear need to embed more cybersecurity guardrails within DevOps workflows, noted Bar. Rather than attempting to achieve that goal in a piecemeal fashion, Bar said Codenotary is making a case for an integrated platform that can be invoked as a natural extension of a DevOps workflow.

In general, Bar said there’s now a greater sense of urgency when it comes to software supply chain security. Many of the reviews of those processes are, arguably, long overdue. One way or another, there will be a lot more questions asked about how software is actually developed. The organizations that consume this software are starting to appreciate how vulnerable they are as the overall dependency on software continues to increase. The only real question now, unfortunately, is how many more breaches there might be before those software security issues are thoroughly addressed.

June 17, 2022
Codenotary Adds Vulnerability Scanning to Popular Community Platform for Open Source Supply Chain Security

Community Attestation Service addresses need for integrated, continuous security for developers

KubeCon Europe, VALENCIA, Spain, May 16, 2022 — Codenotary, leaders in software supply chain security, today announced the addition of the first-ever free background vulnerability scanning service combined with a free and open source Community Attestation Service (CAS) code signing and attestation service to further secure open source supply chains.

Gartner predicts that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021. The addition of a free vulnerability service to CAS allows cloud native and open source projects to better secure their projects. This additional service scans assets (based on the hashes uploaded) for any known security vulnerability and provides alerts if problematic packages are found in the stack. CAS can also be used to “untrust” any problematic artifacts.

“This is especially unique – a totally free code integrity service that integrates automated, continuous and self-updating vulnerability scanning, delivering alerts when it finds issues,” said Dennis Zimmer, co-founder and chief technology officer, Codenotary. “Users of open source software – and that is pretty much everyone – have a free and easy way to ensure the security of their software supply chain which addresses a big and growing problem”

Codenotary is the primary maintainer of immudb, the first and only open source enterprise-class immutable database with data permanence at scale for demanding applications — up to billions of transactions per day. Codenotary uses immudb to underpin its notarization and verification product. There have been more than 12 million downloads of immudb.

Anyone can start using CAS today to ensure their open source software is secured for themselves and their users. Codenotary is at booth S92 at KubeCon Europe from May 16-20.

Codenotary provides tools for cataloging and trusting components of the software development lifecycle which help attest to the origin and safety of the code. The company further enhances this core functionality by providing an additional tamper-proof layer which processes and stores millions of transactions per second, on-premises or as a cloud service, and with cryptographic verification. It gives developers a way to attach a Software Bill of Materials (SBOM) for development artifacts that include source code, builds, repositories, and more, plus Docker and Kubernetes container images for their software.

About Codenotary

With over 100 customers that includes top three banks in the U.S. and Europe, Codenotary brings easy to use trust and integrity into the software lifecycle by providing end-to-end cryptographically verifiable tracking and provenance for all artifacts, actions, and dependencies. Codenotary can be set up in minutes and can be fully integrated with modern CI/CD platforms. It is the only immutable and client-verifiable solution available that is capable of processing millions of transactions a second. With the Codenotary tamper-proof bill of materials, users can instantly identify untrusted components in their software builds. For more information, go to https://www.codenotary.com.

Contact
Joe Eckert for Codenotary Eckert Communications jeckert@eckertcomms.com

May 16, 2022
Codenotary Launches Cloud Service to Generate SBOMs

Codenotary has launched a Codenotary Cloud platform that can automatically generate a software bill of materials (SBOM) and make it easier to discover what components have been included in an application.

Moshe Bar, Codenotary CEO, said that capability can also play a key role in identifying which components in an application might contain, for example, the Log4jShell vulnerabilities that were recently discovered in Java applications.

That capability can reduce the time required to remove insecure artifacts by as much as 80% simply because organizations are not dependent on scanning tools to search for vulnerable components, added Bar.

Codenotary Cloud is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. In the wake of a series of high-profile breaches, there’s now a lot more focus on the integrity of software supply chains. In fact, the Biden administration recently issued an executive order requiring all federal agencies to, among other things, make sure an SBOM is available for all the software they use.

Codenotary claimed Codenotary Cloud can scale to millions of integrity verifications per second across source code, builds, repositories, Docker container images and Kubernetes deployments in a way that doesn’t require DevOps teams to upload data to a centralized platform, noted Bar. That makes it possible to notarize and verify the provenance of all the code being employed, he added.

Codenotary Cloud can also be fully integrated with most vulnerability scanners and popular cloud-native continuous integration/continuous delivery (CI/CD) systems running on any cloud or on-premises host via a managed service. Pricing starts at $5,500 for a workgroup of 10 developers.

It’s not clear to what degree the Biden administration’s executive order will improve overall software security. There have been multiple vulnerability issues over the years that have not resulted in any material change in how organizations manage their application development processes. However, the executive order issued by the Biden administration, coupled with a recent summit on the state of open source software security, means more senior business and IT executives are at least aware of growing concerns.

The one thing that is certain is there will be more zero-day vulnerabilities discovered. Developers today routinely reuse open source software and free components maintained by a small number of volunteer programmers. Like any other developer, the amount of security expertise those individuals have is limited. Many organizations reuse that code without contributing anything meaningful back to the project—either in terms of financing or vulnerability identification and remediation support. Contributors to these projects freely donate their time and expertise to build these components. Many of those contributors feel the onus for securing the software they created is on the organizations that decide to deploy that software.

Regardless of who is responsible for security, it’s apparent cybersecurity teams are going to be reviewing application development processes. Theoretically, that should benefit all concerned and lead to DevSecOps best practices being more widely adopted.

February 7, 2022
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.

October 26, 2021