Building software today is closer to assembly than authoring. The code we write ourselves is only a slice; most of the rest is open-source libraries and the dependencies those libraries pull in. As convenient as that is, attackers know it’s more efficient to target the “parts” we trust than the code we wrote. This is a calm look at supply-chain security and open-source vulnerability management, from a tester’s view.
More of someone else’s code than your own
Libraries you install directly are visible, but the “transitive dependencies” they in turn pull in are not — and the risk often lives in that unseen depth. Here’s a shape we meet often.
your-app
├─ web-framework@2.4
│ └─ json-parser@1.1 ← direct dep (you installed it)
│ └─ legacy-utils@0.9 ← transitive (came along uninvited)
│ └─ [CVE-20XX-XXXX] deserialization RCE ★ risk is here
└─ image-lib@3.2
└─ native-decoder@0.5 ← known buffer overflowNobody installed legacy-utils@0.9 directly, yet it sits quietly three levels down. “We don’t even know what we’re running” is the first challenge of supply-chain security.
How supply-chain attacks get in
Type | One-line description |
|---|---|
Transitive CVE | A known flaw lingers in an old package deep in the tree |
Typosquatting | A malicious package with a near-identical name gets installed by mistake |
Dependency confusion | An internal name published publicly tricks the build into pulling it |
Compromised package | Malicious code slipped into a new version of a legitimate package |
Build-pipeline compromise | Code injected into artifacts via CI/CD or build tooling |
SBOM — start by knowing what you use
Management starts with an inventory. An SBOM (Software Bill of Materials) is a spec of “which components and versions make up this software.” Knowing that lets you answer “are we affected?” within minutes when a new vulnerability drops.
# 1) inventory what you use (generate an SBOM)
syft dir:. -o cyclonedx-json > sbom.json
# 2) cross-check against known vulnerabilities
grype sbom:sbom.json
osv-scanner --sbom sbom.json
# result: component → version → matching CVE → severityNot just versions — is it actually exploitable?
A scanner tells you “this version is vulnerable.” Whether it’s actually exploitable in your environment is another question. Priority comes from whether the vulnerable function is on a real call path (reachability) and whether external input reaches it. So we re-check identified components with a 1-day mindset — reading the public patch in reverse to prove, within a controlled scope, whether it truly exploits here. That’s exactly where a targeted attacker (APT) aims. (Discovery in How 0-days Are Found; testing flow in our pentest process post.)
Not once, but ongoing
Regenerate the SBOM each build so a new CVE automatically answers “are we affected?”
Prioritize by reachability and exposure, not the count of “old versions”
Keep a light policy to check source, signature, and reputation when adding a new dependency
Field note: tracing “how did they get in” after an incident, the entry is often a transitive dependency someone added three years ago. It’s no one’s fault — which is why simply knowing “what you use” day to day dramatically speeds up response.
FAQ
We already run a dependency scanner — do we need this?
Catching the inventory and known CVEs with a scanner is a great start. Adding a human layer of “is it actually exploitable here?” makes it clear what to fix first.
Are we safe if we avoid open source?
Avoiding open source entirely is impractical and unnecessary. The key is a system to know what you use and respond quickly.
Closing
Knowing whether the parts you lean on are safe is now close to a security fundamental. To review your components and dependencies through an APT lens together, reach out at penetration testing. We’ll start, calmly, from “what you use.”