What it is
Software supply chain security covers everything that goes into your build, not only the code your team writes. A service pulls in open source libraries, a base container image, build plugins, CI runners and package registries. An attacker needs one weak link: a typosquatted package, a leaked registry token, a compromised maintainer account.
An SBOM, or software bill of materials, is a file that lists every component inside a build artifact. Each entry carries a name, a version, a supplier and a machine readable identifier such as a package URL. Good ones record the dependency graph too: library A pulled in B, and B pulled in C. CycloneDX and SPDX are the two formats you will meet most, and both come as JSON or XML that tools parse without a human reading them.
An SBOM is an inventory, not a verdict. It does not tell you the software is safe and it is not a scanner. Its value appears when you compare it against something else: a vulnerability database, a license policy, a support timeline.
How it works
Generate the SBOM during the build, from the artifact you will actually ship. Tools such as Syft, cdxgen, Trivy or the CycloneDX plugins for Maven, Gradle and npm read your lockfiles and write the file. Put the step after the build and before publishing, so the SBOM and the image share a digest.
You need two views. A source level SBOM comes from manifests and lockfiles and shows what developers declared. A binary level SBOM comes from scanning the built image and shows what is really there, including OS packages from the base image that nobody wrote down. That second view surprises people: a slim base image still carries dozens of system libraries.
Consumption is where the work happens. Feed the file into a matcher such as Grype, Trivy or Dependency-Track. It maps components to known vulnerabilities and keeps watching. When a new advisory lands for a package you shipped six months ago, you get a hit even though you changed nothing.
Then tie the file to the artifact. Sign the image and the SBOM with something like Sigstore cosign and record provenance: which pipeline, commit and builder produced it. An unsigned SBOM is a claim. A signed one attached to a digest is evidence.
Why it matters for a business
The real test is a bad day: a widely used library gets a critical advisory at 4pm on a Friday. Leadership asks one question. Are we affected, and where? With an SBOM per release you answer in minutes by searching the inventory. Without it, you grep across repos and hope the person who built the service is online.
Customer security reviews ask for this directly. Enterprise buyers request an SBOM, often in CycloneDX or SPDX, plus a description of how you build and sign releases. Software sold to US federal agencies is expected to ship one, and the EU Cyber Resilience Act sets similar expectations for products sold in Europe. Having the file ready turns a two week questionnaire into an afternoon.
There is an operational payoff. An SBOM shows components pinned to old versions, out of support, or duplicated at several versions inside one image. Those are maintenance problems you can fix calmly. It also makes patching cheaper: you change one base image and rebuild, because you know what depends on it.
Common mistakes
Generating an SBOM once and filing it. A bill of materials is true for one build. If it is not produced on every release and stored next to the artifact, it drifts within days and quietly becomes fiction.
Listing only direct dependencies. Most risk sits deeper in the graph. npm, pip and Go modules pull in trees of packages, and container images add OS packages on top. Check that your tool resolves transitive dependencies and shows the depth.
Treating the SBOM as the security program. A list patches nothing. Teams that wire the matcher to a channel and ignore it end up with hundreds of open alerts and no trust in the data. Triage by severity, by whether the vulnerable function is reachable, and by whether the component runs in production.
Skipping the base image, the build tools and the publish credentials. Your compiler and CI runner are part of the chain. An SBOM for application code only gives you half the picture, and the missing half is often the one that matters.
How to get started
Start with one service that matters. Add an SBOM step to its pipeline, run it on every build, and store the output keyed by image digest in the same place you keep the artifact. Pick one format and keep every version for as long as you support that release.
Wire it to a scanner with a simple policy first: critical severity plus anything on a known exploited list goes to a named person, the rest lands in a queue reviewed weekly. Scan the base image too, and refresh it on a schedule so the numbers stay honest.
Then extend to the rest of your services and add signing. Ask vendors for their SBOMs and keep them, because your inventory is incomplete without the parts you did not build.
If releases still depend on one person and a lot of manual steps, a platform helps. Cloudverg's Delivery platform setup is a fixed price $14,500 package that runs four weeks and includes pipelines with a security scan step, separate environments and a tested rollback. It is one option among several. The SBOM habit still has to come from your team.
Frequently asked questions
What is an SBOM in simple terms?
It is a file, usually JSON or XML, that lists every component in a piece of software: libraries, their versions, who supplied them and how they relate. Think of it as an ingredients list a machine can read. On its own it fixes nothing, but it lets you answer questions about what you ship.
Should I use CycloneDX or SPDX for my SBOM?
Both are open and widely supported. CycloneDX leans toward security use cases and has fields for vulnerabilities and services, while SPDX has longer roots in license compliance. Pick the one your customers and tools accept and stay consistent. Converting later is possible but annoying.
Does an SBOM make our software secure?
No. It is an inventory. It becomes useful when you match it against vulnerability data, license rules and support timelines, and when someone acts on the results. Teams that generate SBOMs and never read them get paperwork and little else.