How Sonatype Guards the Software Supply Chain from Code to Cloud

Sure, your developers built the app, but did they really build everything in it?

Today’s applications are largely composed of open-source libraries, frameworks, containers, APIs, and increasingly, AI. Everything gets pulled into development environments at a blistering pace. That makes software development fast. But it creates a problem that doesn’t end when the vulnerability scanner finds a CVE. That’s because that component could already be in the build, deployed to multiple environments, and relied upon by applications that no one remembers touching.

In its 2026 State of the Software Supply Chain report, Sonatype describes an ecosystem operating at “machine scale” where open-source registries are increasingly critical infrastructure, and attackers are increasingly leveraging open source as a distribution channel. And it notes that “vulnerable versions continue to be downloaded after a fix is released, often due to transitive dependencies, upgrade friction, and unclear ownership.”

So, the question isn’t just about finding bad code. It’s about knowing what goes into the software supply chain, whether it should be allowed, and governance after developers begin using it.

The problem doesn’t stop at the first vulnerability

Software Composition Analysis (SCA) has become a mainstay for addressing this issue. In its simplest form, SCA identifies the open-source components used in an application, compares them to known vulnerabilities, and flags those that need action.

Where it gets tricky is what comes next. There can be dozens or hundreds of transitive dependencies that tag along behind the direct dependencies of a modern application. A vulnerability in one component might sound alarming, but if the affected code is never actually reached, the impact could be minimal. Or, conversely, a component that appears to be low risk could be deeply embedded in a mission-critical application.

This differentiation is particularly relevant given that interpreting vulnerability data itself is getting harder. According to Sonatype, nearly 65% of open-source CVEs lack CVSS scores in the National Vulnerability Database (NVD), which means there’s no easy way to assess their severity. So, the company’s Lifecycle product integrates vulnerability intelligence with additional context such as reachability, breaking changes, and upgrade availability, so organizations can focus on what’s actually risky instead of simply working down a list of CVEs.

It’s in this area that the concept of software supply-chain security starts to shift away from scanning and toward ongoing decision-making and governance.

From scanning to governance

Lifecycle embeds this logic into development by helping identify vulnerable or non-compliant components before they’re used, enforcing policies based on criteria like application type or risk profile, and monitoring dependencies as they evolve. It also enables SBOM visibility so teams can understand exactly what’s in their applications, rather than relying on a static inventory.

This means security policy can now be woven into the developer workflow as opposed to sitting at the very end of a long checklist. That matters because developers don’t want another security queue. If a dependency is blocked after an application is developed, then fixing it is essentially rework. Addressing the issue when a developer chooses or changes a component is considerably less disruptive.

Sonatype’s strategy also covers automatic mitigation via what Sonatype calls Golden Pull Requests, which can suggest dependency upgrades based on compatibility. The goal here isn’t to alert a developer about a vulnerability; it’s about reducing the time from awareness to remediation.

Security starts before the build

There is one more problem with relying purely on scanning: by the time something is incorporated into a build, it is typically already in your environment. This is where Sonatype’s larger software supply-chain platform fits in. While Nexus Repository provides storage and control for software artifacts in a centralized repository, Sonatype Firewall analyzes incoming open-source components and AI models for vulnerabilities or malicious code before they reach a development environment.

And there’s an important distinction. Lifecycle is more about understanding and managing application use. Sonatype Firewall is about moving the control upstream to screen components before they ever enter a dev environment. That creates a layered supply-chain security strategy, with components being evaluated before they’re consumed, analyzed as apps are built, and tracked as dependencies change. So instead of assuming that a single security scan will detect everything, security controls are spread across the software lifecycle.

The software supply chain needs a memory

Security is only part of the problem. Organizations also need to understand the provenance of components, what’s in them, which apps use them, and whether they conform to internal or external standards. This is where SBOMs come in, but only if they’re kept up-to-date. An inventory created once during a release goes out of date as soon as dependencies change. Sonatype Lifecycle is capable of creating or importing SBOMs and continuously monitoring direct and transitive dependencies, while its SBOM Manager is designed to manage and share this data across applications and teams.

This general trend is in no way limited to Sonatype. OWASP’s 2025 Top 10 places Software Supply Chain Failures at A03 and cites out-of-date or vulnerable third-party components, transitive dependencies, insecure build processes, and untrusted components as key risks that organizations need to mitigate. Its suggested controls include maintaining SBOMs, taking constant inventories of components, monitoring sources of vulnerabilities, and utilizing SCA tools.

What’s interesting is that this puts software supply-chain governance less in the realm of security and more into everyday software development.

Security can’t start at the finish line

What’s more significant, however, is that supply-chain security is moving beyond the single-security-gate model. Open source isn’t going away, and shouldn’t. The whole point is to let developers build on existing work. The challenge is to make that reuse sufficiently predictable that it can be managed at scale within an organization.

Sonatype’s role is to put governance around that process, which means checking components before they reach a development environment, evaluating dependencies in the build process, enforcing policies, helping developers fix issues, and maintaining oversight over what ultimately ships. Its 2026 research highlights how increased automation, accelerated software development, and AI integration are making software supply-chain trust harder to manage at scale.

In conclusion, Security cannot begin when an application is ready for production. By then, the most important decisions about what went into that application have already been made.

The next generation of software security will be less about inspecting finished applications and more about making every component’s journey through development visible, governed, and trustworthy.