An SBOM Is an Inventory. It Isn't Proof Your Software Is Safe.

There's a familiar move in technology procurement: take something genuinely useful, turn it into a checkbox, and then quietly start treating the checkbox as evidence that the underlying problem has been solved. The software bill of materials, or SBOM, is vulnerable to exactly that treatment. An SBOM can tell you what components are represented in a software product. That is valuable information. But it cannot, by itself, tell you whether the build was compromised, whether a dependency is configured safely, whether the software can be exploited in your environment, or whether the vendor will respond competently when something goes wrong.

The National Telecommunications and Information Administration defined minimum SBOM elements to improve software-component transparency, including baseline data fields, automation support, and operational practices (National Telecommunications and Information Administration [NTIA], 2021). That's a useful starting point. It isn't a certificate of security, and the distinction matters when an executive is deciding whether to approve a product, an engineer is deciding what to ship, or a security team is deciding what to do after a vulnerability announcement.

If a widely used library develops a serious vulnerability, an accurate component inventory may help you identify affected products faster than manually interrogating every development team. It can also help establish relationships among packages, suppliers, and versions. That's the straightforward promise of an SBOM: improved visibility into software composition (NTIA, 2021).

Now consider what the inventory doesn't tell you. A component may appear in the build but never execute in the vulnerable configuration. A vulnerable function may be present yet unreachable from any realistic attacker-controlled input. Conversely, a component may be omitted because the inventory was generated at the wrong stage, the build process changed, or a supplier's declaration was incomplete. A clean-looking inventory can coexist with a compromised release process.

The practical question is therefore not simply whether the supplier has an SBOM. It's whether the SBOM corresponds to the artifact you actually received, whether it is sufficiently complete for the decision you're making, and whether you can use it when the situation changes. An inventory that arrives six months after the release and cannot be matched to a deployed version may satisfy a procurement request while offering little operational value.

NIST's Secure Software Development Framework describes practices that can be incorporated into software development life cycles to reduce vulnerabilities and address their root causes (Souppaya et al., 2022). Its scope is broader than a list of dependencies. It addresses the people, practices, environments, and evidence involved in producing software.

That distinction is especially important in modern build pipelines. A team can use well-maintained dependencies and still expose a release through stolen signing credentials, an overprivileged build runner, an unreviewed deployment change, or an unprotected artifact repository. None of those problems is solved by knowing the names of the libraries in the final package.

When I look at a software assurance claim, I want to know how source changes are reviewed, how build identities are protected, how dependencies are selected, how releases are tied to source and build records, and who can interrupt publication when something doesn't add up. These are questions about control and accountability. The SBOM can be part of the evidence, but it isn't a substitute for the system that produces the evidence.

CISA and partner agencies have argued for shifting more of the security burden toward technology producers through secure-by-design and secure-by-default practices (Cybersecurity and Infrastructure Security Agency et al., 2023). I agree with the direction of that argument: customers shouldn't have to compensate indefinitely for avoidable product weaknesses. But the procurement conversation still needs specificity. A supplier saying it follows secure-by-design principles isn't the same as showing how those principles affect its release process, default configuration, or vulnerability handling.

An SBOM can help identify components associated with known vulnerabilities. It cannot make every vulnerability equally important. A severe score may describe the potential consequences of exploitation under stated conditions, not the likelihood that your particular deployment can be attacked in that way. An organization can waste substantial effort treating every matching component as an identical emergency while missing the few exposures that genuinely threaten critical services.