NIST Builds SBOM Use Cases for DevSecOps Pipelines
The NCCoE's example builds move beyond generating an SBOM to integrating cryptographic signing at each build stage and operationalizing vulnerability detection, bridging the June cyber EO's SSDF tasking to actual infrastructure.
TL;DR
NIST's National Cybersecurity Center of Excellence is publishing example builds that show how to use SBOMs for active supply-chain scanning and vulnerability management, rather than simply generating and storing them. The builds integrate cryptographic hashing and signing at each stage of the DevSecOps pipeline. The work responds to the Trump administration's June 6 cyber executive order directing NCCoE to demonstrate SSDF implementation practices. Michael Ogata, NCCoE computer scientist, described the efforts at the Billington Cybersecurity Summit, noting that two example builds have been published so far under the DevSecOps project, with more planned for vulnerability management workflows.
NIST's National Cybersecurity Center of Excellence is tackling the practical gap that's dogged SBOM adoption since the concept entered federal procurement: having an SBOM isn't the same as using one.
At the Billington Cybersecurity Summit on September 8, NCCoE computer scientist Michael Ogata described a two-stage DevSecOps project that's building reference implementations for what SBOM operationalization actually looks like. The first stage covers SBOM generation integrated into cloud-hosted build pipelines, with cryptographic hashing and signing enabled at each stage of the development process. "It is very simple to enable certain SBOM generation in your tool chain," Ogata said. "But in our example builds, we have also enabled cryptographic hashing and signing at each stage throughout the development process."
The second stage (still in development) goes further: example builds that demonstrate what to do with an SBOM beyond "just storing it away in a database somewhere." That work aims to help organizations inject vulnerability data from national vulnerability databases into their infrastructure and determine where patching is needed. Ogata told Inside Cybersecurity after the panel that two example builds have been published so far.
The effort executes a tasking from the June 6 cyber executive order, which directed NCCoE to "demonstrate the implementation of software development, security and operations practices" from NIST's Secure Software Development Framework (SP 800-218). The NCCoE had already launched its DevSecOps project in 2022, but the EO gave it new urgency and a formal demonstration mandate.
AI agents and SBOM provenance
Ogata also sketched how SBOMs intersect with the NCCoE's emerging work on agentic AI security. He argued organizations deploying AI agents in software development lifecycles will need policies requiring SBOM generation for the models and tooling those agents use. His scenario: an agent tasked with vulnerability hunting and code generation needs least-privilege and zero-trust access controls to avoid overstepping. And the downstream question ("what tool did you use? Did you use some vulnerable model for building the infrastructure you have built?") points toward AI model provenance becoming a supply-chain attestation concern.
That framing aligns with NIST SP 800-218A, the SSDF Community Profile for generative AI and dual-use foundation models published in July 2024. That document adds AI-specific practices and tasks to the SSDF baseline, covering model development across the software development lifecycle.
CISA's side of the equation
CISA associate director for vulnerability management Jay Gazlay, speaking on the same panel, noted that the agency finalized updated SBOM minimum elements guidance on July 29, an evolution of the 2021 NTIA framework. Gazlay said federal agencies that develop software now know what's on their edge and can better protect it. But he was blunt about what hasn't worked: "We still have vendors who are afraid to tell us that they don't know what happened to their software development lifecycle."
Gazlay said CISA has considered mandates but prioritized updating minimum elements and harmonizing requirements with international partners. Former CISA SBOM lead Allan Friedman told Inside Cybersecurity that NIST's use-case work represents "certainly the most mature part of supply chain transparency," noting the availability of open-source tooling from a developer's perspective.
The NCCoE hasn't given a timeline for publishing the full set of example builds beyond the two currently available. But the direction is clear enough: the federal expectation is shifting from "hand over an SBOM" to "show us you're using it continuously." That's a different kind of audit conversation, and the NCCoE builds are the closest thing to a reference architecture for it.
Published ·Deep Fathom