Juicy Shop
Vulnerable & Outdated Components
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
// package.json — floating ranges, no audit in CI
{
"dependencies": {
"express": "^4.0.0",
"lodash": "*"
}
}
// "works" today, silently pulls vulnerable versions laterWide ranges (* and loose ^) plus no scanning means a known-vulnerable transitive version can be installed without anyone noticing.
// 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.