What an SBOM is and why regulators are starting to ask for one

01.What an SBOM is

A software bill of materials (SBOM) lists the components inside a piece of software. Think of the ingredients label on food. It does not tell you the food is safe. It tells you what is in it, so someone with an allergy can decide.

An SBOM names each component, its version, where it came from and often its licence. It covers the libraries you chose and the ones those libraries pulled in. Two formats are common: SPDX and CycloneDX. Both are structured, machine-readable and widely supported by tools.

Manufacturers have used bills of materials for a long time. If a supplier recalls a part, the manufacturer can find every product that contains it. Software needs the same ability, for the same reason.

02.Why it matters

When a new vulnerability is announced, you can find what is affected in minutes instead of days. Without an inventory, the process is a round of messages: "Do you use this package?" Each team checks by hand. Some reply, some do not. By the time you have an answer, the window for easy action has narrowed.

With an inventory, you search for the package and version. You get a list of builds and services. You can prioritise by exposure and start work the same morning.

An SBOM also helps with licence questions. If a package carries terms your legal team dislikes, you find out before a customer or an acquirer does. And it helps in incident response: when something odd happens, knowing exactly what is running removes a lot of guesswork.

03.Why regulators and customers are asking

Customers and some regulations increasingly request SBOMs. The reasoning is straightforward. Software is built from many parts, and a flaw in one part can affect everyone using it. Buyers want a way to check what they are being sold, and to respond quickly when something is found.

For you, this usually shows up as a line in a procurement checklist, a contract clause or a security review question. Treat it as a sign of where expectations are going, not as a one-off request. Companies that can answer calmly and quickly tend to look more mature than those who scramble.

04.What a useful SBOM looks like

Many first attempts produce a file that nobody uses. A useful SBOM has these qualities:

• It is generated by the build, not by hand. A document written once goes stale within weeks.
• It includes transitive dependencies. The packages your packages depend on matter as much as the ones you picked.
• It is tied to a specific build. You should be able to say "this SBOM describes version 4.2 of this service."
• It is stored and searchable. A folder of files is not an inventory.
• It is checked. If a build produces an SBOM with five components for a large application, something is wrong.

A common trap is container images. Your application manifest may list forty packages while the image it runs in carries hundreds more from the operating system and base layers. If you only scan the manifest, your SBOM describes a fraction of what you ship.

05.What changes when you have one

Take a plausible morning. An advisory appears for a widely used logging library. Without an SBOM, the security lead posts in a chat channel and waits. Three teams say "we think no". One says "let me check". Someone else uses it indirectly and does not know.

With an SBOM, the lead types the library name and version range into a search. Within a minute there is a list: four services, two of them internet-facing. The team opens tickets for those two first, checks whether the vulnerable function is used, and patches. The rest follow in the normal cycle. The difference is not cleverness. It is having the data.

06.How to start in a week

• List your repositories and languages. Rank them by customer impact. Start with what customers touch.
• Pick one tool per ecosystem. Do not search for the perfect tool. Pick one that outputs SPDX or CycloneDX and works in CI.
• Pilot on two or three repositories. Choose different stacks so you learn early.
• Store the output centrally. Keep the repository, commit and build number with every SBOM.
• Add vulnerability scanning on top. The SBOM is the inventory. Scanning is what turns it into action.
• Write a short process for customer requests. Who approves, what is shared, how long it takes.

07.Common mistakes

• Treating the SBOM as a document to produce once. It must come from the pipeline.
• Ignoring container images. Packages installed in image builds may not appear in manifests.
• Counting only direct dependencies. The risk is often several levels down.
• Sending SBOMs without review. Check what you are sharing. Internal package names can reveal more than you intend.
• Having an inventory and no owner. Someone must be responsible for acting on what it shows.
• Expecting an SBOM to fix security. It is a map. You still need to walk the route.

08.What to do next

If you have no inventory, start with the five most important repositories this week. If you have SBOMs but nobody reads them, connect them to scanning and decide who owns the findings. If a customer has asked and you are unsure what to send, agree a standard answer now, before the next request arrives.

The goal is simple: when the next advisory lands, you answer "are we affected?" quickly and with confidence.

09.How SBOMs fit with scanning and signing

An SBOM is one piece of a small set of practices that work together. It is worth seeing how they connect so you do not buy or build one part and expect the others to follow.

The SBOM is the inventory: what is in the build. Vulnerability scanning reads that inventory and compares it with public advisories, so you learn when something you ship becomes known to be risky. Build signing and provenance records show who built an artefact, from which source, and that nobody changed it afterwards. Policy ties them together: a rule that says what the pipeline should do when scanning finds something serious.

You can start with the inventory alone and still gain a lot. But the value grows when each piece feeds the next. An inventory without scanning is a list. Scanning without an inventory is partial. Signing without either tells you the artefact is genuine, not that it is safe.

10.Who should own it

SBOMs often fall between teams. Security wants them. Engineering produces them. Sales sends them. Nobody owns the whole process, and the result is a pile of files and a lot of waiting.

A workable split looks like this. Engineering owns the pipeline step and keeps it running. Security owns the policy and watches the findings. One named person, often an engineering manager or a security lead, owns the customer-facing answer: what is shared, in what format and how quickly. Write this down. It takes ten minutes and saves weeks of confusion later.