Outdated Components

OWASP Top 10

Course 1 · Chapter 6 · A06: Vulnerable & Outdated Components

Every category so far has been about your code or your configuration. A06 is about everyone else's: the open-source libraries, frameworks, runtimes, and packages your application depends on. Modern apps are mostly other people's code — a typical project pulls in hundreds or thousands of dependencies — and a vulnerability in any one of them is a vulnerability in your app, even if your own code is flawless.

A06: Vulnerable & Outdated Components

This category covers using components (libraries, frameworks, servers, OS packages, container images) that are out of date, unsupported, or have known vulnerabilities. The defining feature: you didn't write the vulnerable code, but you shipped it. And because the vulnerable component is public and widely used, the exploit is public too — attackers scan for known-vulnerable versions at internet scale.

Why It's Uniquely Dangerous: Known & Weaponized

A known CVE in a popular component is a published exploit waiting for a scanner
The hallmark of A06 is that the vulnerability is publicly known — it has a CVE, a description, often proof-of-concept exploit code, and a patch. That cuts both ways: defenders could fix it, but attackers have a ready-made exploit and a way to find every unpatched target. Automated scanners crawl the internet fingerprinting component versions (from headers, error pages, JS files, default paths) and fire known exploits at anything outdated — no skill required. So an unpatched component isn't a theoretical risk; it's a countdown. The window between a CVE's disclosure and mass exploitation is often days or hours.

The Canonical Example: Log4Shell

In December 2021, a critical vulnerability (Log4Shell, CVE-2021-44228) was found in Log4j, a ubiquitous Java logging library. A crafted string in anything that got logged (a username, a User-Agent header) triggered remote code execution. Because Log4j was buried as a transitive dependency in a staggering number of applications and devices, millions of systems were instantly exploitable — many run by organizations that didn't even know they used Log4j. It's the perfect illustration of A06: a flaw in someone else's code, deep in the dependency tree, turning flawless applications into RCE targets overnight.

Transitive Dependencies: The Iceberg

The reason A06 is so pervasive is the dependency tree. You add one package; it depends on ten others, which depend on more, and so on. The components you chose (direct dependencies) are the tip; the vast majority are transitive — pulled in indirectly, often unknowingly.

# you installed 1 package — but your app actually ships dozens/hundreds your-app └─ web-framework # direct (you chose it) ├─ template-engine # transitive ├─ logging-lib ← # a Log4Shell-style flaw could live HERE, unseen └─ http-parser └─ ...deeper... # you never explicitly added these

You can't patch what you don't know you have — which is why visibility into the full tree is the first defence.

The Defences

  • Inventory everything — maintain a Software Bill of Materials (SBOM): a complete list of all components and versions, direct and transitive. You can't secure what you can't see.
  • Scan continuously — use Software Composition Analysis (SCA) tools (Dependabot, Snyk, OWASP Dependency-Check, npm audit, etc.) to flag dependencies with known CVEs, ideally in CI on every build.
  • Patch promptly — keep components updated; treat critical-CVE patches as urgent. A documented, fast update process is the core control.
  • Remove what you don't use — unused dependencies, features, and components are pure attack surface; prune them.
  • Use maintained, reputable sources — prefer actively-maintained components from official repositories; avoid abandoned or unofficial packages.
  • Monitor advisories — subscribe to security feeds (CVE/NVD, GitHub Security Advisories) for your stack so you hear about a Log4Shell on day zero, not day thirty.
A06 shades into supply-chain security — the components themselves can be malicious
Beyond outdated components, the modern frontier is supply-chain attacks: the dependency isn't just vulnerable, it's compromised. Examples include typosquatting (a malicious package named like a popular one — reqeusts vs requests), dependency confusion (tricking a build into pulling an attacker's public package instead of your private one), and compromised maintainer accounts pushing a malicious update to a trusted package (the event-stream and SolarWinds incidents). Defences extend accordingly: pin exact versions and use lockfiles, verify integrity hashes, vet new dependencies before adding them, use private registries with namespacing, and — connecting to A08 — protect the build pipeline that pulls them in. The trust you place in a dependency is trust in everyone who can publish to it.

Hands-On Exercises

Exercise 1

Explain why a vulnerability in a third-party component is uniquely dangerous compared to a bug in your own code, focusing on "publicly known + weaponized + internet-scannable." Use Log4Shell to illustrate why transitive dependencies make it worse.

📄 View solution
Exercise 2

Describe a practical A06 defence program: SBOM, SCA scanning in CI, patching process, removing unused deps, advisory monitoring. Explain what each step addresses and why "we'll update when we get around to it" fails given how fast known CVEs are exploited.

📄 View solution
Exercise 3

Distinguish "vulnerable/outdated components" from "supply-chain attacks," with an example of each (a known CVE vs typosquatting/dependency confusion/compromised maintainer). List the additional defences supply-chain risk needs (lockfiles, integrity hashes, vetting, private registries) and how this connects to A08.

📄 View solution

Chapter 6 Quick Reference

  • A06 Vulnerable & Outdated Components — shipping libraries/frameworks/runtimes that are outdated, unsupported, or have known CVEs; you didn't write it, but you shipped it
  • Uniquely dangerous: the flaw is publicly known + weaponized + internet-scannable — attackers fingerprint versions and fire ready-made exploits at scale
  • Log4Shell (CVE-2021-44228) — a logged string → RCE in ubiquitous Log4j; millions exposed via a deep transitive dependency
  • Transitive dependencies — most of your components are pulled in indirectly/unknowingly; you can't patch what you can't see
  • Defences: SBOM (inventory all components) · SCA scanning in CI (Dependabot/Snyk/npm audit) · patch promptly · remove unused deps · use maintained sources · monitor advisories
  • Supply-chain frontier: components can be malicious — typosquatting, dependency confusion, compromised maintainers; defend with lockfiles, integrity hashes, vetting, private registries
  • Connects to A08 (pipeline/build integrity) — protect what pulls the dependencies in
  • Next chapter: A07 Identification & Authentication Failures (→ the Auth course)