Install a package with a mistyped name and you may have run somebody else’s code as part of your build, with whatever credentials that build holds. Package registries are open by design, names are cheap, and installation scripts execute automatically. ENISA’s threat landscape work on supply chain attacks made the point plainly: attackers target suppliers and dependencies because the trust is already established.
Two attacks that look identical from the inside
Typosquatting relies on a human mistake: a package named one character away from a popular library, published and waiting. Dependency confusion relies on a tooling default. If your organisation uses an internal package named after your company and a public package appears with the same name and a higher version number, some package managers will fetch the public one because they treat the registries as a single namespace. Both end the same way, with unreviewed code running during installation. The install-time script is the mechanism worth understanding, because it runs before any of your tests do.
What the attacker gets from a build agent
Build machines are a good target because of what they hold rather than what they run. A typical agent carries repository credentials, a cloud token, a package registry key for publishing, and network access to internal systems that developer laptops cannot reach. Code executing during a dependency install inherits all of it. Worse, output is rarely inspected, so a script that quietly copies environment variables to a remote host produces a green build. That is why the compromise usually surfaces weeks later through the credentials rather than through the build itself.
“Ask your development team a simple question: if a dependency ran arbitrary code during the next build, what would it be able to reach? Most teams discover the answer is the production deployment key. Ephemeral agents, scoped tokens and a private registry that refuses to fall through to the public one turn that answer into something much less alarming.”
William Fieldhouse, Director, Aardwolf Security Ltd
Controls that actually reduce the risk
Run everything through a private registry that proxies the public one, and configure it so internal package names are never resolved upstream. Pin dependencies with a lockfile and verify hashes, so an unexpected version cannot arrive quietly. Disable install scripts where your ecosystem allows it, and where it does not, run builds on short-lived agents that are destroyed afterwards. Give the pipeline scoped, short-lived credentials rather than a permanent key, and keep publishing credentials on a separate identity from the one that builds. None of this is expensive, and most of it is configuration rather than new tooling.
Keeping visibility over what you ship
You should be able to list what is in a release without reading the code. A software bill of materials produced at build time gives you that list, and it turns an advisory about a popular library into a five minute query rather than a week of investigation. Review new dependencies before adoption, with attention to how recently the package appeared and whether the maintainer changed. Pair that with regular vulnerability assessmentsof the systems the pipeline touches, and web application penetration testsof what you deploy, since a vulnerable dependency only matters once it is reachable in a running application.
Frequently asked questions about dependency risk
These questions come up whenever a supply chain incident makes the news.
Does an audit command cover this?
Only partly. Those tools compare your dependency list against known vulnerability data, which says nothing about a brand new malicious package that has never been reported.
Is pinning versions enough?
It stops surprises from upgrades and does not help if the pinned version was malicious when you added it. Combine pinning with a review step for new dependencies and a registry that controls what can be fetched.
