Software Supply Chain Security and the SBOM

Modern applications are mostly made of libraries, frameworks and packages written elsewhere. A typical project pulls in hundreds of dependencies, and each of those has dependencies of its own. When a serious vulnerability appears in a widely used component, the first question is simple and hard to answer: are we using it, and where?

A software bill of materials helps answer that question in minutes. This guide explains SBOMs and the wider topic of software supply chain security, in practical steps for a small development team and for an enterprise buying and building software at scale.

What is an SBOM

The US Cybersecurity and Infrastructure Security Agency, in its SBOM resources, describes an SBOM as a nested inventory of the components that make up software, a list of ingredients. It is a building block in software security and supply chain risk management and promotes transparency across the software ecosystem. A related concept, the Vulnerability Exploitability eXchange, or VEX, is an advisory that states whether a product is actually affected by a known vulnerability, which helps reduce noise.

An SBOM typically records, for each component:

• Name and version.
• Supplier or origin.
• Unique identifiers, such as package URLs and hashes.
• Licence information.
• Relationships, such as which component depends on which.
• Metadata about the SBOM itself, such as the author and timestamp.

Why it matters

• Faster response. When a vulnerability is announced, search your inventory and skip the round of asking every team.
• Risk visibility. See outdated, unsupported or high-risk components.
• Licence compliance. Identify obligations that come with open source licences.
• Procurement. Buyers increasingly ask suppliers for SBOMs, and regulations in some regions encourage or require them for certain sectors.
• Incident handling. Faster scoping of exposure.

Formats and tools

Common formats include SPDX, a standard maintained under the Linux Foundation, and CycloneDX, developed by the OWASP community. Both can express components, relationships and vulnerabilities. Many build tools and package managers can generate SBOMs automatically, and scanners can read them. Choose a format your tools and partners support, and use one consistently.

Generate and use SBOMs

1. Generate in the build pipeline for every release, so the SBOM matches the shipped artefact. Generating from a running environment can add runtime information.
2. Include direct and transitive dependencies, the ones pulled in by others.
3. Store SBOMs in a central repository, linked to each product and version.
4. Scan against vulnerability databases regularly, including after release, since new vulnerabilities are published daily.
5. Prioritise findings by severity, exploitability, exposure and whether the vulnerable code is actually used. Known-exploited vulnerabilities deserve urgent attention.
6. Fix: update, replace or mitigate, and record decisions.
7. Share SBOMs with customers where appropriate, with the right confidentiality.

Beyond the SBOM: securing the supply chain

An inventory shows what you have. Protecting the chain takes more.

Source and code

• Protect repositories with multi-factor authentication, branch protection and required reviews.
• Control who can merge and release.
• Scan code for secrets, such as keys, and remove them.
• Use signed commits where useful.

Dependencies

• Choose well-maintained components with active communities, and check licences.
• Pin versions, and use lock files so builds are repeatable.
• Verify integrity with hashes and signatures where available.
• Use private package mirrors or proxies to control what enters your builds.
• Watch for typosquatting and malicious packages that imitate popular names.
• Remove unused dependencies, since each one adds risk.
• Update regularly, with automated pull requests and tests.

Build and release

• Use isolated, ephemeral build environments.
• Define builds as code, and review changes.
• Restrict access to build secrets, and rotate them.
• Sign artefacts and verify signatures before deployment.
• Record provenance, meaning evidence of how and where an artefact was built. Frameworks exist for levels of build integrity.
• Scan container images and infrastructure code.

Deployment and runtime

• Deploy only approved, signed artefacts.
• Monitor for unexpected behaviour.
• Keep the ability to roll back quickly.

Suppliers and vendors

• Assess critical suppliers’ security practices.
• Include security and vulnerability disclosure terms in contracts.
• Ask for SBOMs and information about how they handle vulnerabilities.
• Track end-of-life dates for software you depend on.

Our article on DevOps delivery metrics explains the delivery practices that make frequent, safe updates possible, which is essential for keeping dependencies current.

Organise the work

• Inventory first: know which products and components matter most.
• Assign ownership: product teams own their dependencies, and a security team provides tooling and policy.
• Set policy: acceptable licences, maximum age of critical vulnerabilities, rules for adding dependencies.
• Measure: time to identify affected products, time to remediate, share of builds with SBOMs, number of outdated or unsupported components.
• Practise: run an exercise where a major vulnerability is announced, and see how fast you can find and fix affected systems.

Challenges

• Volume of findings, many of which are not exploitable in your context. Use VEX information and reachability analysis to focus.
• Incomplete or inaccurate SBOMs, especially from tools that cannot see everything. Compare tools and validate.
• Legacy and third-party software with no SBOM available.
• Developer friction when security gates slow delivery. Automate and keep fixes easy.
• Confidentiality concerns about sharing component lists. Share under agreements where needed.

Common mistakes

• Generating an SBOM once and never updating it.
• Scanning only at build time.
• Treating the SBOM as a compliance document with no action behind it.
• Ignoring build system security.
• Allowing any package into builds.
• No owner for dependency updates.

A starting plan

1. Pick one important product and generate an SBOM in its pipeline.
2. Scan it, and fix critical findings.
3. Add dependency pinning and automated update proposals.
4. Secure the build pipeline and sign releases.
5. Extend to other products, and ask key suppliers for SBOMs.

How SoftSapien supports software supply chain security

SoftSapien helps engineering teams set up SBOM generation, vulnerability management, secure pipelines and supplier reviews, balancing security with delivery speed. See our cybersecurity consulting and enterprise software engineering services.

To strengthen your own supply chain, go to the contact page and chat with our team, send a message or schedule a free consultation call.