What Is a Software Bill of Materials (SBOM)?
Ramirez often compares SBOMs to nutrition labels. His daughter has celiac disease, so he studies food labels closely to avoid hidden gluten. A person can look at a package and not see the word “gluten” anywhere, he says, but still be at risk because ingredients such as soy sauce may contain it. The danger is buried in the fine print.
Modern applications work the same way. They pull in open-source libraries, frameworks, plugins and third-party services, and those pieces pull in other dependencies of their own. In the 2021 Log4j incident, the vulnerability lived in a code library several layers down, not in the main executable that agencies saw, Ramirez says. Without an SBOM software tool that surfaces those layers, that kind of risk is easy to miss.
Traditional manufacturing uses bill of material software to track physical parts, and an SBOM does the same for digital parts: core modules, open-source packages, third-party software development kits and the versions that tie them together. Because SBOMs are machine readable, government agencies can feed them into scanners and asset inventories instead of relying on manual spreadsheets.
DIVE DEEPER: Five ways that governments benefit from platform engineering.
Why Do SBOMs Matter for State and Local Cybersecurity?
For state and local governments, the biggest benefit of SBOMs is speed and clarity when new vulnerabilities hit the headlines. Once an SBOM is available, agencies can plug it into their security tools so the tools can map known issues to specific components, Ramirez says.
“You can take that SBOM and put it into your scanner so it can tell you what your potential issues are,” he says.
The challenge, then, is separating signal from noise. A security scanner may flag long lists of vulnerable packages. What agencies really need to know is which of those packages are actually present and being used in production. SBOMs help bridge that gap by linking vulnerability data to the specific versions and dependencies inside each application.
Ramirez emphasizes that having a machine-readable “recipe” and piping it into tooling “helps to reduce the amount of time it takes you to determine whether or not you’re actually vulnerable or susceptible to a vulnerability.”
That time savings is crucial when critical public services are at stake. With SBOMs in hand, security teams can quickly see where shared components appear across systems and prioritize mitigation accordingly.
READ MORE: State and local agencies turn to AI for improved services.
How Can SBOMs Reduce Risk in AI-Enhanced Applications?
AI-enhanced applications introduce another layer of dependencies in the form of models, frameworks, plugins and external services. The SBOM concept can extend into what some call an AI SBOM or AI bill of materials.
The same principles apply: Agencies need to understand the AI libraries and frameworks, such as PyTorch or TensorFlow, and the large language models that vendors embed, Ramirez says. Those components should show up right alongside traditional software dependencies in the SBOM so governments can quickly determine which applications might be affected when an AI component is found vulnerable or misconfigured.
An AI SBOM also helps address “shadow AI,” the AI equivalent of shadow IT. Ramirez points out that many government agencies define a clear set of approved tools, but some staff will experiment with other services when they cannot get what they need fast enough. If teams generate SBOMs and AI SBOMs for production systems, they can spot unexpected AI components and bring them under governance.
What Are Best Practices for Operationalizing SBOMs for Governments?
SBOMs are most effective when agencies build them into the full lifecycle of how they buy and manage software.
Ramirez recommends starting with procurement. Requests for proposals and contracts should make it clear that SBOMs are required deliverables, not optional extras. He suggests that agencies explicitly call out standard formats such as SPDX or CycloneDX and require vendors to provide SBOMs in those formats so governments can plug them into existing bill of materials software and vulnerability management tools.
He also stresses that SBOMs cannot be one-and-done documents. If a vendor ships a new version of its application or updates key components, the SBOM must be updated as well. Otherwise, the inventory becomes stale and security teams may chase the wrong issues. Contracts should specify how often SBOMs must be refreshed and how quickly vendors must provide them after a significant change, Ramirez says.
Flow-down clauses are another important element. When prime contractors rely on subcontractors and third-party modules, the SBOM requirements should apply to everyone in that chain so agencies get a complete picture of their dependencies, not just the top-level vendor’s view.
Once SBOMs arrive, they need to be used, not shelved. Ramirez warns against simply storing SBOMs as PDFs in a shared folder. To get value, government agencies should centralize machine-readable SBOMs in a repository, tie them to asset inventories, and feed them into scanners and risk engines. That turns the SBOM from static documentation into an active part of continuous monitoring.
Finally, SBOMs should be paired with additional context so teams can focus on real risk. Ramirez points to the role of VEX, or vulnerability exploitability exchange, data that lets vendors explain whether a known vulnerability is actually reachable in a particular product. Combining an SBOM with VEX and real-world usage data helps security teams avoid overreacting to every headline while still moving fast when there is genuine exposure.
