Software supply chain security in practice: generate SBOMs, keep dependencies healthy, protect CI/CD pipelines and sign artifacts with provenance.
Most modern applications are assembled rather than written from scratch: open-source libraries, container base images, build tools and CI/CD pipelines all become part of what you ship. Each is a potential entry point for attackers. These practical controls reduce the risk.
Know what you ship: SBOMs
A software bill of materials (SBOM) is a machine-readable list of the components in a piece of software, using standard formats such as SPDX or CycloneDX. Generate an SBOM for every build, store it with the release, and use it to answer quickly whether you are affected when a new vulnerability is announced.
Keep dependencies healthy
- Scan dependencies and container images for known vulnerabilities in every pipeline run.
- Pin versions and use lock files so builds are reproducible.
- Prefer well-maintained components and remove unused ones.
- Use a private registry or proxy to control which packages enter your builds, reducing exposure to typosquatting and dependency confusion.
Protect the pipeline
Your CI/CD system can sign and deploy code to production, which makes it a high-value target. Use short-lived credentials instead of long-lived secrets, restrict who can change pipeline definitions, require code review for changes and isolate build runners.
Sign and verify artifacts
Sign build artifacts and container images, and verify signatures before deployment. Build provenance — a record of how, where and from what source an artifact was built — lets you confirm that what runs in production came from your trusted pipeline. Frameworks such as SLSA describe levels of supply chain maturity you can work towards.
Plan your response
Decide in advance how you will find, patch and redeploy affected software when a widely used component is compromised. SBOMs and automated pipelines make that response far faster.
Start here: generate SBOMs, scan dependencies on every build and lock down who can change your pipelines.
6 proven controls for software supply chain security
- Maintain an inventory of dependencies. Generate a software bill of materials (SBOM) for every build in a standard format such as SPDX or CycloneDX, and store it alongside the release.
- Scan continuously, not once. New vulnerabilities are disclosed in existing packages every day. Re-scan SBOMs against vulnerability databases and prioritise issues that are known to be exploited.
- Pin and verify dependencies. Use lock files and checksums so builds pull exactly the versions you reviewed, and prefer trusted registries or internal mirrors.
- Harden build pipelines. Run builds in ephemeral, isolated environments, restrict who can change pipeline definitions and protect secrets with short-lived credentials.
- Sign artifacts and record provenance. Sign container images and packages, and generate provenance that shows which source, builder and parameters produced them. Verify signatures before deployment.
- Plan for response. When a critical library flaw emerges, an accurate SBOM lets you answer which applications are affected within hours rather than weeks.
Why attackers target the supply chain
Compromising a widely used library, build tool or update mechanism can give an attacker access to thousands of downstream organisations at once. Typosquatted packages, hijacked maintainer accounts and tampered build servers are all common techniques, which is why controls need to cover source, build and distribution.
Common mistakes to avoid
- Generating SBOMs but never using them for vulnerability management.
- Allowing builds to download the latest version of every dependency automatically.
- Storing long-lived cloud credentials inside CI/CD variables.
- Ignoring transitive dependencies, which make up most of a typical application.
Frequently asked questions
Do we need SBOMs for internal applications?
Yes. Internal applications use the same open-source components and face the same risks, and an inventory speeds incident response.
Where should we start?
Generate SBOMs in your main pipelines, enable dependency scanning and protect pipeline credentials. Add signing and provenance next.
A 90-day action plan
Days 1 to 30: generate bills of materials for your most important applications, enable dependency scanning in their pipelines and inventory where build credentials are stored.
Days 31 to 60: replace long-lived pipeline secrets with short-lived credentials, restrict who can edit pipeline definitions and require reviews for dependency changes.
Days 61 to 90: sign container images and packages, verify signatures at deployment and rehearse your response to a critical vulnerability in a widely used library.
Questions to ask suppliers
- Can you provide a bill of materials for the software you deliver to us?
- How do you secure your build systems and protect signing keys?
- How quickly do you notify customers of vulnerabilities in your products?
- Do you follow a recognised secure development framework?
- How do you vet open-source components before adopting them?
Key terms explained
- Transitive dependency: a library your code uses indirectly through another library.
- Provenance: verifiable information about how and where an artifact was built.
- Typosquatting: publishing malicious packages with names similar to popular ones.
- Reproducible build: a build that produces identical output from the same source.
The bottom line
Modern applications are assembled from hundreds of third-party components and built by automated pipelines, which makes the path from source to production an attractive target. Inventories, continuous scanning, pinned dependencies, hardened build systems, signing and rehearsed response plans address the main risks. Apply the same expectations to suppliers. Progress is incremental, but each control makes compromise harder and response faster when the next critical library flaw appears.
Further reading on software supply chain security
For authoritative, vendor-neutral guidance on software supply chain security, see the SLSA framework. You can also browse our free whitepapers.
