Software Supply Chain Security: SBOMs, Dependencies, and Third-Party Risk
Your software is mostly other people's code. Supply chain security is about knowing what you ship and proving it was not tampered with.
Almost no organisation writes most of its own software any more. A typical application is 70 to 90 percent third-party code by volume, pulled in transitively through package managers, base images, and build tooling. Securing the code your team writes addresses a minority of the risk.
The practical question supply chain security answers is simple and, in most organisations, currently unanswerable: when a widely used library is found to be malicious, which of our systems contain it and did it ever run in production?
Start with inventory: the SBOM
A software bill of materials is a machine-readable list of every component in a build, with versions and licences. Generate it automatically in the pipeline for every build — not periodically by hand — and store it alongside the artefact so it can be queried later.
Two details determine whether SBOMs are useful. Include transitive dependencies, because that is where the risk hides. And record the mapping from artefact to deployment, since knowing that version 4.2 contained a bad package is useless if you cannot tell which environments run 4.2.
Govern dependencies deliberately
- Pin and lock. Exact versions with lockfiles committed; floating version ranges make builds non-reproducible and allow silent introduction of new code.
- Use an internal proxy registry. A caching proxy protects against upstream package removal and gives you a single control point for blocking known-bad versions.
- Screen new dependencies. Check maintenance activity, maintainer count, download trends, and whether the package genuinely warrants adding. Single-maintainer packages that perform trivial functions are a recurring compromise vector.
- Watch for typosquats and dependency confusion. Register your internal package namespaces publicly and configure resolvers to prefer the internal registry.
- Update on a cadence. Automated dependency update pull requests with good test coverage beat annual bulk upgrades, which become too large to review.
Protect build integrity
| Control | Purpose |
|---|---|
| Ephemeral, isolated build runners | Prevents persistence and cross-build contamination |
| Least-privilege build credentials | Limits blast radius if the pipeline is compromised |
| Artefact signing and verification | Proves what you deploy is what you built |
| Provenance attestation | Records which source and pipeline produced the artefact |
| Protected branches and required review | Blocks unilateral code and pipeline changes |
| Pipeline configuration as reviewed code | Stops silent modification of build steps |
Build systems are high-value targets precisely because they hold credentials for everything downstream. Treat the CI environment with production-grade access control, not developer-grade convenience.
Vendor and commercial software assurance
The same logic extends to software you buy. Request SBOMs for commercial products, ask how vulnerabilities are disclosed and patched, and require contractual notification timelines for incidents affecting their code. For SaaS, the equivalent questions concern sub-processors, data location, and their own supply chain assurances.
Maintain a register mapping each vendor to the data and systems it can reach. When the next widely exploited platform vulnerability appears, that register determines whether triage takes hours or weeks.
Prepare the response, because it will happen
Write the runbook now: query SBOMs to find affected builds and environments, determine whether the compromised version executed in production, rotate every credential the build or runtime could reach, remove or pin the dependency, rebuild from verified source, and redeploy. Then confirm with logs whether exfiltration occurred.
Practise it once against a hypothetical package. Teams that have rehearsed this respond in a day; teams that have not spend a week establishing what they run.
Frequently asked questions
What is an SBOM?
A machine-readable inventory of every component, library, and dependency in a piece of software, including versions and licences, usually in SPDX or CycloneDX format.
Why prioritise supply chain over application code?
Because most application volume is third-party code, and a malicious or vulnerable transitive dependency affects you exactly as your own defect would — without visibility unless you maintain an inventory.
How do we respond to a compromised package?
Identify affected builds and environments from SBOMs, establish whether the version ran in production, rotate reachable credentials, remove or pin the dependency, and rebuild and redeploy from verified source.
Are SBOMs required by regulation?
Increasingly yes for suppliers to government and critical infrastructure, and commonly requested in enterprise procurement regardless of statutory obligation.