Vulnerable & Outdated Components
detect, prioritise, remediate
Vulnerable and outdated components (OWASP A06:2021) is the parent category for the software-supply-chain risk that an application depends on libraries, frameworks, runtimes, container base images, or operating-system packages that ship with known CVEs, missing patches, or no upstream maintainer. It reaches across direct, transitive, runtime, and infrastructure layers and is one of the most common ways an enterprise application becomes exploitable without a single line of code changing.
No credit card required. Free plan available forever.
What are vulnerable and outdated components?
Vulnerable and outdated components is the OWASP Top 10 category that captures the full software-supply-chain failure pattern, not a single bug. OWASP listed it as A06:2021 to consolidate three previously separate Top 10 entries (using components with known vulnerabilities, using outdated components, and using unsupported components) and to give AppSec, vulnerability management, and product security teams one shared name for the risk that a deployed application depends on libraries, frameworks, runtimes, container base images, or operating-system packages that ship with known security flaws, missing patches, or no upstream maintainer at all. The canonical CWE is CWE-1104 (Use of Unmaintained Third Party Components), and the wider OWASP mapping covers CWE-937 (Use of Components with Known Vulnerabilities), CWE-1035 (Using Components with Known Vulnerabilities), and the supporting design-stage weaknesses around inventory, version discipline, and patch cadence.
The category is a parent, not a single vulnerability. A component is in scope for A06 if you do not know which version is in production, if you know the version but it has a published CVE you have not patched, if the version is no longer supported by an upstream maintainer, if the version is several majors behind current and missing accumulated security fixes, if it reaches you only through a transitive dependency you never named directly, or if it sits in a container base image, a runtime, or an operating-system package that lives outside your application code. The pattern repeats from the package manifest layer down to the kernel layer and across every language ecosystem.
A06 is mechanistically distinct from the per-package finding the platform usually records as vulnerable dependencies. The per-package finding is a single CVE in a single library that scanning surfaced; the A06 category covers the programme conditions that produce those findings repeatedly: no software composition analysis (SCA) coverage, no inventory, no end-of-life tracking, no upgrade cadence, no policy for unmaintained components, and no path to retire components that lost upstream support. SecPortal records both shapes on the engagement record through code scanning with Semgrep SAST and dependency analysis against repository connections via GitHub, GitLab, and Bitbucket OAuth, with the broader programme work landing through findings management so the supply-chain backlog and the per-package CVE share one canonical record.
Component layers in scope
A06 reaches further than the application source tree. Every layer below contributes components your application depends on at runtime, and every layer has its own version, advisory feed, end-of-life schedule, and patch cadence. A programme that scans only one layer surfaces only one slice of the category.
Direct application dependencies
Packages your manifest names directly: npm package.json, pip requirements.txt, Maven pom.xml, Gradle dependencies, Go go.mod, Ruby Gemfile, Composer composer.json, NuGet packages.config, Cargo Cargo.toml. The first layer most SCA tools cover.
Transitive dependencies
Packages your direct dependencies pull in. A single direct dependency can drag dozens of transitive packages, any of which can carry a CVE that lockfile analysis surfaces but the manifest never names.
Runtimes and language versions
Node.js, Python, Java, .NET, Ruby, PHP, Go runtime versions. A runtime past its end-of-life window stops getting security updates even if your application code is current.
Frameworks and platforms
Web frameworks (Spring, Django, Rails, Express), application servers (Tomcat, JBoss), CMS platforms (WordPress, Drupal), and ORMs that ship their own advisory streams independently of the application code that uses them.
Container base images
OS layers shipped through container base images (Alpine, Debian, Ubuntu, distroless, Red Hat UBI) and the system packages baked into them. A pinned tag from 18 months ago carries the CVEs of that day plus everything published since.
OS and infrastructure components
Operating-system packages on VMs, embedded libraries in firmware, third-party agents, system daemons, and infrastructure components whose versions are tracked outside the application repository.
How A06 surfaces in production
OWASP names A06 as a category because the same risk shape arrives through several different programme failures. The four patterns below are the most common entry points for an A06 finding on an enterprise engagement record.
Known CVE in a used version
The advisory feed publishes a CVE against a version that lockfile analysis confirms is in production. The component is not outdated by year; it is current at the time of the advisory and becomes vulnerable the moment the CVE lands. The programme has to detect and react before exploitation tooling does.
Outdated version, accumulated CVEs
The pinned version is several minors or majors behind current. No single CVE forced an upgrade, so the version sat. Each newly published advisory against intermediate versions added to the backlog until the upgrade became a multi-week project rather than a routine patch.
Unmaintained component
The component has no upstream maintainer publishing security updates. The repository is archived, the project sunset, or the original author moved on. New CVEs against the component will not receive an official fix, so the programme has to decide between a maintained replacement, an internal fork, or an accepted risk with compensating controls.
Invisible transitive or runtime drift
A direct dependency upgraded itself, pulled in a new transitive, and the new transitive carries a CVE the team never reviewed. Or the runtime image rebuilt against a newer base and inherited fresh OS-package CVEs. The version moved without a code change and the SCA window missed it.
Common causes
No SCA coverage across the portfolio
Software composition analysis runs on a few flagship repositories but not every service. Smaller services, internal tools, and contractor-owned codebases never get the dependency scan, so the A06 surface for those assets is invisible.
No inventory of components in production
The team cannot answer the question: which version of which library is currently running in production for each service. Without that inventory, the response to a high-profile CVE (Log4Shell, Spring4Shell, OpenSSL) becomes a forensic exercise rather than a query.
No end-of-life or supportability tracking
The runtime, framework, or operating-system version that an application depends on has fallen out of upstream support. Nobody is watching the EOL calendar, so the application keeps running on an unsupported version until a security incident or audit surfaces it.
Pinned versions with no upgrade cadence
Dependencies were locked to specific versions during the initial build and never revisited. Without a scheduled upgrade ritual, every patch becomes a one-off interruption that gets deferred until the next CVE forces the conversation.
Transitive depth is unmonitored
Lockfile analysis is not enabled or its output is ignored. Vulnerabilities in deep transitive dependencies are invisible to manifest-only inspection and update only through unrelated direct-dependency upgrades.
Container and runtime drift
Container base images are pinned by tag rather than digest and rebuild silently. Or the application image inherits a newer OS layer than the SCA window covered. The version in production diverges from the version the team reviewed.
How to detect it
Detection is a coverage problem before it is a tool problem. The right A06 detection posture covers every component layer that contributes to the running system, runs continuously rather than at release boundaries, and lands findings on a record that distinguishes a per-package CVE from a programme-level coverage gap.
Automated and tooling signals
- SecPortal code scanning runs Semgrep SAST rule packs and dependency analysis against connected repositories so direct-dependency CVEs and transitive-dependency CVEs surface on the same engagement record alongside source-level findings.
- Continuous monitoring schedules (daily, weekly, biweekly, monthly) keep the dependency scan running after the engagement closes so a CVE published next month against a version already in production still lands a finding on the canonical record.
- Bulk finding import lands SCA output from outside scanners (Snyk, Trivy, Grype, OWASP Dependency-Check, OSV-Scanner) onto the same engagement record through the Nessus, Burp, and CSV parsers when the platform-native scan does not cover a language or ecosystem your portfolio uses.
- Findings management captures CWE-1104, CWE-1035, CWE-937, OWASP A06:2021, the affected package and version, the CVE identifier, and a CVSS 3.1 vector that reflects the worst plausible exploitation path the version exposes for the affected asset.
Programme-stage review
- Maintain a software bill of materials (SBOM) for every deployed service in either CycloneDX or SPDX format so the inventory question (which version is running where) is answerable as a query rather than a forensic exercise. Pair the SBOM with VEX assertions so the exploitability signal travels with the inventory.
- Track upstream end-of-life calendars for every runtime, framework, and operating-system component your portfolio depends on. EOL is a planning input, not a surprise; an unsupported component on the EOL date is an A06 finding by definition because no future CVE will receive an upstream fix.
- Reconcile against the CISA Known Exploited Vulnerabilities catalog and the FIRST EPSS feed so the programme prioritises CVEs that are actively exploited or carry a high exploit-likelihood score rather than processing the alphabetised feed in arrival order.
- Establish a reachability discipline so unreachable transitive CVEs sit in a triaged backlog with a recorded rationale rather than burning incident-response capacity. Reachability is an SCA add-on; the platform records the rationale on the finding regardless of which reachability engine produced it.
How to fix it
Cover every component layer with continuous SCA
Enable software composition analysis on every repository and every container image, not just the flagship services. Direct dependencies, transitive dependencies, runtimes, frameworks, container base images, and OS packages all need a scan window. Run it on a continuous monitoring schedule so a CVE published after the last release still lands a finding.
Build and maintain a current SBOM per service
Generate a CycloneDX or SPDX SBOM as part of every build and store it as an attached artefact on the engagement record. The SBOM answers the inventory question that audit, leadership, and IR will ask the next time a high-profile component CVE drops. Pair the SBOM with VEX so the exploitability assertion travels with the inventory rather than living in a parallel spreadsheet.
Establish a scheduled dependency upgrade ritual
Treat upgrades as a recurring activity rather than a CVE-triggered emergency. A monthly cadence (or biweekly for high-velocity services) keeps the version distance small so each upgrade is a routine patch rather than a multi-week migration. Lockfiles travel with the upgrade so build reproducibility holds.
Track EOL calendars and plan migrations early
Maintain a forward calendar of upstream end-of-life dates for runtimes, frameworks, container base images, and operating systems. An unsupported component on the EOL date is an A06 finding by definition. Plan the migration before the EOL date arrives, not after the first post-EOL CVE.
Have a written policy for unmaintained components
When a component loses upstream maintenance, document the decision: replace with a maintained alternative, fork and maintain internally, or accept the risk with compensating controls and a defined re-evaluation cadence. Capture the decision on the finding through the exception register so the audit trail does not depend on a meeting note.
Prioritise with multi-signal evidence, not feed order
Combine CVSS severity, EPSS exploitation probability, CISA KEV status, asset criticality, and reachability into the prioritisation decision so the queue reflects exploitable risk in your environment rather than the alphabetised order the advisory feed produced. Patch SLAs key off the combined signal, not the bare CVSS number.
Verify closure with a follow-up scan against the upgraded build
A finding moves to closed only when a fresh SCA scan against the upgraded branch confirms the affected version is no longer present. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures that survive the next continuous monitoring run.
How SecPortal records and tracks A06 findings
SecPortal is not a standalone SCA tool, does not host an SBOM registry, and does not run a reachability engine. It is the workspace where every A06 finding lands on the engagement record alongside source-level findings, external attack-surface findings, and authenticated DAST findings so severity, ownership, evidence, fix, and retest stay on one canonical record per service. The flow for an A06 finding looks like this on the platform.
Connect the repository through OAuth
Use a GitHub, GitLab, or Bitbucket OAuth connection to give the platform read access to the codebase. Encrypted storage holds the OAuth token and the connection is scoped to the workspace so only authorised team members can trigger a scan.
Run code scanning with dependency analysis
Code scanning executes Semgrep SAST and dependency analysis against the connected repository. The dependency pass walks the manifest and lockfile, resolves transitives, and emits findings per affected package with the CVE identifier and severity captured.
Record A06 against CWE-1104, CWE-1035, CWE-937
The finding lands in findings management with the OWASP A06:2021 category, the matching CWE, the affected package and version, the CVE identifier, and a CVSS 3.1 vector calibrated for the asset tier the component runs in rather than the upstream base score.
Import results from outside SCA where needed
Bulk finding import lands Snyk, Trivy, Grype, OWASP Dependency-Check, or OSV-Scanner output through the Nessus, Burp, and CSV parsers when the platform-native scan does not cover the ecosystem. The imported findings share the same lifecycle as the native ones.
Run continuous monitoring on a schedule
Continuous monitoring runs the scan daily, weekly, biweekly, or monthly so CVEs published after the engagement closes still surface on the canonical record without anyone re-triggering a manual scan. New findings inherit the engagement scope and the routing rules already in place.
Route ownership through team management RBAC
Assign A06 findings to the named owner of the affected component or service through team management roles (owner, admin, member, viewer, billing). The activity log captures the assignment so the audit trail of who took ownership of which finding when is preserved on the record.
Capture EOL or unmaintained decisions on the finding
When the response to an A06 finding is an accepted risk against an unmaintained component, the decision lives on the finding through the exception register pattern rather than in a meeting note. The compensating controls, the re-evaluation date, and the named approver all travel with the record.
Retest against the upgraded build through the lifecycle
The retesting workflow pairs the retest to the original finding so closure means the SCA scan no longer reports the CVE in the upgraded branch. The verified_at and resolved_at timestamps preserve the audit chain of when the version moved and who confirmed it.
Generate evidence packs through AI report generation
AI report generation turns the A06 backlog and closure cadence into an exported report aimed at engineering leadership, audit, or board reporting without rebuilding the narrative from spreadsheets each cycle. The report cites the underlying findings rather than fabricating numbers.
What SecPortal does not do
Honesty on capability matters when the topic is software supply chain. SecPortal does not generate SBOMs on your behalf, does not host an SBOM registry, does not parse CycloneDX or SPDX files into a structured component graph the platform exposes as a queryable index, does not run a reachability analysis engine across application binaries, does not federate against an asset inventory or CMDB, does not integrate with Jira, ServiceNow, Slack, SIEM, SOAR, or upstream package registry advisories through a packaged API surface, and does not maintain a continuously-refreshed CISA KEV or FIRST EPSS feed inside the workspace. Programmes that need real-time KEV reconciliation, EPSS refresh, SBOM ingestion at scale, or upstream registry advisory streaming typically run an external worker against the public feeds and land the refreshed data on the engagement record through bulk-finding-import. The platform value is the consolidated record where every A06 finding (whether it came from native code scanning, bulk import from an outside SCA, or a manual finding entry against a runtime CVE) lives alongside the rest of the security backlog with the same lifecycle, the same RBAC, the same activity log, and the same evidence trail.
Related vulnerabilities and recommended reading
A06 is the parent category for a cluster of more specific findings and the upstream concern for several SecPortal workflows. The pages below cover the per-package finding shape, the frameworks that map control evidence against A06, and the programme workflows that hold the A06 backlog across detect, triage, prioritise, route, remediate, and verify.
- Vulnerable dependencies the per-package CVE finding shape that A06 most often surfaces in production, with detection, lockfile, and patch guidance.
- Hardcoded secrets an adjacent A07-class finding that often shares a code-scanning pass with A06 dependency analysis on the same engagement record.
- Insecure design (A04:2021) the upstream design-stage category that explains why a component-choice decision was made without an upgrade plan to begin with.
- Security misconfiguration (A05:2021) the adjacent deployment-stage category that often pairs with A06 when an outdated component is also misconfigured at runtime.
- NIST SSDF (SP 800-218) practice group PW.4 (acquire and maintain well-secured software) and PS.3 (protect components) are the federal practice mapping for A06 evidence.
- NIST SP 800-161 (C-SCRM) the cybersecurity supply chain risk management practices that wrap A06 component decisions inside an enterprise C-SCRM operating model.
- EU Cyber Resilience Act the regulatory consequence for product manufacturers that requires component documentation, vulnerability handling, and security update support across the product lifecycle.
- OWASP ASVS Chapter V14 (Configuration) and V14.2 (Dependency) are the verification standard sections that read against the controls A06 expects.
- OWASP SAMM the maturity model that surfaces the programme gaps (security testing, defect management, secure build) that generate repeat A06 findings.
- OWASP Top 10 explained the parent reference that sets A06 alongside the rest of the Top 10 and the changes from the 2017 list.
- Software bill of materials guide the practitioner-side guide to running SBOM-aligned vulnerability management as the inventory layer A06 reconciliation depends on.
- SAST vs SCA code scanning the technical comparison between source-code analysis and dependency analysis inside the same build pass.
- CISA secure software development attestation guide the US federal attestation that requires SBOM, vulnerability disclosure, and component-handling evidence from software suppliers.
- SLSA framework explained the build-integrity scaffold that pairs each release with a signed provenance attestation, so the components in production trace to a known build.
- Reachability analysis vulnerability prioritisation the prioritisation technique that separates exploitable A06 findings from the long tail of unreachable transitive CVEs.
- Risk-based vulnerability management buyer guide the buyer guide for the operating model A06 component findings flow through alongside the rest of the security backlog.
- Dependency vulnerability triage the engagement workflow that turns the SCA detection wall into a defensible queue of reachable risk with a closure cadence.
- SDLC vulnerability handoff the stage-gate workflow that moves A06 findings from AppSec to engineering owners without losing the trail back to the CVE source.
- Container image vulnerability remediation workflow the workflow for the container-base-image layer of A06 where OS packages drift independently of application code.
- SBOM management and VEX publishing the operational discipline that keeps the SBOM-VEX-finding triangle reconciled on one record across release cycles.
- Patch management coordination the cross-team coordination that schedules and verifies the patch work A06 prioritisation queues up.
- SecPortal for AppSec teams the audience overview for the teams that own A06 discovery, triage, and remediation across the application portfolio.
- SecPortal for vulnerability management teams the audience overview for the teams that aggregate A06 findings alongside the wider scanner-output backlog.
- SecPortal for product security teams the audience overview for product security organisations that ship components downstream and have to publish their own A06 evidence.
Compliance impact
OWASP ASVS
V14.2 Dependency requirements
OWASP SAMM
Verification (Security Testing) and Operations (Defect Management)
NIST SSDF
PW.4 Acquire & Maintain Well-Secured Software, PS.3 Protect Components
NIST SP 800-161
SR-3, SR-11 Component Authenticity & Integrity
ISO 27001
A.8.8 Technical Vulnerability Management, A.8.30 Outsourced Development
SOC 2
CC7.1 System Operations, CC8.1 Change Management
PCI DSS v4.0
Req. 6.3.2 Inventory of Bespoke and Custom Software, 6.3.3 Patch Vulnerabilities
EU Cyber Resilience Act
Article 13 Essential Requirements, Annex I Vulnerability Handling
Run A06 component findings on one engagement record
SecPortal records SAST and dependency findings from connected repositories, lands SBOM and outside-SCA output through bulk import, and keeps the A06 backlog visible alongside the wider security record. Start scanning for free.
No credit card required. Free plan available forever.