Stop Chasing CVEs: Start Governing Software Dependencies
7 minute read time
A new vulnerability disclosure can set off a familiar chain of work. You check whether or not an application uses the affected component, determine whether the vulnerable code is reachable, find a fixed version, test the upgrade, and get it into production. Then the next advisory arrives.
Known vulnerabilities need to be understood and remediated. But a process built around chasing CVEs one at a time can leave teams reacting to risk after a dependency has already entered their software.
It also leaves important questions unanswered:
-
Is the package malicious?
-
Is its license acceptable?
-
Is the project still maintained?
-
Can its origin be verified?
-
Does the dependency meet the organization's requirements?
A CVE is a useful signal, but it is not a complete measure of component trust. Teams need to govern the software dependencies they use across the SDLC, from selection and approval through ongoing monitoring and remediation.
CVE Remediation Is Necessary. It Is Not the Whole Strategy.
The CVE system gives security teams, developers, vendors, and researchers a shared way to identify known vulnerabilities. But a CVE record or score does not show whether vulnerable code is reachable in an application, whether a dependency is direct or transitive, or whether a safe upgrade is available.
Sonatype's analysis of 1,552 open source CVEs found that 64% had no CVSS score, severity categories matched across sources only 19% of the time, and scoring delays averaged six weeks. Those gaps can make it difficult to rank findings and decide where engineering time will reduce the most risk.
Teams need to treat CVEs as one input and weigh them alongside component use, available fixes, and application context.
Disclosure Starts the Remediation Cycle
When vulnerability management centers on incoming CVEs, teams begin responding after disclosure: identifying affected versions, tracing dependencies, and coordinating upgrades. By then, a component may already appear across applications, build environments, and releases, adding to the remediation backlog.
Component risks also extend beyond CVEs. A package may be malicious, poorly maintained, or incompatible with licensing requirements. Finding those issues earlier can help teams avoid broader changes, release delays, and retesting.
AI Is Increasing the Pace of Discovery and Consumption
AI is changing how quickly teams find and use software components. A developer might ask a coding assistant to add a feature, accept its suggestion to use a new library, and move on to the next task. The package can become part of the project before anyone has checked whether it is maintained, allowed by policy, or appropriate for that use. Consequently, teams must absorb a higher volume of vulnerability disclosures while simultaneously tracking which components enter their codebase and why.
A large Spring security disclosure illustrates the downstream scale. In August 2026, Sonatype tracked 91 CVEs across Spring and related projects. At the time of publication, Sonatype Guide reported 148,608 affected components, including components that bundle vulnerable Spring code. The disclosure does not establish that AI caused those vulnerabilities, but it shows how broadly a vulnerability can affect software that depends on an ecosystem.
Teams responding to disclosures at this scale need to determine:
-
Which applications include the affected components, directly or transitively?
-
Which vulnerable versions are present or deployed?
-
Which components pose the greatest risk in their environment?
-
Which upgrades will address the vulnerabilities without causing unnecessary disruption?
Discovery can move faster than downstream teams can locate, assess, and upgrade affected components. As AI-assisted vulnerability research develops, vulnerability intelligence and remediation processes will need to keep pace.
Teams also need visibility into what is in their software, where it came from, how it is used, and who owns decisions to keep, upgrade, replace, or accept it. That context helps turn a stream of findings into work that can be prioritized and acted on.
Component Risk Goes Beyond Vulnerabilities
A component can create risk even when it has no known CVE. A more complete assessment considers several dimensions:
-
Malware: Has the package or release been compromised, or does it contain malicious behavior?
-
Licensing: Is its license compatible with the project's obligations and intended use?
-
Maintenance: Is the project maintained, and can the team rely on its release and support practices?
-
Provenance: Can the component's source and history be verified?
-
Policy: Does it meet the organization's requirements for approved sources, versions, and use cases?
Each scenario demands distinct evidence and action: fixing vulnerable releases, instantly blocking malicious packages, scheduling replacements for unmaintained libraries, legally reviewing licenses, or verifying provenance prior to approval.
Treating every issue as another scanner finding can obscure those differences. Component governance gives teams a way to define which qualities matter, set expectations before adoption, and assign an appropriate response when a component falls outside them.
Govern Dependencies Before and After Adoption
Governance works best when it is part of normal development, rather than a review that begins after a release is ready.
Teams can make it practical by connecting policy to the component lifecycle:
-
Define acceptable use. Establish requirements for sources, licenses, maintenance, provenance, and known security risks. Set policies that reflect how components will be used and the impact of a failure.
-
Evaluate before adoption. Check candidate components against those requirements before they become dependencies. Give developers and AI tools clear, approved choices where possible, so the compliant path is also the easy path.
-
Maintain a record of use. Track component identity and version, origin, dependency relationships, and the applications or releases that include it. This context helps teams understand the reach of a new advisory or policy change.
-
Monitor for change. A component's status can change after adoption. New vulnerability information may emerge; a project may become inactive; a release may be compromised; or an organization's policy may change. Reassess components as new evidence arrives.
-
Route decisions to owners. Define who handles upgrades, replacement, license review, and exceptions. Record the reason for an exception and when it should be reviewed again.
Scanning and patching remain essential, but connecting them to a broader decision framework lets teams weigh vulnerabilities against exposure, exploitability, available fixes, and business context. Meanwhile, malware alerts, licensing issues, and maintenance risks can be routed directly to the appropriate decision-makers.
Effective open source policy enforcement aligns with risk severity. Known malware warrants immediate blocking, licensing queries require review before distribution, and unmaintained low-risk components may receive temporary exceptions. Explicit thresholds, designated owners, and time-bound exceptions enable consistent standard application without unnecessary escalations or blanket bans.
Timing is critical. Providing developers and AI tools with trusted, policy-approved component options during dependency selection allows teams to address risk before it is built in. Identifying flagged components later in release pipelines forces teams to reverse decisions already embedded across repositories and applications.
Move From a Findings Queue to Better Decisions
Software teams will continue to receive CVEs, and they should continue to remediate vulnerabilities that put their applications at risk. But a growing list of CVEs is not, by itself, a strategy for choosing and managing software components.
A stronger approach starts earlier and continues after adoption. It helps teams select components that meet their needs, understand where those components are used, detect changes in their risk, and respond according to clear policies. That can reduce avoidable surprises and help engineering teams spend less time reconstructing dependency context during an incident.
The goal is not to eliminate vulnerability work. It is to make that work part of a more complete way to govern software components — one that accounts for security, licensing, maintenance, provenance, and policy throughout the software lifecycle.
Sonatype Nexus One platform helps put that strategy into practice and gives teams the data to assess open source dependencies. With trusted component intelligence and policies built into development workflows, teams can make better decisions about what they use and respond more effectively when the evidence changes. Contact us to learn more about how you can improve your open source governance strategy.
Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.
Explore All Posts by Aaron LinskensTags
Code 3x Faster with Less False Positives
Build, test, and launch secure applications without rework. Explore how the Sonatype platform can enhance productivity and security.