Software Supply Chain Security: SBOMs, Signing, and What Buyers Now Ask For
Why this became a procurement question
A string of high-profile compromises delivered through build systems and package repositories moved supply chain security from a security team concern to a contractual one. Enterprise buyers, and increasingly regulators in both the EU and the US, now ask vendors what their software is made of, how it is built, and how quickly they can answer when a new vulnerability lands in a widely used library. Being unable to answer within a day is now a commercial disadvantage, not just a technical gap.
An SBOM is only useful if it is generated automatically
A software bill of materials produced by hand for a customer questionnaire is out of date before it is sent. Generate it in the build pipeline for every release, in a standard format, store it alongside the artefact, and make it queryable. The value is not the document — it is being able to answer 'are we affected' in minutes when the next critical vulnerability in a common library is announced, instead of spending two days grepping repositories.
Pin, verify and reduce dependencies
Lock files with cryptographic hashes so a rebuild gets identical inputs. Verify signatures where publishers provide them. And treat every new dependency as a decision with a maintenance cost — a small utility package brought in for one function adds an update surface and a trust relationship forever. Reviewing dependency additions in code review, and periodically removing unused ones, does more for supply chain risk than most tooling.
The build system is a production system
Whoever controls your CI can ship code to your customers. That means the pipeline needs the same care as production: least-privilege credentials scoped per job, short-lived tokens rather than long-lived secrets, protected branches with required review, restrictions on which workflows can access secrets, and third-party actions or plugins pinned to specific commits rather than mutable tags. Compromised CI credentials are one of the most efficient attack paths against a software vendor, and they are frequently the least monitored part of the stack.
Signing and provenance
Signing artefacts and publishing build provenance lets consumers verify that what they run came from your pipeline and your source. Tooling for this has matured to the point where it is a pipeline configuration change rather than a project. Combined with a verification step at deployment, it closes the gap where an attacker with registry access could substitute an image. Larger customers have begun asking for this specifically, so it is worth doing before it appears in a contract.
Vulnerability response is a process, not a scanner
Scanning produces a list; what matters is what happens next. Define severity thresholds with response times, route findings to the team that owns the component rather than a central queue, and distinguish reachable vulnerabilities from theoretical ones so engineers are not drowning in noise. A documented, evidenced process — including how you notify customers — is what buyers are actually assessing when they ask about your security posture.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch