Most of the code running in your production environment was not written by your team. A typical service pulls in a handful of direct dependencies, each of which pulls in its own, and within two or three hops you are executing code from hundreds of maintainers you have never evaluated. That code runs with the same privileges as yours. It reads the same secrets, talks to the same databases, and ships in the same container. An attacker who wants access to your application has a choice: find a flaw in the code your engineers reviewed, or find a way into one of the packages nobody reviewed at all. Increasingly, they pick the second option — and a penetration test that only looks at your own source code will never see them coming.
The Attack Surface Nobody Owns
Supply chain compromise works because responsibility is diffuse. Your developers assume the package registry vets what it hosts. The registry assumes maintainers secure their own accounts. The maintainer of a widely used utility library is often one unpaid person with an email address from a decade ago and no multi-factor authentication. Nobody in that chain believes they are the security control, which is precisely why the chain breaks.
The practical consequence is that your threat model has to extend past your repository boundary. The questions worth asking are uncomfortable ones: what would happen if a dependency you have never heard of published a malicious minor version tonight? Would anything stop it from reaching production? Would anyone notice? For most organizations, the honest answers are "nothing" and "no."
How Attackers Actually Get In
The techniques are well established and require less sophistication than people assume.
- Typosquatting: An attacker publishes a package with a name one character away from a popular one and waits for a developer to fat-finger an install command. The malicious package runs install scripts with full shell access on a developer laptop or a build agent.
- Dependency confusion: If your build resolves package names against both a public registry and a private one, an attacker who learns your internal package names can publish a higher-versioned public package with the same name. Many resolvers will happily prefer it.
- Compromised maintainer accounts: Credential stuffing or phishing against a maintainer yields publish rights to a package with millions of downstream installs. The malicious version looks legitimate because, on paper, it is.
- Poisoned updates: Rather than attack the package, attack the build that produces it. If an adversary gets into a maintainer's CI pipeline, they can inject code into an artifact whose source repository stays completely clean.
- Transitive reach: You audit your twelve direct dependencies. The risk lives in the four hundred packages behind them, which no one has ever looked at.
What a Test Should Actually Assess
Covering supply chain risk means testing the machinery that assembles and delivers your software, not just the software itself. Serious application penetration testing should extend into several areas that traditional scoping tends to skip.
- Dependency provenance: Where does each artifact come from, is the resolution order deterministic, are lockfiles enforced in CI, and can an external package shadow an internal one?
- Pipeline security: Who can modify build definitions, can a pull request from a fork trigger a privileged workflow, and does a compromised build step reach production without human review?
- Secrets in build systems: CI runners are frequently the richest credential store in an organization — cloud keys, registry tokens, signing material — and are often far less monitored than production.
- Artifact integrity: Are builds reproducible, are artifacts signed, and does anything verify that the container you deploy is the one your pipeline produced?
- Blast radius: If a dependency executes arbitrary code at install or runtime, what does it reach? Egress controls and least privilege determine whether a compromise is an incident or a catastrophe.
The Case for an SBOM
A software bill of materials is not a compliance artifact to be generated once and filed. Its value is operational: when a widely used package is found to be malicious or vulnerable, the organizations that respond in hours are the ones that can answer "do we ship this, and where?" without convening a working group. Everyone else spends a week grepping repositories.
An SBOM is only as good as its freshness and coverage. Generate it at build time from what actually gets assembled, not from what a manifest claims. Include transitive dependencies and base image contents. Then make sure someone can query it under pressure — an inventory nobody can search during an incident is not an inventory.
Fitting This Into a Real Program
None of this replaces testing your own code. Injection flaws, broken authorization, and business logic abuse remain the findings that most often lead to real compromise, and they still require skilled manual work to surface. Supply chain assessment is additive: it asks whether the trusted path into your production environment is defensible, alongside the untrusted one. Our methodology treats these as parts of the same engagement, because an attacker does not care which category their entry point falls into.
The practical starting point is scope. If your last test stopped at the application boundary and never touched your CI configuration, package resolution, or artifact signing, you have tested half the problem.
Next Steps
If you are not sure whether a malicious dependency would reach production, contact us and we can walk through your build path. It is a short conversation that usually surfaces something worth fixing.