Software Supply Chain Security: SBOMs, Dependency Risk and Build Provenance
Securing your software supply chain: dependency risks, lockfiles and review, SBOMs (CycloneDX, SPDX), signed builds, SLSA provenance and CI hardening.
How do you secure your software supply chain?
Control what comes in (lockfiles, pinned versions, review of new dependencies, vulnerability and malicious-package alerts), protect how software is built (least-privilege CI, short-lived credentials, isolated and reproducible builds), record what you shipped (SBOMs in CycloneDX or SPDX), prove where it came from (signed artefacts and provenance following SLSA), and have a plan for responding when a dependency is compromised. Start with the basics and add provenance as you mature.
This guide is for engineering leads and developers. It is educational. For a point-in-time review of licences and vulnerabilities, see open-source software audit.
Key takeaways
- Pin and lock dependencies; review new ones.
- Alert on vulnerable and malicious packages.
- Harden CI: least privilege, short-lived credentials, protected branches.
- Generate SBOMs on every build.
- Sign artefacts and produce provenance.
- Practise responding to a compromised dependency.
Attack paths
| Path | Example | Control |
|---|---|---|
| Dependencies | Malicious package or typo-squatted name | Review, allowlists, lockfiles, malicious-package alerts |
| Maintainer compromise | Legitimate package publishes a bad version | Pinning, delayed upgrades, monitoring advisories |
| CI/CD | Leaked token used to push or deploy | Least privilege, OIDC credentials, secret scanning |
| Build tampering | Modified build output | Isolated builds, signing, provenance |
| Registries and images | Unverified base images | Trusted sources, scanning, signature verification |
SBOMs
Generate an SBOM automatically during each build in a standard format such as CycloneDX or SPDX, store it with the release, and use it to answer 'are we affected?' when vulnerabilities are announced. ASD's ACSC co-authored international guidance on SBOMs, updated with 2026 minimum elements (joint guidance via NZ NCSC).
Provenance and signing
Provenance describes how an artefact was built: source commit, build platform, inputs and steps. SLSA (version 1.2) defines levels of build integrity, from documented provenance to hardened build platforms. Sign release artefacts and container images, publish provenance, and verify signatures before deployment. Pair this with secrets management for CI credentials.
Responding to a compromised dependency
- Use SBOMs to find affected applications and versions.
- Pin to a known-good version or remove the package.
- Rotate any secrets the build or runtime could have exposed.
- Check logs for suspicious behaviour.
- Rebuild from clean sources and redeploy.
- Follow your incident response plan; see cyber incident response plans.
Hypothetical example: a SaaS responding to a package advisory
This example is hypothetical. A SaaS team learned that a popular logging package had a malicious release. Because every build stored an SBOM, it found within minutes that two services used the package but at an earlier pinned version, while one internal tool had pulled the bad version through a loose version range. It removed the version, rotated the tool's credentials, rebuilt it, and tightened version ranges and new-dependency review across repositories.
Common mistakes
- Loose version ranges in production builds.
- CI tokens with broad, long-lived permissions.
- SBOMs generated once for a customer and never again.
- No verification of signatures before deployment.
- Treating supply chain security as only a licence check.
Related guides
- AI supply chain security for models and datasets.
- Infrastructure as code for reviewed infrastructure changes.
- DevOps for growing businesses for CI/CD foundations.
- Threat modelling for build threats.
Conclusion
Software supply chain security combines careful dependency management, hardened builds, SBOMs and provenance. Start with lockfiles, alerts and CI least privilege, generate SBOMs on every build, then add signing and provenance.
Customers asking about SBOMs?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure software delivery. We do not provide security certification, but we build these practices into the software and pipelines we deliver.
Common questions.
Protecting everything that goes into building and delivering your software: third-party dependencies, build tools, CI/CD pipelines, artefact registries and deployment processes. Attacks can come through a compromised package, a malicious maintainer, a leaked CI secret or a tampered build.