Software bill of materials (SBOM)

An SBOM answers a question that is surprisingly hard to answer without one: what is actually in the thing we ship? Most of a modern application is code somebody else wrote. A handful of declared dependencies pull in hundreds of transitive ones, and those are the components an attacker studies.

The value shows up on the day a widely used package is found to be compromised. The only question that matters in the first hour is whether you are affected, and teams without an inventory answer it by reading lockfiles under pressure. Teams with one answer it by searching a file.

Two formats dominate: CycloneDX and SPDX, and CISA maintains the reference material on what an SBOM should contain. Both are produced by tooling from your existing dependency files, so generating one is a build step rather than a project. The discipline is generating it per release and keeping the old ones, so you can also answer what changed.

Enterprise procurement increasingly asks for an SBOM directly, and some public sector buyers require one. That makes it one of the few security artefacts that is both genuinely useful internally and immediately saleable externally.