Dependency and Supply-Chain Risk
Modern software is mostly other people's code — open-source dependencies pulled in by the hundreds — and every one is code you ship and must trust. A vulnerability in a dependency (Log4Shell) or a malicious package (typosquats, hijacked maintainers) becomes your vulnerability, and the attacker knows it.
This topic covers software supply-chain risk at the level a security-conscious team must handle it: knowing what you depend on, catching known-vulnerable and malicious packages, and verifying integrity — with the deeper pipeline hardening handed to DevSecOps.
Your Dependencies Are Your Attack Surface
Transitive dependencies mean you run far more third-party code than you directly chose — a package you added pulls in dozens you never named. A single vulnerable or malicious package deep in that tree is a real entry vector (the initial access of Chapter 5), so the whole tree must be managed, not just the handful of direct dependencies you can see.
Known-Vulnerable Components
Dependencies with published CVEs are one of the OWASP Top 10 categories. Software composition analysis (the next topic) and dependency scanners flag them, and the fix is updating — which means you must be able to update, not pinned to abandonware. The lesson of Log4Shell was less about one library than about how many organizations could not even answer "are we affected?" quickly.
Malicious Packages
Some packages are built or hijacked to attack you: typosquatting (a package one character off a popular name), dependency confusion (a public package shadowing your internal one), and hijacked maintainer accounts that push a backdoored update. Scanners for known CVEs will not flag brand-new malicious code — the defenses are pinning versions, verifying sources, preventing dependency confusion, and reviewing new dependencies.
Knowing What You Ship — SBOM and Provenance
A software bill of materials lists every component so that when the next Log4Shell drops, you can answer "are we affected?" in minutes rather than weeks. Provenance and signing (SLSA, Sigstore) verify that a package is what it claims, from where it claims. Meridian's dependency hygiene is concrete: generate an SBOM, scan continuously, pin and verify versions, vet new dependencies, and keep a fast path to patch a critical dependency CVE — closing the vector the intruder could have used.
Known-vulnerable — legitimate packages with a discovered CVE; the code is not hostile, it is flawed. Caught by SCA and scanners, fixed by updating.
Malicious — packages built or hijacked to attack you (typosquat, dependency confusion, backdoored update). Caught by source verification, pinning, provenance, and review — CVE scanners will not flag brand-new malicious code. You need defenses against both.
- No inventory of dependencies (no SBOM), so when a critical dependency CVE drops you cannot tell if you are affected.
- Never updating dependencies, or pinning to abandoned ones, so known-vulnerable components pile up unpatched.
- Pulling in packages by name without verifying source or integrity, exposing you to typosquats and dependency confusion.
- Treating only direct dependencies as your surface while the transitive majority goes unmanaged.
- Having no fast path to patch a critical dependency CVE when one lands.
- Maintain an SBOM so you can answer "are we affected?" instantly when a component CVE lands.
- Scan dependencies continuously (SCA) and keep them updatable and updated; treat dependency CVEs on the same exposure and exploitation basis as Chapter 7.
- Defend against malicious packages: pin and verify versions, prevent dependency confusion, verify provenance and signatures, and review new dependencies.
- Manage the full transitive tree, not just direct dependencies, and keep a fast critical-patch path.
- Prefer well-maintained dependencies you can actually update over abandoned ones you cannot.
Knowledge Check
Why are your transitive dependencies part of your attack surface?
- You run code you never chose, and a deep flaw is a real way in
- Only dependencies you import directly can contain vulnerabilities
- Transitive dependencies never actually run in production builds
- Dependencies are the vendor's responsibility, not yours
Why won't a CVE scanner catch a freshly published malicious package?
- They flag documented vulnerabilities, not brand-new code with no CVE yet
- Malicious packages are always published slightly older than their own assigned CVEs
- Scanners only work on internal packages
- Malicious packages cannot be installed by a build
What is the primary value of a software bill of materials (SBOM)?
- When a new dependency CVE drops, you can answer "are we affected?" in minutes instead of weeks
- It encrypts the dependencies at build time
- It automatically patches every vulnerable dependency
- It removes all transitive dependencies from the build
You got correct