The Baseline for SBOM Compliance
In July 2021, the National Telecommunications and Information Administration (NTIA) published "The Minimum Elements For a Software Bill of Materials." This document isn't a suggestion. It's the foundational standard that Executive Order 14028 references when it says software vendors must provide SBOMs to federal agencies.
Yet months after publication, most organizations generating SBOMs are still getting it wrong. They produce files that technically qualify as SBOMs but miss critical fields, lack automation, or ignore the distribution requirements entirely. The minimum elements document is only 26 pages. There's no excuse for not reading it. But since many haven't, let's walk through what actually matters.
The Three Categories
The NTIA breaks its minimum elements into three buckets: data fields, automation support, and practices and processes. Most people fixate on the first category and ignore the other two. That's a mistake.
Data Fields
Every SBOM must contain these baseline data fields for each component:
Supplier Name — The entity that creates, defines, or identifies components. This isn't always the same as the author. For open-source packages, it's typically the maintainer or publishing organization. Getting this wrong creates downstream confusion when you're trying to trace a vulnerability back to its source.
Component Name — The name assigned to the software unit by its original supplier. Sounds simple, but it gets complicated fast. Package managers, registries, and vendors don't all use the same naming conventions. lodash on npm, org.apache.commons:commons-lang3 on Maven Central, python3-requests in a Debian repository — these are all component names, but they follow wildly different formats.
Version of the Component — The version string as used by the supplier. Semantic versioning, date-based versioning, commit hashes — the NTIA doesn't prescribe a format. But whatever the supplier uses, that's what goes in the SBOM. Don't normalize or translate version strings. You'll lose fidelity.
Other Unique Identifiers — This includes CPE (Common Platform Enumeration), PURL (Package URL), SWID tags, or any other unique identifier that helps disambiguate components. PURL has emerged as the de facto standard for open-source components, and for good reason. It encodes the package type, namespace, name, and version in a single string.
Dependency Relationship — The SBOM must characterize the relationship between components. At minimum, this means documenting that Component A includes or depends on Component B. This is where most auto-generated SBOMs actually do well, since package managers already track dependency trees. But vendored dependencies, statically linked libraries, and embedded firmware still trip people up.
Author of SBOM Data — The entity that creates the SBOM. This is distinct from the software supplier. If you're a systems integrator generating SBOMs for software you didn't write, you're the SBOM author, not the supplier. This distinction matters for accountability.
Timestamp — When the SBOM was created. Not when the software was built. Not when it was published. When the SBOM data was assembled. Use ISO 8601 format. Always include timezone information.
Automation Support
This is where most organizations stumble. The NTIA explicitly states that SBOMs must be machine-readable. A PDF listing your dependencies doesn't count. A spreadsheet doesn't count. The document identifies three recognized formats:
- SPDX (Software Package Data Exchange) — An ISO standard (ISO/IEC 5962:2021) maintained by the Linux Foundation.
- CycloneDX — An OWASP project that's gained significant traction, particularly in the security community.
- SWID (Software Identification) Tags — An ISO standard (ISO/IEC 19770-2) that predates the SBOM movement.
In practice, the market has converged on SPDX and CycloneDX. SWID tags still show up in enterprise software, but they're increasingly rare in modern development.
The automation requirement goes beyond just the format. SBOMs must be generated automatically as part of the build process, not manually assembled after the fact. Manual SBOM creation is error-prone, doesn't scale, and becomes stale immediately.
Practices and Processes
The third category is the one everyone skips, and it's arguably the most important for operationalizing SBOMs:
Frequency — SBOMs must be generated for every new release or update. If you're shipping software updates monthly, you need monthly SBOMs. If you're doing continuous deployment, you need SBOMs for every deployment. The NTIA recognizes this can be burdensome, which is why automation support is a separate requirement.
Depth — The NTIA acknowledges that full transitive dependency enumeration isn't always possible. When you can't enumerate all dependencies, you must document where the enumeration stops and why. "Known unknowns" are acceptable. Pretending your SBOM is complete when it isn't is not.
Distribution and Delivery — SBOMs must be made available to the people who need them. The NTIA doesn't mandate a specific distribution mechanism, but it does require that organizations define and follow a process. Some organizations embed SBOMs in their software packages. Others publish them to a registry. Some deliver them on request. All of these can work, as long as the process is documented and followed.
Access Control — The NTIA recognizes that SBOMs can contain sensitive information about software architecture. Organizations may need to implement access controls on who can view detailed SBOM data. This is particularly relevant for defense contractors and organizations handling classified software.
Where Organizations Get It Wrong
After reviewing hundreds of SBOMs across the industry, the same failures come up repeatedly:
Missing Dependency Relationships
The most common problem. Many tools generate flat component lists without any relationship data. An SBOM that says "this software contains components A, B, C, D, and E" without specifying that A depends on B which depends on C is nearly useless for vulnerability triage. When Log4Shell hit, organizations with flat SBOMs still had to manually trace which applications actually used Log4j, because the dependency chain wasn't documented.
Incomplete Transitive Dependencies
Your application might directly depend on 50 packages. Those 50 packages might pull in 500 more. The NTIA minimum elements require you to document transitive dependencies to the extent feasible. Many SBOM generators only capture direct dependencies, missing the deep tree where most vulnerabilities actually live.
Stale SBOMs
Generating an SBOM once and never updating it is worse than having no SBOM at all. It creates a false sense of security. If your SBOM says you're running Log4j 2.14 but you patched to 2.17 three months ago, the SBOM is actively misleading anyone who consumes it.
No PURL Identifiers
Without Package URLs, correlating SBOM components to vulnerability databases becomes a manual exercise. PURL adoption has improved significantly, but plenty of SBOM generators still output components with only name and version, leaving out the unique identifier that makes automated vulnerability matching possible.
Ignoring the "Known Unknowns" Requirement
The NTIA explicitly asks for honesty about SBOM completeness. If your build process includes vendored C libraries that your SBOM tool can't introspect, say so. Mark those components as unknown. The minimum elements document includes provisions for this exact scenario. Most organizations just pretend the gap doesn't exist.
SPDX vs. CycloneDX for NTIA Compliance
Both formats satisfy the NTIA minimum elements. The choice between them often comes down to ecosystem and use case:
SPDX excels at license compliance and has strong support in legal and procurement contexts. Its ISO standardization gives it weight in regulated industries. However, the specification can be verbose, and tooling has historically been less accessible.
CycloneDX was designed from the ground up for security use cases. It's more concise, has a lower barrier to entry for tooling, and maps cleanly to vulnerability databases. Its VEX (Vulnerability Exploitability eXchange) integration is also more mature.
For NTIA minimum elements compliance, either works. Pick the one that fits your tooling and downstream consumers.
Practical Implementation Checklist
If you're starting from zero, here's a concrete path to NTIA-compliant SBOMs:
- Pick a format — CycloneDX or SPDX. Don't overthink this.
- Integrate SBOM generation into your CI/CD pipeline — Every build should produce an SBOM automatically.
- Validate your SBOMs — Both CycloneDX and SPDX have validation tools. Use them. A malformed SBOM is worse than no SBOM.
- Include PURL identifiers — Configure your SBOM generator to output Package URLs for every component.
- Document your depth — If your SBOM doesn't capture everything, say so explicitly in the SBOM metadata.
- Establish a distribution process — Decide how you'll deliver SBOMs to consumers and document it.
- Set up a refresh cadence — Every release, every deployment, every significant change.
Beyond Minimum: Where the Standard Is Heading
The NTIA minimum elements are just that — a minimum. The industry is already moving beyond these baseline requirements:
- VEX documents alongside SBOMs to provide vulnerability exploitability context
- Build provenance attestations (SLSA framework) to verify how software was built
- Runtime SBOMs that capture the actual components loaded in production, not just what was packaged
- SBOM-as-a-service platforms that continuously monitor and update SBOM data
The minimum elements were designed as a starting line. If your organization treats them as a finish line, you'll find yourself scrambling when the next evolution of requirements drops.
How Safeguard.sh Helps
Safeguard generates NTIA-compliant SBOMs in both CycloneDX and SPDX formats, with full transitive dependency resolution, PURL identifiers, and proper relationship mapping out of the box. SBOM generation integrates directly into your CI/CD pipeline, so every build automatically produces an up-to-date, machine-readable SBOM that meets every minimum element the NTIA requires. When gaps exist, Safeguard flags them — so you can document your known unknowns instead of shipping incomplete data and hoping nobody notices.