Most federal software is assembled, not written from scratch. A typical application pulls in open-source libraries, commercial components, and container base images, each with its own dependencies. A software bill of materials (SBOM) is how a program office finds out what is actually inside the system it is paying for, and how it learns quickly when a component becomes a problem.
What an SBOM Is
Executive Order 14028, "Improving the Nation's Cybersecurity" (May 2021), describes an SBOM as a formal record containing the details and supply chain relationships of the components used in building software.[1] Think of it as an ingredients list: component names, versions, who supplied them, and how they relate to one another.
An SBOM does not tell you that software is secure. It tells you what to look at when a new vulnerability is announced. Its value comes from what you do with it, which is why this article spends as much time on tracking and contracting as on formats.
Formats and Minimum Elements
SPDX and CycloneDX
Two machine-readable formats dominate. SPDX, developed under the Linux Foundation, is recognized as an international standard (ISO/IEC 5962:2021).[5] CycloneDX, which originated in the OWASP community, is also standardized through Ecma International.[6] Both can express components, versions, suppliers, and dependency relationships, and both are supported by common open-source generation tools. Pick one as the contractual default, but allow the other if it carries the same required data.
The NTIA Minimum Elements
In July 2021 the National Telecommunications and Information Administration (NTIA) published "The Minimum Elements For a Software Bill of Materials," as directed by the executive order.[2] It groups the minimum into three areas:
- Data fields: supplier name, component name, component version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp.
- Automation support: the SBOM must be in a machine-readable format such as SPDX or CycloneDX so it can be ingested by tooling rather than read by hand.
- Practices and processes: how often SBOMs are produced and updated, how deep the dependency listing goes, how unknown dependencies are flagged, how SBOMs are distributed, how access is controlled, and how mistakes are corrected.
CISA, which now coordinates federal SBOM work, publishes updated guidance and community resources at its SBOM page.[3] Treat the NTIA elements as a floor and check CISA's current materials before finalizing requirements.
EO 14028 and Secure Development Attestation
Section 4 of EO 14028 directed NIST and other agencies to strengthen software supply chain security for software sold to the government.[1] NIST's response includes the Secure Software Development Framework (SSDF), SP 800-218, a set of high-level practices for preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.[4]
OMB then directed agencies to obtain attestations from software producers that their development practices conform to NIST guidance, and CISA published the Secure Software Development Attestation Form, often called the common form, for that purpose.[7] Federal policy on attestation and SBOM collection has been revised since it was first issued, so confirm the current OMB direction and your agency's own policy rather than relying on any single memo cited in an older solicitation.
For a program manager, the practical point is stable even when memo numbers change: ask the supplier to state, in writing and with an accountable signatory, which secure development practices they follow, and ask for the SBOM that shows what the product contains.
Turning an SBOM Into Vulnerability Tracking
An SBOM sitting in a shared folder protects nothing. It becomes useful when it is matched against vulnerability data.
KEV: Prioritize What Is Being Exploited
CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of active exploitation.[8] Matching SBOM components against KEV helps a team decide what to fix first, instead of treating every scanner finding as equally urgent.
VEX: Say What Is Actually Affected
A component in an SBOM may have a published vulnerability that is not exploitable in the way the product uses it. A Vulnerability Exploitability eXchange (VEX) statement lets a supplier say so. CISA's VEX guidance describes status values such as not affected, affected, fixed, and under investigation.[3] Requesting VEX alongside the SBOM cuts down on noise and gives the government a documented answer for each finding.
Open-Source Risk
Open source is not the problem; unmanaged open source is. Useful questions for any program include:
- Are direct and transitive dependencies both listed?
- Are components pinned to specific versions and sources?
- Is anyone watching for abandoned, unmaintained, or unexpectedly changed packages?
- Are license obligations recorded, since SPDX and CycloneDX can both carry license data?
- Is there a defined path to patch or replace a component when an upstream project stops responding?
Build Integrity: Provenance and Signing
An SBOM describes contents; it does not prove that the artifact you received was built from the source and process claimed. That gap is addressed by build provenance and signing. The SLSA framework (Supply-chain Levels for Software Artifacts) from the OpenSSF defines progressively stronger expectations for build provenance and tamper resistance,[9] and the SSDF's practices on protecting software and verifying integrity point the same direction.
In practice, this means asking suppliers whether builds run on hardened, access-controlled systems; whether the build generates signed provenance; whether release artifacts are cryptographically signed; and whether the receiving environment verifies signatures before deployment.
Writing SBOM Requirements Into a SOW
Requirements that are vague get vague deliverables. Consider including the following, adjusted to your agency's policy and your contracting officer's guidance:
- Format and content: machine-readable SBOM in SPDX or CycloneDX that meets, at minimum, the NTIA data fields.
- Depth: direct and transitive dependencies, with unknown or unresolved components explicitly flagged.
- Cadence: a new SBOM with each release and whenever a component changes, not only at initial delivery.
- Vulnerability handling: VEX statements for findings the supplier believes are not exploitable, and a stated timeframe for addressing KEV-listed vulnerabilities in delivered components.
- Attestation: a signed secure development attestation aligned to SSDF, using the CISA common form where the agency requires it.
- Integrity: signed release artifacts, and provenance information where the program's risk justifies it.
- Delivery and access: where the SBOM is delivered, who may see it, and how errors are corrected.
- Flow-down: the same requirements pass to subcontractors and third-party component suppliers.
Tracking It After Award
Add SBOM delivery to the contract deliverables schedule and review it like any other deliverable. Many programs find a small set of recurring questions enough: Did we receive an SBOM for this release? Does it parse in our tooling? What is new since the last release? Which findings are in KEV, and which have a VEX statement? Supply chain risk management guidance such as NIST SP 800-161 Rev. 1 can help structure how those reviews feed into the wider risk picture.[10]
Key Takeaways
- An SBOM is an inventory, not a security guarantee; its value comes from tracking.
- Use SPDX or CycloneDX and require at least the NTIA minimum elements.
- Pair SBOMs with VEX and the CISA KEV catalog to prioritize real risk.
- Ask for secure development attestation based on NIST SSDF, and verify current OMB and agency policy.
- Add signing and provenance to show that what was delivered matches what was built.
- Write the requirements into the SOW, schedule the deliverables, and review them on a cadence.
References
- Executive Order 14028, "Improving the Nation's Cybersecurity," May 12, 2021, Federal Register: federalregister.gov
- NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)," July 2021: ntia.gov
- CISA, "Software Bill of Materials (SBOM)," including VEX resources: cisa.gov/sbom
- NIST, SP 800-218, "Secure Software Development Framework (SSDF) Version 1.1": csrc.nist.gov
- SPDX project, Linux Foundation: spdx.dev
- CycloneDX specification (OWASP / Ecma International): cyclonedx.org
- CISA, "Secure Software Development Attestation Form": cisa.gov
- CISA, "Known Exploited Vulnerabilities Catalog": cisa.gov/known-exploited-vulnerabilities-catalog
- OpenSSF, "SLSA: Supply-chain Levels for Software Artifacts": slsa.dev
- NIST, SP 800-161 Rev. 1, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations": csrc.nist.gov
Conclusion
SBOMs work when they are requested precisely, delivered regularly, and connected to vulnerability intelligence and build integrity checks. Program managers do not need to become tool experts; they need clear SOW language, a deliverables schedule, and a short list of review questions. If you would like to talk through how this applies to a specific program, get in touch with our team.
