The overwhelming majority of a modern application is third-party code you did not write and cannot fully review. That is not a failure - it is how software is built. The failure is not knowing what is in there when a critical vulnerability lands and a customer asks whether you are affected.
The three attack surfaces
- Dependencies - vulnerable, abandoned, malicious or typosquatted packages pulled in directly or transitively.
- The build pipeline - compromise here injects code into legitimately signed artefacts, which is the most damaging variant because everything downstream looks authentic.
- Distribution - tampering between your build and your customer.
Notice that dependency scanning only addresses the first. Programmes that stop there leave the two harder surfaces uncovered.
What an SBOM actually gives you
A Software Bill of Materials is a machine-readable inventory of the components in a piece of software - typically in SPDX or CycloneDX format. Its value is operational rather than ceremonial:
- Answer "are we affected?" quickly. When a widely-used library has a critical flaw, the organisations that answer in hours have SBOMs; the ones that answer in weeks are grepping repositories.
- Answer it for customers - increasingly a contractual expectation, and a differentiator when you respond fast.
- Surface licence obligations alongside security.
- Show transitive dependencies, where most surprises live.
An SBOM generated once and filed is nearly useless. It must be produced per build and stored with the artefact, or it describes a version you no longer run.
Make supply chain evidence part of your programme
GRC Copilot links your dependency, build and artefact controls to the requirements in the SSDF, the EU Cyber Resilience Act and your other frameworks - with the evidence attached.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Practical controls
Dependencies
- Software composition analysis in CI, with policy on which severities block.
- Lock files committed so builds are reproducible and a dependency cannot silently change.
- An internal registry or proxy rather than pulling directly from public repositories.
- Review before adopting new dependencies - maintenance status, maintainer count, release history.
- A policy on abandoned packages, which are a slower but real risk than vulnerable ones.
Build integrity
- Builds only from version-controlled source, never from a developer machine.
- Ephemeral, isolated build environments.
- Tightly restricted access to pipeline configuration - it is production-equivalent.
- Signed artefacts, with signature verification enforced at deployment.
- Build provenance recorded - what source, what inputs, what environment produced this artefact.
Distribution
- Publish checksums and signatures.
- Provide SBOMs alongside releases.
- A documented, monitored vulnerability disclosure route.
The regulatory pull
This has moved from good practice to obligation in several places: the EU Cyber Resilience Act expects SBOMs and vulnerability handling from manufacturers; US federal procurement has pushed secure development attestation and SBOM expectations via the SSDF; and NIS2 names supply chain security explicitly. If you sell software, expect these questions in procurement regardless of your own regulatory status.
Where to start
- Generate SBOMs in CI and store them with each artefact.
- Turn on dependency scanning and set a policy for what blocks.
- Commit lock files and make builds reproducible.
- Lock down who can modify the pipeline.
- Sign artefacts and verify signatures at deploy.
- Publish a vulnerability disclosure policy.
- Rehearse the "are we affected?" drill against a real past CVE and time it.
Frequently asked questions
Which SBOM format should we use?
SPDX and CycloneDX are both widely accepted. Choose based on your tooling and what customers request; generating both is straightforward.
Do we have to publish SBOMs publicly?
Not usually. Many organisations provide them under NDA or on request. The regulatory expectation is that they exist and can be supplied, not that they are public.
Does an SBOM create risk by revealing our stack?
Marginally, but attackers can usually fingerprint your stack anyway. The defensive benefit of knowing your own inventory outweighs it - which is why the regulatory direction is toward disclosure.
How do we handle thousands of existing findings?
Baseline and block on new ones, then burn down by exploitability and reachability rather than raw severity. Not every vulnerable dependency is actually reachable in your code.
Key takeaways
- Dependency scanning covers only one of three attack surfaces.
- Generate SBOMs per build and store them with the artefact.
- Pipeline access is production-equivalent - restrict it accordingly.
- Time your "are we affected?" drill; that number is the real measure.