█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Application Security/OWASP A06: Vulnerable and Outdated Components
40 minIntermediate

OWASP A06: Vulnerable and Outdated Components

After this lesson, you will be able to: Recognize, find, and fix Vulnerable and Outdated Components (OWASP A06): using libraries, frameworks, or runtimes with known vulnerabilities.

Vulnerable and Outdated Components is OWASP A06: modern apps are mostly other people's code (dependencies), and a known CVE in any of them is your vulnerability. This is one of the easiest categories to exploit (the exploit is often public) and one of the easiest to fix (update the dependency).

Prerequisites:Security Misconfiguration

What it is

Every app pulls in dozens to thousands of dependencies (npm, pip, Maven, OS packages, the framework, the runtime). When one has a published vulnerability (a CVE), and you are running the affected version, attackers can use the public exploit against you. The risk compounds because dependencies have their own dependencies (transitive), and teams often do not know their full software bill of materials or how old it is.

💡 Real-world breach

Equifax (2017) exposed the personal data of about 147 million people because they ran a version of Apache Struts with a known, publicly-disclosed critical vulnerability (CVE-2017-5638). A patch had been available for two months. Attackers used the public exploit to gain remote code execution. It is the canonical example of an outdated component causing a catastrophic breach.

How to find it

This category is largely automatable.

  1. 1

    Generate a software bill of materials (SBOM): know every dependency and version.

  2. 2

    Run dependency scanners: `npm audit`, `pip-audit`, OWASP Dependency-Check, Snyk, or GitHub Dependabot alerts.

  3. 3

    Scan container images (Trivy, Docker Scout) for vulnerable OS packages and libraries.

  4. 4

    Check the runtime/framework version against its end-of-life and known CVEs.

  5. 5

    Wire these scans into CI so a new critical CVE in a dependency surfaces on every build.

How to fix it

Update, automate, and remove what you do not use.

bash
# FIND known-vulnerable dependencies
npm audit # Node
pip-audit # Python
trivy image myapp:1.2.3 # container image
# FIX
npm audit fix # apply safe updates
# then bump remaining flagged packages to a patched version + retest
# PREVENT (the durable fix)
# - Enable Dependabot / Renovate to open update PRs automatically.
# - Fail CI on High/Critical CVEs (e.g. trivy --exit-code 1 --severity HIGH,CRITICAL).
# - Remove unused dependencies (less code = fewer CVEs).
# - Track end-of-life: don't run an unsupported framework/runtime.
Quick Check

Why is 'vulnerable and outdated components' both easy to exploit and easy to fix?

Pick the best answer.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←OWASP A05: Security Misconfiguration
Back to Application Security
OWASP A08: Software and Data Integrity Failures→