Your team writes only part of the code it ships. The rest arrives through dependencies, build tooling, and third-party vendors. That is exactly where attackers have learned to spend their effort.
After a run of high-profile incidents, one lesson has landed with most engineering leaders. The perimeter of a modern application is not its network edge. It is the whole path a line of code travels: from an external maintainer, through a package registry, into a build system, out to production. Compromise any link and the attacker inherits your distribution. That is why supply chain security has climbed from a compliance footnote to a board-level concern.
Why the supply chain became the target
Attacking a well-defended application head-on is expensive. Attacking one of the many components it trusts is usually cheaper and quieter. A single compromised dependency reaches every organization that pulls it, so one intrusion becomes hundreds of downstream footholds. The economics favor the attacker, and the tooling to exploit them has matured.
Two shifts made this worse. First, applications now sit on deep trees of open-source code, most of it transitive and unreviewed. Second, build and delivery moved into automated pipelines that hold powerful credentials and run untrusted inputs on every commit. Both trends improved velocity, and both quietly widened the attack surface in ways that are easy to miss.
Mapping the modern attack surface
Before you pick controls, you need an honest map of where trust is being extended. The surface is wider than most inventories capture.
Open-source and transitive dependencies
The packages you declare directly are a small fraction of what you actually run. Transitive dependencies, pulled in several layers deep, are rarely reviewed and often maintained by one person with no formal security process. A compromise, or an abandoned project that gets hijacked deep in the tree, then behaves as trusted code inside your application.
Build and CI systems
Continuous integration is a prize target because it holds signing keys, registry tokens, and cloud credentials while running code from every branch and pull request. A build step an attacker can influence is effectively remote code execution with production-grade permissions attached.
Package registries and typosquatting
Public registries are convenient and largely open. Attackers work that openness with typosquatted names, dependency confusion against internal package names, and takeovers of legitimate maintainer accounts. The install step trusts whatever it is told to fetch, and a plausible name is often enough.
Third-party vendors and integrations
SaaS tools, agents, and integrations that touch your source code or CI push your trust boundary outward. Their weakest access token is now part of your risk model, whether or not it shows up on your architecture diagram.
Controls that meaningfully reduce risk
The goal isn't to eliminate external code. It's to make trust explicit, verifiable, and revocable. A handful of controls do most of the work.
- A software bill of materials (SBOM). You can't defend what you can't list. A generated, machine-readable inventory of every component and version turns the next disclosed vulnerability from a frantic search into a quick lookup.
- Dependency pinning and review. Pin versions and hashes so builds are reproducible and a swapped artifact stands out. Route new and updated dependencies through review instead of letting them flow in on their own.
- Artifact signing and provenance. Sign what you build, and record where and how it was built. Frameworks such as SLSA define provenance levels that let downstream consumers verify an artifact came from your pipeline and not a stand-in.
- Least-privilege CI/CD. Scope build credentials tightly, keep untrusted pull-request builds away from privileged steps, and favor short-lived, narrowly scoped tokens over long-lived secrets. It's the same principle behind zero trust architecture, applied to your delivery pipeline.
- Vendor security review. Check the security posture of any tool that touches your code or CI before you grant access, and revisit that access on a schedule. Independent attestations like the ones covered in SOC 2 versus ISO 27001 are a useful signal, but treat them as a starting point, not a guarantee.
The most useful thing you can do is know what you actually ship. An SBOM plus reproducible, pinned builds turns most future incidents from open-ended investigations into bounded questions you can answer, and it makes every other control easier to apply.
A practical priority order
A growing company can't adopt every control at once, and pretending otherwise just buys shelfware. Sequence the work so each stage pays off on its own.
- Gain visibility. Generate an SBOM and turn on dependency vulnerability alerts. Nothing else matters if you can't answer whether a disclosed flaw affects you.
- Make builds trustworthy. Pin dependencies, lock down CI permissions, and clear out standing secrets. This closes the highest-impact paths an attacker would take to reach production.
- Add provenance and review. Sign artifacts, set a provenance baseline, and require review for dependency changes. This raises the cost of substitution and account-takeover attacks.
- Formalize vendor governance. Once your own house is in order, extend the same rigor to the third parties whose access already sits inside your boundary.
Each step stands on its own, and each makes the next one cheaper. Teams that try to buy their way to the end state without visibility usually end up with tooling they can't act on.
Supply chain security isn't a project with a finish line. It's an ongoing discipline: know what you depend on, verify how it was built, and constrain what your automation can do on your behalf. If your team is planning this work and wants a defensible sequence for its own environment, reach out to us and we'll talk it through.
Back to blog