Software supply chain security has run for decades on vendor assurance — questionnaires, attestations, and hope. A quieter movement is replacing assertion with cryptographic verification: signing, transparency logs, SBOMs, and reproducible builds.
Part 8 of 10 in Trust through mathematics
Every organisation runs on software it did not write, built by people it has never met, assembled from components those people did not write either. The traditional governance answer to this uncomfortable arrangement is the supplier-assurance process: questionnaires, certifications, contractual flow-downs, and an annual review. Anyone who has sat on either side of it knows what it verifies – that somebody was able to fill in the questionnaire.
The incidents of the past few years – build systems compromised to ship signed malware to thousands of organisations, popular open-source packages hijacked through maintainer accounts, a backdoor inserted into a compression library over years of patient, socially-engineered contribution – share a common feature. In each case the paperwork was in order. The supply chain failed precisely where assurance is thickest and verification thinnest: in the gap between what suppliers assert and what anyone can check.
A quieter development over the same period has been the assembly, piece by piece, of the machinery for checking. Taken together, those pieces are this series’ argument applied to software itself: replacing trust by attestation with trust by mathematics.
The Pieces Of A Verifiable Chain
The first piece is signing, done seriously. Code signing is decades old; what is new is the infrastructure that makes it trustworthy at ecosystem scale. Sigstore ties signatures to identities through short-lived certificates and records signing events in a public, append-only transparency log. Package ecosystems are adopting the same model: npm automatically generates provenance attestations for trusted-publishing workflows, while PyPI accepts and exposes digital attestations bound to trusted publishers. The transparency model is borrowed from Certificate Transparency, which did the same service for TLS: not preventing bad issuance, but making it impossible to do quietly. A signature that must be published to be valid is one that anyone can audit, forever. Silent substitution – the heart of every supply-chain attack – becomes loud.
The second is knowing what is inside, which is the job of the Software Bill of Materials. An SBOM is simply an ingredients list: every component and version inside a piece of software, in a standard machine-readable format. The value is unglamorous and proven. When the next critical vulnerability lands in a ubiquitous library, organisations with SBOMs query a database and organisations without them convene meetings. Log4Shell made the case more persuasively than any policy paper; regulators noticed, and SBOM requirements now appear in US federal procurement and in the EU’s Cyber Resilience Act. An SBOM is not itself a security control. It is the index that makes every other control addressable.
The third is provenance: not what is inside, but where it came from. SLSA defines provenance as verifiable information about where, when, and how a software artefact was produced, with higher build levels adding protection against tampering in and around the build. This targets the lesson of the most damaging attacks: the decisive compromises happened in the build, after the source was reviewed and before the signature was applied. Signed provenance closes the gap in which they lived.
The fourth, and strongest, is reproducible builds. The end of this road is the ability to verify rather than be told: anyone rebuilding the published source obtains a bit-for-bit identical artefact, so the binary you run demonstrably corresponds to the code that was audited. It is demanding engineering – stripping every timestamp and ordering quirk out of a build is harder than it sounds – and whole ecosystems have nonetheless achieved it substantially. Where it holds, an entire category of attack simply ceases to be available, including attacks on the build infrastructure itself.
What This Means In Practice
For most organisations the sensible posture is consumer first, producer second.
As a consumer, begin requiring SBOMs from suppliers; regulation is making this normal, and asking is free. Verify signatures where ecosystems support it, which increasingly means turning on what already exists rather than building anything. Prefer suppliers who publish provenance and can answer the question “how would we detect it if your build system were compromised?” – the modern form of the question this series keeps asking. The honest answers are illuminating, and so are the dishonest ones.
As a producer, the instruction is short. Sign what you ship, publish SBOMs, and treat your build pipeline as production security infrastructure – because your attackers already do. The pattern in the serious incidents is consistent: development was careful, the build system was an afterthought, and the afterthought was the target.
None of this retires supplier governance. Contracts, certifications, and reviews still do work nothing cryptographic can do: they cover conduct, support, and the parts of quality no signature attests. Our own national-security review of defence-logistics outsourcing for the Ministry of Defence turned on exactly the questions paperwork can address – concentration risk, sovereignty, and what happens when assurance meets adversity. The shift described here is narrower and sharper: for the specific claims “this artefact is what the supplier built, from the source they reviewed, with the contents they declare”, assertion is no longer the best available evidence. Verification is, and it is largely free.
The Pattern
Certificate Transparency made certificate issuance auditable, and mis-issuance went from routine scandal to detectable anomaly. The same architecture – sign everything, log everything publicly, let anyone verify – is now being applied to software artefacts, and the early signs suggest a similar trajectory. It does not make compromise impossible. It makes compromise visible, which changes the economics for an attacker whose whole method depends on substitution going unnoticed.
The shape is by now familiar: not the elimination of trust but its relocation, out of assertions anyone can make and into mathematics anyone can check. Software supply chains are simply the latest, and arguably the most overdue, place the relocation is happening. The tooling exists, the standards have settled, and the regulators have started writing it into law. The remaining question for any organisation is the usual one: whether to adopt the discipline before or after the incident that makes the case internally.