Vulnerability library  /  Outdated components
CWE-1104OWASP A06:2021 Vulnerable and Outdated Components

Vulnerable and outdated components

Outdated components

Applications inherit risk from unsupported or vulnerable libraries, frameworks, runtimes, images, appliances, and services. A reachable weakness in one component can compromise the entire application or its supply chain.

Also known as
Known vulnerable dependencies · Unsupported software · Dependency vulnerabilities · Unpatched components
Typical severity · Low to Critical
Last updated
On this page: What it is
  1. 1 · What it is
  2. 2 · Why it matters
  3. 3 · Examples
  4. 4 · How to fix it
  5. 5 · How to test for it
  6. References

What it is#

Applications are assembled from open-source packages, commercial libraries, operating-system packages, container images, runtimes, browser code, infrastructure modules, services, and appliances. Each component has its own support and vulnerability lifecycle.

The finding applies when a component is known to be vulnerable, no longer supported, cannot be inventoried, or is not updated within the organization's risk-based timeframe. Version age alone is not proof of exploitability, and a scanner match alone is not proof that vulnerable code is reachable. Both require validation.

Transitive dependencies and embedded software are easy to miss because the organization did not select them directly.

Why it matters#

  • Remote code execution, authentication bypass, data exposure, or denial of service inherited from a dependency.
  • Compromise through an internet-facing appliance or unsupported runtime.
  • Supply-chain risk from abandoned packages, malicious updates, or unverified artifacts.
  • Long remediation windows when ownership, inventory, or upgrade paths are unclear.
  • Repeated reintroduction of vulnerable versions through old images, lockfiles, or deployment templates.
Typical severity

Severity depends on the specific vulnerability, reachability, privileges, exposed data, and available mitigations. A low-risk outdated package and an actively exploited internet-facing component should not receive the same priority. Actual severity depends on context: who is affected, what data or actions are reachable, and existing controls.

Examples#

✕ Vulnerableyaml
# Vulnerable: installs non-reproducible dependencies and suppresses review.
- name: Install dependencies
  run: npm install --no-audit
✓ Fixedyaml
# Fixed: use the reviewed lockfile, generate an inventory, and gate risk.
- name: Install reviewed dependencies
  run: npm ci

- name: Generate software bill of materials
  run: npm sbom --sbom-format spdx > sbom.spdx.json

- name: Check production dependencies
  run: npm audit --omit=dev --audit-level=high

An audit command is one input, not the entire program. Findings still require ownership, reachability analysis, remediation tracking, and independent scanning of images and operating-system packages.

How to fix it#

1. Maintain a complete inventory. Generate an SBOM for applications and images. Include direct, transitive, build-time, client-side, operating-system, firmware, appliance, and infrastructure components.

2. Use supported versions. Track end-of-support dates for languages, frameworks, databases, operating systems, devices, and managed services. Upgrade before security support ends.

3. Pin and verify artifacts. Use lockfiles, trusted registries, integrity verification, protected build pipelines, and controlled update sources. Make builds reproducible.

4. Scan continuously. Check source dependencies, containers, hosts, deployed services, and infrastructure during development and after deployment. New vulnerability information can affect unchanged software.

5. Prioritize by real risk. Consider internet exposure, known exploitation, reachable code, required privileges, available mitigations, asset sensitivity, and CISA's Known Exploited Vulnerabilities Catalog.

6. Patch or upgrade promptly. Prefer a supported fixed release. Backporting and virtual patching are temporary measures that require ownership, testing, and expiration.

7. Remove what is unused. Delete abandoned packages, sample applications, build tools from runtime images, unused plugins, and legacy endpoints.

8. Automate update proposals. Use dependency update services with tests and staged rollout. Do not automatically deploy unreviewed major updates to production.

9. Track exceptions. Record the affected assets, risk, compensating controls, owner, target date, and evidence required to close the finding.

10. Rebuild and redeploy. Updating a manifest is not enough if old images, hosts, caches, or artifacts remain live.

How to test for it#

  • Generate inventories from manifests, lockfiles, built artifacts, container layers, hosts, browser bundles, and running services.
  • Run more than one relevant data source or scanner and manually validate high-impact matches.
  • Confirm package identity and version from the deployed artifact, not only the source repository.
  • Determine whether affected code is included, configured, reachable, and exposed; document uncertainty rather than assuming either safety or exploitation.
  • Compare internet-facing components and appliances with authoritative vendor advisories and the CISA KEV catalog.
  • Review end-of-support dates and update ownership for runtimes, operating systems, databases, and devices.
  • After remediation, rebuild from a clean environment, redeploy, rescan the live asset, and remove superseded artifacts.
  • Test rollback and emergency-patching procedures before a critical vulnerability requires them.

References#

Permalinklibrary.infinity8labs.com/vulnerable-outdated-components/JSON
Found this in Breachvane? Your finding links here for background. Evidence, affected assets and retest status are in your Breachvane ↗ (opens in a new tab) workspace. Need help fixing it? Talk to us.