Accueil / retour à la liste

Vulnerable and Outdated Components

6) Vulnerable and Outdated Components

What it is

This means your app uses software pieces (libraries, frameworks, plugins, containers, OS packages) that have known security bugs.

Attackers do this:

  1. Find your component version.
  2. Check public CVEs/exploits.
  3. Use ready-made exploit code.
  4. Compromise your app.

So even if your own code is okay, a weak dependency can break everything.

Where risky components come from

  1. Direct dependencies in your app (package.json, requirements.txt, etc.).
  2. Transitive dependencies (dependency of your dependency).
  3. Container base images.
  4. Web server/runtime packages.
  5. Frontend JS packages/CDN imports.
  6. CI/CD tools and plugins.

Step-by-step attack example

  1. Your app uses library X version 1.2.0.
  2. 1.2.0 has a known RCE CVE.
  3. Attacker fingerprints your app headers/error behavior.
  4. Attacker sends crafted payload that targets that CVE.
  5. Library executes malicious input.
  6. Attacker gets code execution / data access / lateral movement.

Why this happens

  1. No asset/dependency inventory.
  2. Teams only patch app code, not dependencies.
  3. Fear of breaking changes delays updates.
  4. “It works, don’t touch it” mindset.
  5. Transitive dependencies are ignored.
  6. End-of-life software still in production.

Tricky concepts explained

1) Direct vs transitive dependencies

  1. Direct: you added it yourself.
  2. Transitive: installed automatically because another package needs it.

Important:

  1. Many real breaches come from transitive packages.
  2. “We never installed it directly” is not protection.

2) CVE, CVSS, and real risk

  1. CVE = public vulnerability ID.
  2. CVSS = severity score (technical impact).
  3. Real risk also depends on exploitability and your exposure.

So patch priority should consider:

  1. Internet exposure
  2. Exploit availability
  3. Privileges required
  4. Business criticality

3) EOL (End of Life)

EOL software no longer gets security fixes. Using EOL means new bugs may stay permanently unpatched.

4) SBOM

SBOM (Software Bill of Materials) is a full list of components and versions in your app. Without SBOM, incident response is slow because you don’t know where vulnerable packages exist.

How to prevent it (practical program)

  1. Keep an up-to-date dependency inventory (prefer SBOM).
  2. Run SCA scanning in CI on every pull request.
  3. Block merges for critical/high vulns unless risk-approved.
  4. Patch on a fixed cadence (weekly/biweekly) plus emergency patch path.
  5. Use version pinning and lockfiles for reproducible builds.
  6. Remove unused dependencies aggressively.
  7. Prefer well-maintained libraries with active security response.
  8. Scan container images and OS packages, not only app libraries.
  9. Track EOL dates for frameworks/runtimes and plan upgrades early.
  10. Add compensating controls when patching is delayed (WAF rules, feature disable, network isolation).
  11. Sign and verify artifacts where possible.

Detection checklist

  1. Do we know every dependency and version in production?
  2. Are transitive dependencies scanned too?
  3. Are container base images scanned and updated?
  4. Any EOL frameworks/runtimes in use?
  5. Is there an SLA for patching critical CVEs?
  6. Do we have an emergency patch playbook?
  7. Are exceptions documented with expiration dates?

Business impact

  1. Remote code execution and full compromise.
  2. Large data breaches from known, preventable issues.
  3. Fast attacker success using public exploit kits.
  4. Audit/compliance failures and incident costs.