The Cybersecurity and Infrastructure Security Agency (CISA) has been at the forefront of operationalizing SBOMs for the US government. Since Executive Order 14028 mandated SBOM-related requirements in May 2021, CISA has been developing guidance, facilitating working groups, and establishing the practical frameworks that government agencies need to actually implement SBOM programs.
For software producers selling to the government, and for the agencies themselves, understanding CISA's evolving guidance is essential.
The NTIA Minimum Elements
Before CISA's work, the National Telecommunications and Information Administration (NTIA) published "The Minimum Elements for a Software Bill of Materials" in July 2021. This document established the baseline data fields that every SBOM must contain:
Required Data Fields
Supplier Name: Who created the component (organization or individual).
Component Name: The name of the software component as defined by its supplier.
Version: The version identifier used by the supplier.
Unique Identifier: A unique identifier for the component (such as a Package URL or CPE).
Dependency Relationship: Which components are dependencies of which other components.
Author of SBOM Data: Who created the SBOM (may differ from the component supplier).
Timestamp: When the SBOM was generated.
These seven fields are the absolute minimum. A useful SBOM typically includes additional data: license information, download URLs, checksums, and vulnerability status.
CISA's SBOM Working Groups
CISA organized multiple working groups to address the practical challenges of SBOM adoption:
SBOM Tooling and Implementation
This working group focuses on the tools and processes needed to generate, consume, and manage SBOMs. Key outputs include:
- Surveys of available SBOM generation tools
- Guidance on tool selection criteria
- Reference architectures for SBOM management
SBOM Sharing and Exchange
How do you get SBOMs from producers to consumers? This working group addresses:
- Distribution mechanisms (API, registry, artifact attachment)
- Access control (who can see which SBOMs?)
- Update frequency (how often should SBOMs be regenerated?)
SBOM Awareness and Adoption
Focused on education and outreach to increase SBOM adoption across both government and private sector.
What Agencies Must Do
Government agencies operating under Executive Order 14028 need to:
1. Require SBOMs in Procurement
New software procurements should include SBOM requirements in contracts. At minimum:
- Vendors must provide SBOMs for all delivered software
- SBOMs must meet NTIA minimum element requirements
- SBOMs must be delivered in a machine-readable format (CycloneDX or SPDX)
- SBOMs must be updated with each software release
2. Build SBOM Consumption Capability
Receiving an SBOM is useless if you cannot process it. Agencies need:
- Storage infrastructure for managing SBOMs across their software portfolio
- Analysis tools that correlate SBOM data with vulnerability databases
- Query capability to answer "are we affected?" when a new CVE is announced
- Integration with existing asset management to link SBOMs to deployed systems
3. Establish SBOM Lifecycle Management
SBOMs are not static documents. They must be:
- Regenerated with every software release
- Monitored continuously against evolving vulnerability databases
- Compared across versions to identify changes in the dependency tree
- Archived for audit and compliance purposes
4. Use SBOMs for Risk Management
SBOMs enable risk management practices that were previously impossible:
- Pre-deployment assessment: Before deploying new software, check its SBOM for known vulnerabilities and license issues
- Continuous monitoring: Correlate SBOM data with new CVE announcements to identify affected systems
- Incident response: When a vulnerability like Log4Shell is announced, query all SBOMs to determine exposure across the agency
- Vendor risk assessment: Evaluate the security posture of vendor software based on its SBOM
Challenges in Practice
Incomplete SBOMs
Many vendors are still learning how to generate SBOMs. The first SBOMs you receive will likely be incomplete — missing transitive dependencies, lacking version information for some components, or using inconsistent naming conventions.
Recommendation: Accept imperfect SBOMs and work with vendors to improve quality over time. A partial SBOM is better than no SBOM.
Format Fragmentation
Some vendors will deliver SBOMs in CycloneDX; others in SPDX. Some will use JSON; others XML. Your consumption infrastructure needs to handle all of these.
Recommendation: Use tools that support multiple formats and can normalize SBOM data into a consistent internal representation.
Volume Management
A large agency may receive thousands of SBOMs from hundreds of vendors, each updated with every release. Managing this volume requires automation.
Recommendation: Invest in automated SBOM ingestion, parsing, and analysis. Manual review does not scale.
Vendor Resistance
Some vendors view SBOMs as exposing their intellectual property or revealing unflattering dependency choices. They may push back on SBOM requirements.
Recommendation: Make SBOM delivery a contractual requirement. Frame it as a security necessity, not an IP exposure risk. SBOMs list components and versions — they do not reveal proprietary source code.
The Path Forward
CISA's guidance will continue to evolve. Expect:
- More specific requirements for SBOM depth (how many levels of transitive dependencies?)
- Integration with VEX (Vulnerability Exploitability eXchange) for contextual vulnerability data
- Mandatory SBOM requirements for critical infrastructure software beyond government
- Standardized APIs for SBOM exchange between producers and consumers
How Safeguard.sh Helps
Safeguard.sh provides a complete SBOM management platform that aligns with CISA's guidance and NTIA minimum elements. Our platform ingests SBOMs from multiple sources and formats, correlates them with vulnerability databases in real-time, and provides the query capabilities agencies need for incident response. For software producers, Safeguard.sh automates SBOM generation that meets government requirements, making compliance a natural part of the development workflow rather than a separate burden.