A typical web application ships with hundreds of third-party packages, each one written, published, and maintained by someone outside your organisation. Attackers have noticed.
How Supply Chain Attacks Work
Rather than attacking your hardened perimeter, attackers compromise something you already trust: a popular package gets a malicious maintainer, a typosquatted name catches a hurried npm install, or a build pipeline is poisoned upstream. The malicious code then runs with the full privileges of your application.
Practical Defences
- Lock and verify. Commit lockfiles, pin versions, and verify integrity hashes in CI.
- Reduce the surface. Audit direct dependencies periodically — every package you drop removes a subtree of transitive risk.
- Watch behaviour, not just CVEs. Vulnerability scanners catch known issues; unexpected network calls or install scripts from a minor version bump are the supply chain signal that matters.
- Isolate build systems. CI runners with production credentials are a favourite target. Scope tokens tightly and expire them fast.
Testing the Whole Picture
Application-level penetration testing should include how your application ingests and trusts third-party code — because your attacker won't respect the boundary between "your code" and "your dependencies".