SBOMs Are No Longer Optional
Executive Order 14028, signed on May 12, 2021, introduced the most significant federal mandate for software transparency in decades. Among its many directives, the requirement for Software Bills of Materials (SBOMs) stands out as the most immediately actionable — and the most challenging for organizations that haven't invested in software composition visibility.
An SBOM is a machine-readable inventory of every component in a software product. Think of it as a nutrition label for software. It lists the ingredients — open-source libraries, third-party components, internal modules — along with their versions, licenses, and relationships.
The concept isn't new. NTIA has been working on SBOM standards since 2018. But EO 14028 transformed SBOMs from a nice-to-have into a procurement requirement for anyone selling software to the federal government.
What the EO Actually Requires
Section 4(e) of EO 14028 directs NIST to publish guidelines that include "guidelines recommending minimum standards for vendors' testing of their software source code, including identifying recommended types of manual or automated testing... as well as identifying or developing a standard set of tools and practices."
More specifically, Section 4(f) directs the Secretary of Commerce to publish "minimum elements for an SBOM" drawing on existing NTIA work. The NTIA Minimum Elements document, published in July 2021, specifies:
Data Fields
- Supplier Name — Who provided the component
- Component Name — The name of the software component
- Version — The version identifier
- Other Unique Identifiers — CPE, PURL, or SWID tag identifiers
- Dependency Relationship — How components relate to each other (direct vs. transitive)
- Author of SBOM Data — Who generated the SBOM
- Timestamp — When the SBOM was generated
Automation Support
SBOMs must be machine-readable. The two recognized formats are:
- SPDX (Software Package Data Exchange) — An ISO standard (ISO/IEC 5962:2021) maintained by the Linux Foundation. Supports RDF, JSON, YAML, and tag-value formats.
- CycloneDX — An OWASP standard designed specifically for security use cases. Supports JSON and XML. More opinionated about vulnerability correlation.
Both formats satisfy the EO requirements. The choice between them often comes down to ecosystem and tooling. CycloneDX tends to be preferred in application security contexts; SPDX has deeper roots in license compliance.
Practices and Processes
- SBOMs must be generated for each software release
- SBOMs should be updated when components change
- Suppliers must be able to provide SBOMs to customers upon request
- There should be mechanisms for discovering and tracking components across organizational boundaries
The Practical Challenges
Transitive Dependencies
The average modern application has hundreds of transitive dependencies — libraries pulled in by your direct dependencies. A Node.js project with 20 direct dependencies might have 500+ packages in its node_modules folder. An SBOM must capture all of them.
Most developers don't know what's in their transitive dependency tree. They've never looked. Generating a complete SBOM requires tools that can resolve entire dependency graphs, not just list direct imports.
Multi-Layer Applications
Modern software isn't a single artifact. It's a container image based on Ubuntu, running a Python application with pip dependencies, which calls a Go microservice with its own module dependencies, all orchestrated by Kubernetes manifests referencing specific image tags.
A complete SBOM needs to cover every layer: the OS packages, the language-specific dependencies, the container base image, and the application code. Different tools cover different layers, and stitching together a comprehensive view is non-trivial.
Keeping SBOMs Current
An SBOM is a snapshot. The moment you generate it, it starts going stale. New vulnerabilities are discovered daily. Dependencies auto-update. Container base images get patched. You need a process for regenerating SBOMs and correlating them against current vulnerability data.
A static SBOM sitting in a document repository has limited value. SBOMs need to be integrated into continuous monitoring workflows.
Vendor Dependencies
If your product includes third-party commercial components, your SBOM is only as complete as the SBOMs your vendors provide. If a vendor can't give you an SBOM for their library, you have a gap. Binary analysis tools can help, but they're imperfect.
Getting Started: A Practical Roadmap
Step 1: Inventory Your Build Systems
Before generating SBOMs, understand your build landscape. What languages do you use? What package managers? What container registries? What CI/CD systems? Each combination requires specific tooling.
Step 2: Choose Your Format
Pick CycloneDX or SPDX and standardize. You can always convert between formats later, but starting with a consistent format simplifies tooling and processes.
Step 3: Automate Generation
Integrate SBOM generation into your CI/CD pipeline. Every build should produce an SBOM alongside the artifact. Tools like Syft, Trivy, cdxgen, and CycloneDX plugins for Maven/Gradle/NPM can handle this.
Step 4: Store and Distribute
SBOMs should be stored alongside build artifacts. Consider an SBOM repository or integrate with your existing artifact management. Make SBOMs accessible to customers and auditors through a defined process.
Step 5: Correlate with Vulnerabilities
An SBOM without vulnerability correlation is just an inventory. Connect your SBOMs to vulnerability databases — NVD, OSV, GitHub Advisory Database — to identify which components have known CVEs. Automate this correlation continuously.
The Future of SBOMs
EO 14028 is the starting gun, not the finish line. Expect SBOM requirements to expand beyond federal procurement into regulated industries, insurance requirements, and enterprise procurement standards. The organizations that build SBOM capabilities now will have a significant advantage.
The shift toward software transparency is permanent. Regulation is catching up to what security practitioners have known for years: you can't secure what you can't see.
How Safeguard.sh Helps
Safeguard.sh automates the entire SBOM lifecycle that EO 14028 demands. The platform generates SBOMs in both CycloneDX and SPDX formats, covering all dependency layers — OS packages, language-specific libraries, container images, and transitive dependencies. Integration into your CI/CD pipeline means every build automatically produces a compliant SBOM without manual intervention.
Beyond generation, Safeguard.sh provides continuous SBOM monitoring. As new CVEs are published, the platform correlates them against your stored SBOMs and alerts you to newly affected components. This transforms SBOMs from static documents into living security tools that provide ongoing value.
For organizations navigating federal compliance, Safeguard.sh maps SBOM capabilities against EO 14028 requirements and NTIA minimum elements, identifying gaps in your current practice and providing actionable guidance. Whether you're preparing for your first federal contract or scaling SBOM operations across hundreds of products, the platform provides the automation and visibility to meet compliance requirements efficiently.