Supply Chain Risk Analysis

Every dependency is code you didn't write running with your privileges, maintained by people you don't know, pulled through infrastructure you don't control. The trust you extend is transitive and usually invisible.

Map the real dependency graph

1. Transitive, not direct: your 20 direct dependencies pull hundreds of transitive ones. The risk lives in the deep, unfamiliar, single-maintainer packages you've never heard of.
2. Execution context: which dependencies run at build time (highest risk — full pipeline access), at runtime in the server (privileged), or in the client (different exposure)? A compromised build-time package owns everything.
3. Trust concentration: identify single-maintainer, unmaintained, or recently-transferred packages. A popular package handed to a new owner is a classic injection vector.

The attack vectors

• Malicious package: typosquatting, dependency confusion (internal name resolved to public registry), or a maintainer account takeover pushing a backdoored version.
• Compromised update: a previously-good package ships a malicious version (the "your dependency updated overnight" risk). Unpinned versions auto-pull it.
• Build pipeline compromise: CI tokens, cached artifacts, and build scripts run untrusted code (especially install hooks/postinstall scripts) with production credentials.
• Transitive vulnerability: a CVE three levels deep that your direct deps drag in.

Adversarial validation

• Dependency confusion test: do internal package names resolve to a public registry if an attacker registers them? This is a one-command takeover for many orgs.
• The postinstall question: which dependencies run scripts at install time? Those execute arbitrary code on every developer machine and CI run — on install, before any review.
• Pin and verify: are versions pinned with integrity hashes (lockfile), or floating (^, latest) so a compromised release auto-deploys? Is the lockfile actually enforced in CI?
• Blast radius of one bad package: if the most-trusted build-time dependency were backdoored today, what would it exfiltrate or inject, and would you detect it?
• Provenance: can you verify the artifact you run was built from the source you reviewed (signed builds / SLSA), or are you trusting the registry blindly?

Non-obvious risks

• "Number of GitHub stars" is not a security signal; popular packages are higher-value targets, not safer.
• Removing a dependency you wrote yourself in 20 lines often beats adding one with its own dependency tree — the smallest dependency has the largest hidden graph.
• Vulnerability scanners report known CVEs (lagging) and miss novel malicious packages and intentional backdoors entirely.

Output structure

Deliver: the dependency graph by execution context (build/server/client), the high-risk packages (single-maintainer, unmaintained, install-hooks), the dependency-confusion and pinning/integrity check, the blast radius of a compromised build-time dependency, the provenance/signing gap, and a prioritized hardening list (pin, scope CI tokens, vendor or remove risky deps).