Juicy Shop

← All lessons

Vulnerable & Outdated Components

Supply ChainA06:2021 – Vulnerable and Outdated Componentsintermediate10 min

Your app is only as secure as its weakest dependency. Learn how known-vulnerable packages get exploited and how SBOMs, pinning, and automated scanning keep your supply chain honest.

You ship your dependencies' bugs

A modern app is mostly third-party code: frameworks, parsers, crypto libraries, transitive dependencies you never chose directly. When one of them has a published CVE, every app using that version is exploitable — often with a ready-made proof of concept. Attackers scan the internet for known-vulnerable versions because it is far easier than finding a new bug.

Know what you run

You cannot patch what you cannot see. Maintain a Software Bill of Materials (SBOM) — the full, resolved dependency tree including transitive packages. Lockfiles (pnpm-lock.yaml) pin exact versions so builds are reproducible and so a scanner can map every installed version to known advisories.

Detect and update continuously

Run automated dependency scanning in CI (pnpm audit, GitHub Dependabot/advisory database, Snyk). Treat a high-severity advisory in a production dependency as a build-breaking event. Schedule routine updates rather than letting versions rot — a six-month-old major version is far riskier and harder to upgrade than a steady stream of small bumps.

Reduce and verify the supply chain

Fewer dependencies means fewer advisories to track — prefer the standard library or a small, well-maintained package over a sprawling one. Pin and verify integrity (lockfile hashes), be wary of typosquatted package names, and avoid abandoned packages with no security maintenance. Integrity checks also defend against tampered registry artifacts.

Insecure vs secure

✗ insecure
// package.json — floating ranges, no audit in CI
{
  "dependencies": {
    "express": "^4.0.0",
    "lodash": "*"
  }
}
// "works" today, silently pulls vulnerable versions later

Wide ranges (* and loose ^) plus no scanning means a known-vulnerable transitive version can be installed without anyone noticing.

✓ secure
// committed lockfile + CI gate
// pnpm-lock.yaml pins exact, hash-verified versions
//
// .github/workflows/ci.yml
//   - run: pnpm audit --audit-level=high
//   - uses: dependabot (weekly update PRs)

Exact, hash-verified versions make builds reproducible, and an audit gate fails CI on high-severity advisories so issues are caught before release.

Key takeaways

  • Known-vulnerable dependencies are among the easiest things to exploit.
  • Maintain an SBOM and commit a lockfile so you know exactly what you run.
  • Gate CI on dependency scanning (pnpm audit / Dependabot / Snyk).
  • Update steadily; don't let versions rot into risky big-bang upgrades.
  • Fewer, well-maintained, integrity-verified dependencies shrink the risk.

Knowledge check

Further reading