Reference · Software supply chain security
Software supply chain security: the map, and where to start
The phrase covers several distinct jobs. Seen separately, it becomes clear what each tool gives you, what good looks like in each part, and the order in which each step makes the next one worth more.
Updated 12 Oct 2026 · by the depproof team
In one sentence: software supply chain security is knowing and managing everything that goes into your product and everything that carries it to your customer: what you depend on, where it comes from, how it is built, what you ship, and what you can show about all of it.
What is a software supply chain?
A software supply chain is everything that goes into your software before it reaches a customer, and everything that carries it there: the third-party packages your application depends on, the packages those depend on in turn, the registries they are downloaded from, the build systems and CI pipelines that compile and package the result, and the channel that delivers it. Each of those is a link where something can be added, changed or left out without anyone on your team having written it. Securing the chain means knowing what is in each link and being able to show it.
Five parts, and what good looks like in each
Two vendors can both offer “supply chain security” and mean different products, because the term names a category rather than a control. This is the category laid out as a plan: each part, the outcome you want from it, and the kind of control that delivers it.
| Part | What good looks like | Control |
|---|---|---|
| What you depend on Open-source packages you declared, and the larger set they bring in. | A complete, resolved inventory with known vulnerabilities, known-malicious packages and license obligations attached. | Software composition analysis |
| Where it comes from Registries, mirrors, proxies, and the accounts that publish to them. | Packages arrive only from the sources you intend, under names you expect. | Registry policy and scoped package sources |
| How it is built CI runners, build scripts, and the credentials they hold. | Builds run on hardened, isolated infrastructure you can describe. | CI hardening, SLSA build levels |
| What you ship The artifact itself. | Anyone can confirm the release is the one you built. | Signing and build provenance |
| What you can show SBOMs, VEX statements, and the decisions behind them. | “Are we affected?” has a fast answer, and the answer can be handed over. | SBOM, VEX, recorded risk acceptance |
A useful question for any tool is which of these rows it delivers, and what evidence comes out of it. Knowing that makes the programme easy to plan and easy to explain.
What the well-known cases teach
The events people cite when they say “supply chain” are useful precisely because each one points at a different part of the map, and at the capability that answers it.
- Log4Shell: an inventory question. CVE-2021-44228 in Apache Log4j2 was in an ordinary, widely adopted open-source library, and for many organisations it sat several levels down the dependency graph rather than in anything they had declared. The question everyone had to answer was which products contain it, and where. A resolved inventory across every repository turns that into a lookup.
- xz-utils: a disclosure question. CISA reported malicious code embedded in XZ Utils 5.6.0 and 5.6.1, tracked as CVE-2024-3094. Once a compromised version is published as an advisory, every inventory that is matched against advisory data can locate it the same day.
- SolarWinds: a provenance question. CISA’s Emergency Directive 21-01 concerned a backdoor in specific builds of the SolarWinds Orion platform. The lesson sits in the build and artifact parts of the map: provenance that shows a release is the one that was built from reviewed source.
Three cases, three parts, three capabilities. That is the practical value of the map: it shows which investment answers which question.
What the frameworks and regulations ask for
The published guidance is more consistent than it first appears. Read together, it converges on an inventory you can trust and evidence you can hand over.
- SLSA describes the artifact. Its build track runs from Build L0, no guarantees, to L1, provenance exists, L2, signed provenance from a hosted build platform, and L3, hardened builds. It answers “was this package built the way we say it was?”
- NIST SSDF describes practices. SP 800-218 names the dependency work explicitly: PW.4.1, acquire and maintain well-secured third-party components; PS.3.2, collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM; PO.1.3, communicate requirements to the third parties supplying you. When a customer questionnaire cites the SSDF, these are usually the practices behind the question.
- The EU Cyber Resilience Act describes the evidence. Annex I Part II(1) asks manufacturers to identify and document vulnerabilities and components, including an SBOM in a machine-readable format covering at the very least the top-level dependencies. Built from the full resolved graph, the same SBOM also answers the vulnerability half of that requirement, since vulnerabilities can sit in transitive packages as easily as in the ones you declared.
- US federal guidance values the inventory. OMB memorandum M-26-05 (23 January 2026) replaced the earlier attestation memoranda with a risk-based approach, while stating that agencies “shall continue to maintain a complete inventory of software and hardware” and may require “a current software bill of materials (SBOM) upon request”. Requests now arrive through contracts and security reviews, which is where a ready answer to an SBOM request pays off.
This is a reading of the published texts, not legal advice; the links go to the sources so you can check them with your own counsel.
Where to start: an order that compounds
Each step below makes the next one worth more, which is why programmes that follow this order produce results people trust.
- 1 · An inventory you can stand behind. The full resolved dependency graph, not just the declared list, from a scan that tells you when it could not see everything and what would fix that. A clean result is worth most when you know the scan saw the whole graph.
- 2 · Prioritise on exploitation evidence. Severity describes what a vulnerability could do; exploitation data describes what is happening. KEV and EPSS alongside CVSS put the findings that matter at the top of the queue, so remediation effort goes where it counts.
- 3 · One view across every repository. “Which of our products contain this, and where?” becomes a single question with a single answer when every repository feeds into one place. The depproof hub gives you that view, and dependency governance beyond per-repo scans covers what it makes possible.
- 4 · Evidence per release. A CycloneDX SBOM for each release, and VEX statements for findings you have assessed as not affecting you, with each risk acceptance recorded with an owner and an expiry.
- 5 · Build provenance and signing. Hardened runners, signed provenance per SLSA, and signed artifacts. They attest to the inventory from step one, which is why a complete inventory makes them worth more.
Where depproof fits
depproof delivers the first and last rows of the map, the inventory and the evidence, and works alongside the build-provenance and signing tools you choose for the rest.
- What you depend on. The resolved dependency graph for Maven, Gradle, npm, Python and Go, direct and transitive, checked for known vulnerabilities and known-malicious packages and classified for license obligations. When a scan could not see the whole graph, it says so and tells you what would fix it.
- What you can show. A CycloneDX SBOM for every scan. With the hub: one view across every repository, waivers with an owner and an expiry, and an audit trail of each decision.
- On your terms. It runs on your own infrastructure; your source and findings never leave it.
Frequently asked questions
What is software supply chain security?
Software supply chain security is the practice of managing everything that goes into a software product and everything that carries it to the customer: the open-source packages you depend on, the registries you fetch them from, the build system that assembles them, the artifact you publish, and the evidence you can produce about all of it. Dependency scanning covers what is inside the product; build provenance and signing cover whether the thing you shipped is the thing you built. A mature programme has an answer for each.
Is software composition analysis the same as supply chain security?
SCA is one part of it: the packages you depend on and what is known about them, including vulnerabilities, known-malicious versions and license obligations. Build provenance, artifact signing and CI hardening cover the other parts. SCA is usually where teams start, because it produces the inventory the rest of the programme builds on.
What is the difference between SLSA and the NIST SSDF?
They work on different axes. SLSA describes the artifact: its build track runs from Build L0, no guarantees, through L1, provenance exists, and L2, signed provenance from a hosted build platform, to L3, hardened builds. The NIST SSDF (SP 800-218) describes practices across the development lifecycle and names the dependency work explicitly, for example PW.4.1, acquire and maintain well-secured third-party components, and PS.3.2, collect and maintain provenance data for all components of each release, for example in an SBOM. SLSA strengthens how you build; the SSDF describes what a programme does, including what you build with.
What does the EU Cyber Resilience Act say about SBOMs and dependencies?
Annex I Part II(1) asks manufacturers to identify and document vulnerabilities and components in their products, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies. Article 14 adds reporting of actively exploited vulnerabilities, starting with an early warning within 24 hours of becoming aware of one. The reporting obligations apply from 11 September 2026 and the regulation as a whole from 11 December 2027. This is a reading of the published text, not legal advice.
Is an SBOM of top-level dependencies enough?
It meets the CRA floor for the SBOM itself. The same requirement also asks you to identify and document vulnerabilities, and those can sit anywhere in the graph, including transitive dependencies you never declared. An inventory of the full resolved graph serves both purposes at once, so one piece of work produces the SBOM and answers the vulnerability questions.
Do US federal rules require an SBOM from suppliers?
Not as a general mandate today. OMB memorandum M-26-05 of 23 January 2026 rescinded M-22-18 and M-23-16, while stating that agencies shall continue to maintain a complete inventory of software and hardware, and that they may choose contractual terms requiring a software producer to provide a current SBOM upon request. In practice SBOM requests now arrive through contracts and customer security reviews, and being able to produce one quickly is what makes those conversations short.
Where should a security owner start?
With an inventory you trust: the full resolved dependency graph rather than the declared list, from a scan that tells you when it could not see everything. Then prioritise on exploitation evidence rather than severity alone, bring the same view together across every repository, and publish evidence per release. Build provenance and artifact signing come next, and they are worth more once the inventory they attest to is complete.
Where to go next
- Application security risk: the same dependency work seen from the AppSec side, and how to measure posture.
- What is software composition analysis? The first row of the map, in detail.
- Transitive dependencies: why the full graph, not the declared list, is the inventory worth having.
- Self-hosted SBOM generation and responding to an SBOM request: the evidence row.
- The depproof hub: one answer to “which products contain this?” across every repository.
depproof is a self-hosted SCA tool for Maven, Gradle, npm, Python and Go. The Scanner is free for open source and organizations under $1M revenue; see pricing. Product, standard and regulation names are used nominatively.