The blind spot in every estate
Software is the lifeblood of a modern business, and it also carries most of the business's security, compliance and operational risk. The larger share of a modern application is not written by the team that ships it: it is third-party libraries, open-source components and the dependencies of those dependencies. Most organisations cannot say, for a given release, exactly what is in it. That is a blind spot, and attackers have been working in it for years.
The SBOM as a security control, in one view
A bill of materials that sits in a folder is a document. One that the pipeline generates, checks and acts on is a control.
- Produced once, for a customer questionnaire
- Stored in a folder, drifts from the next release
- Read by a person when a CVE makes the news
- Answers "are we affected?" in days or weeks
- Generated by the pipeline on every build
- Versioned with the artefact, signed with it
- Matched against advisories continuously
- Answers "are we affected?" in minutes, with the list of builds
| Regime | What it asks for |
|---|---|
| US Executive Order 14028 and NIST SSDF | Bills of materials for software sold to the federal government; secure development practices that include component inventory |
| PCI DSS 4.0, requirement 6.3.2 | An inventory of bespoke and custom software and the third-party components in it, to manage vulnerabilities |
| US FDA, medical devices | A software bill of materials in the premarket submission for a cyber device |
| EU Cyber Resilience Act | A bill of materials for products with digital elements, as part of the vulnerability-handling requirements |
| CERT-In technical guidelines on SBOM | Recommended fields, formats and practices for Indian entities, with government and critical-sector procurement first |
What an SBOM actually is
A software bill of materials is a structured list of every component in a software product: the libraries and dependencies, open-source and proprietary; their versions and licences; the known vulnerabilities attached to each; and the relationships between them. It is an X-ray of the software. Two formats matter in practice, CycloneDX and SPDX, and the tools that produce them, Syft, Trivy and the package managers themselves, are free. The cost of an SBOM is not in generating it. The cost is in deciding to treat it as a control.
SolarWinds, Log4j and the supply chain
Modern software relies on hundreds of dependencies, many from vendors and repositories the organisation has never assessed, and criminals target the weak links. In 2020 malicious code was injected into SolarWinds software updates and travelled, signed and trusted, into thousands of organisations. In 2021 a zero-day in Log4j, a logging library almost nobody had consciously chosen, exposed millions of applications at once. Neither incident was found by looking at the code the victims wrote. Both were found, where they were found quickly, by organisations that could look up what they were running.
You cannot patch what you do not know you run.
Hours, not weeks
When a new vulnerability is published the first question is always the same: are we affected, and where? Without a bill of materials the answer is days or weeks of manual searching across repositories, build servers and vendor emails, and every day of that search is a day of exposure. With one, the answer is a query. When CVE-2021-44228 landed, organisations with SBOM-based vulnerability management identified and patched the affected builds within hours; others took weeks, and some were still finding instances months later. The difference between the two groups was not budget or headcount. It was whether the list existed and was current.
In the pipeline, not in a folder
An SBOM produced once for a customer questionnaire is a document. It drifts from the next release, nobody reads it until a CVE makes the news, and by then it describes software you no longer run. An SBOM becomes a control when the pipeline generates it on every build, stores it beside the artefact it describes, matches it continuously against new advisories and acts on the result: a deployment with a known critical does not reach production, a ticket opens with the affected builds already listed, and a vendor is asked for their bill before their component is integrated. Syft or Trivy in the build, Grype or Dependency-Track watching the inventory, and a gate that is allowed to say no. That is the whole design.
Licensing rides on the same list. The large majority of applications carry open-source components, and a licence conflict discovered at due diligence, a copyleft component inside a proprietary product, is a legal problem that the same inventory would have shown a year earlier.
What regulators now expect
The bill of materials has moved from good practice to expectation. In the United States, Executive Order 14028 and the NIST Secure Software Development Framework put it into federal procurement, and the FDA requires one in premarket submissions for medical devices. PCI DSS 4.0 requires an inventory of bespoke software and its third-party components. The EU Cyber Resilience Act requires one for products with digital elements. In India, CERT-In has published technical guidelines on SBOM for government and critical-sector entities and the suppliers who sell to them. For a vendor, the inability to produce one is increasingly the reason a contract is lost. For a buyer, the ability to ask for one is the cheapest supply-chain control available.
Where to begin
Pick one production application. Generate its bill of materials today, with whichever free tool your build already supports, and count how many components it contains and how many carry a known vulnerability. Most teams are surprised by both numbers. Then put the same generation into that application's pipeline so that the count is refreshed on every build, and add one rule: a critical with a fix available fails the build. Extend from there, application by application, and ask each of your vendors for theirs.
An SBOM is no longer optional. It is the foundation for software you can defend.
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands an article and a post first published by the author on LinkedIn.
