A06:2021 — Vulnerable and Outdated Components has been in the OWASP Top 10 long enough that it's become a compliance checkbox. Security teams point to it in audit reports; engineering managers reference it in roadmap prioritization discussions; vendors cite it in sales decks. What it rarely drives is a disciplined, operationally effective approach to dependency risk management.
The checkbox version of A06 compliance looks like this: deploy an SCA scanner, close "open CVEs" tickets on a quarterly cadence, check the box in your SOC 2 or ISO 27001 evidence package. The problem is that this approach optimizes for the appearance of compliance rather than actual reduction in dependency-related exploitability. The incidents that make headlines — breaches traced to known-vulnerable third-party components — happen at organizations that had SCA tooling running. They just weren't running it effectively.
What A06 is actually measuring
The OWASP Top 10 entry for A06 is broader than just CVEs. It covers:
- Components with known vulnerabilities (CVEs in NVD or ecosystem-specific advisories)
- Unsupported or end-of-life components that no longer receive security updates
- Components that haven't been scanned for vulnerabilities
- Developers who don't know what components are in use (SBOM gap)
- Failure to regularly update or patch components on a risk-based schedule
The "outdated components" part of the name is often under-weighted relative to the "vulnerable" part. A component that has no published CVEs but hasn't received a security update in 18 months is an A06 risk — not because of a known specific vulnerability, but because the probability of undetected vulnerabilities in unmaintained code is non-trivial, and the organization has no remediation mechanism when a vulnerability is eventually discovered.
The compliance checkbox creates perverse incentives
When A06 compliance is measured by "CVE count closed per quarter," the incentive is to close CVE tickets, not to reduce real exploitability. These produce very different behaviors.
Closing CVE tickets can be accomplished by: upgrading packages, suppressing alerts for packages deemed non-critical, accepting risk formally, or blanket-ignoring certain CVE severity levels. All of these reduce the open ticket count. Only one of them — actually upgrading to a non-vulnerable version when the fix exists and the call path is reachable — meaningfully reduces exploitability.
Consider a common scenario in SaaS engineering orgs: an SCA tool flags 40 medium-severity CVEs across the dependency tree. The AppSec team runs a bulk-accept for anything below CVSS 7.0 to keep the ticket queue manageable. The 40 medium CVEs disappear from the open queue. A06 compliance score improves. But none of the packages were actually updated, and some of those medium-severity CVEs involve reachable code paths where the severity assessment was conservative.
We're not saying every medium CVE needs immediate patching — triage and prioritization are necessary. What we're saying is that "close the ticket" and "reduce the risk" are not the same operation, and treating them as equivalent produces a compliance theater situation.
The SBOM gap: knowing what you have
OWASP A06 explicitly covers scenarios where organizations don't know what components are in use. This sounds like a basic problem — surely you can just look at your lockfiles — but at scale it isn't.
In engineering orgs with dozens of services, the "complete SBOM for everything in production" problem is genuinely hard. Services have different lockfile formats (npm for frontend, pip for data pipelines, Maven for backend Java services). Containerized deployments include OS-level packages that aren't tracked in application lockfiles. Third-party integrations run components you don't directly manage.
Executive Order 14028 established SBOM requirements for software sold to the US federal government, which formalized what many security practitioners had been advocating for years: you can't manage risk in components you haven't inventoried. The operationally mature approach to A06 starts with a complete, continuously-maintained SBOM across all services — not a point-in-time lockfile audit.
PR-level SCA that generates SBOM artifacts on every merge is one path to continuous SBOM maintenance. Every time a dependency changes, the SBOM updates automatically, and the delta is attributable to the PR that introduced it. This is meaningfully different from a quarterly SBOM generation exercise.
Risk-based prioritization vs. age-based prioritization
A common A06 remediation approach is to prioritize updates by age: update the oldest, least-maintained packages first. This is a reasonable heuristic for the "outdated" component risk, but it's a poor heuristic for CVE prioritization. A CVE in a well-maintained, widely-used package (say, a major HTTP framework) may have a well-understood upgrade path and quick fix available. A CVE in an unmaintained niche utility may have no fix available at all.
The more accurate prioritization combines reachability + severity + fix availability:
- Priority 1: REACHABLE + HIGH/CRITICAL + fix version available
- Priority 2: REACHABLE + MEDIUM + fix version available
- Priority 3: NOT REACHABLE + any severity (schedule for next dependency update cycle)
- Priority 4: REACHABLE + no fix available (track, apply mitigations, monitor for fix)
This ordering sometimes conflicts with CVSS score ordering. A CRITICAL CVE in an unreachable code path is lower priority than a HIGH CVE in a function your code calls on every request. CVSS score measures inherent severity; reachability + call chain evidence measures your application's actual exposure. The combination is the correct prioritization signal.
Operationalizing A06 beyond the checkbox
The organizations that actually minimize their A06 exposure share a few operational practices that go beyond deploying an SCA scanner:
First, they tie CVE findings to specific PRs and engineers. When a vulnerable package enters the codebase, the introducing PR and its author are recorded. This enables targeted outreach and creates accountability without blame — "PR #1043 introduced this dependency, let's discuss the upgrade path" is more actionable than "our lockfile has a CVE."
Second, they measure time-to-remediate for reachable HIGH/CRITICAL findings as a team metric, not just a security team metric. If it takes 45 days on average from detection to merge for CRITICAL reachable CVEs, that's a pipeline problem that security and engineering leadership both need to own.
Third, they distinguish between "acknowledged non-reachable" and "open, unreviewed" in their vulnerability queue. An advisory hit on a package with no call path to the vulnerable function is a different risk category than one that hasn't been triaged yet. Keeping these distinct prevents the all-open-items-look-urgent problem that plagues flat alert lists.
A06 compliance that actually reduces risk looks like a pipeline where every dependency change gets a reachability-aware review, findings are prioritized by real exploitability, and remediation timelines are tracked against measurable SLAs. The compliance checkbox is easy. The operational practice is the work.
