Why Software Dependency Governance Must Go Beyond CVE Remediation
Summary
The article argues that CVE remediation alone misses malicious, unmaintained, unlicensed or unverifiable dependencies, and recommends lifecycle governance with pre-adoption checks, inventory, monitoring and assigned owners. Sonatype cites scoring gaps and Spring-related
Key points
- CVE records and scores do not show whether vulnerable code is reachable, whether a dependency is direct or transitive, or whether a safe upgrade is available.
- Sonatype's analysis of 1,552 open-source CVEs found 64% had no CVSS score, severity categories matched across sources only 19% of the time, and scoring delays averaged six weeks.
- Dependency risk can also involve malicious packages, licensing conflicts, unmaintained projects, unverifiable provenance, or policy violations.
- The article says AI coding tools can add dependencies before teams have checked whether they are maintained, permitted, or suitable.
- Sonatype tracked 91 CVEs across Spring and related projects in August 2026; Sonatype Guide reported 148,608 affected components at publication. The article says this does not establish that AI caused the vulnerabilities.
- Recommended practices include defining component policies, evaluating dependencies before adoption, recording where they are used, monitoring changes, and assigning decision owners.
- The article recommends responses proportionate to risk, such as immediately blocking known malicious packages and reviewing licensing issues before distribution.
Article Details
- Defense Focus
- Govern software dependencies across their lifecycle by assessing component risk before adoption, maintaining dependency visibility, and routing issues to appropriate owners.
- Detection Methods
- Evaluate candidate components against requirements for security risk, approved sources, licensing, maintenance, and provenance before adoption.
- Maintain and review an inventory of component identities, versions, origins, dependency relationships, and the applications or releases that include them.
- Monitor adopted components for new vulnerability information, changes in maintenance or policy status, and potentially compromised releases.
- For vulnerability disclosures, identify affected applications and direct or transitive dependencies, locate vulnerable versions, and assess exposure and available fixes.
- Data Sources
- Component identity and version records
- Dependency relationships and application or release inventories
- Component origin and provenance information
- Vulnerability disclosures and available fix information
- Component maintenance, licensing, and policy status
- Defensive Actions
- Set dependency requirements and approved component choices before adoption.
- Block known-malicious packages immediately.
- Route licensing issues for review before distribution.
- Schedule replacements for unmaintained components, with time-bound exceptions where appropriate.
- Assign owners for upgrades, replacements, license reviews, and exceptions; document exceptions and review dates.
- Prioritize remediation using exposure, exploitability, available fixes, and business context.