EO 14028 SBOM Minimum Element Requirements
CISA's 2025 update adds hashes and context to make SBOMs verifiable, not just inventories.
Executive Order 14028 did not itself define what a Software Bill of Materials must contain. It ordered the Commerce Department to figure that out within 60 days, and the resulting NTIA document, published July 12, 2021, is still the closest thing the industry has to a shared definition of software transparency. This piece walks through what that baseline actually requires, where it has fallen short in the years since, and what CISA's 2025 revision changes about what an SBOM can prove.
What the NTIA's seven core data fields actually require
NTIA organized the minimum elements into three buckets: data fields, automation support, and practices and processes. The data fields are the part most people building software actually have to reckon with, and there are seven of them.
Supplier name identifies the entity that created or distributes the component, which is not always the same party as the original author. Component name and version follow directly. Version matters more than it sounds like it should: a missing or vague version string breaks vulnerability matching, because a CVE database entry is only as useful as the version range it applies to. Other unique identifiers, things like package URL (purl) or CPE, give that matching process something machine-resolvable to key off, linking a component to the registries and vulnerability feeds that track it.
Dependency relationship is the field that turns a list into a graph: it records which component depends on which, so a consumer can trace a vulnerability through nested inclusions rather than just checking a flat inventory. Author of the SBOM data establishes who assembled the document, distinct from who supplied the component, which matters for accountability when the document turns out to be wrong. Timestamp closes the loop by telling a consumer whether the SBOM reflects the software's current state or a snapshot from months ago.
NTIA framed these seven fields as enabling three baseline uses: vulnerability management, software inventory, and license management. The document was candid about its own limits, too. SBOM tooling was young in 2021, adoption had barely started, and the fields reflected what was achievable then, not what would prove sufficient later. On the automation side, NTIA accepted three machine-readable formats: SPDX, CycloneDX, and SWID.
Where the 2021 baseline falls short in practice
The dependency relationship field tells you that component A depends on component B. It says nothing about whether the B that actually got compiled into the binary is the same B the document describes. That gap sits at the center of everything wrong with the 2021 baseline.
No hash requirement means a supplier could substitute a component after the SBOM was generated, and the document would never reflect the swap. The SBOM asserts intent, not delivery. No generation context field means a consumer has no way to tell whether the document came from a build-time process (the most reliable method), a static read of source code, or a post-deployment scan of a running container, three methods with very different failure modes and no way to distinguish among them from the document itself. No dedicated license field means the SBOM's support for legal or compliance work is limited, a real problem for any organization operating under copyleft obligations or trying to clear open-source components for commercial use.
Underneath all of this sits what amounts to a trust problem. An SBOM does not prove that the artifact delivered corresponds, reproducibly, to what the document describes. Absent a link between the SBOM and a verifiable build, the document is an assertion. It is not evidence.
The most damning fact about the 2021 baseline is how easy it was to satisfy on paper while missing the point entirely. A document assembled by hand at release time with only the seven required fields satisfied the letter of the minimum elements. It was also nearly useless. Log4Shell illustrated exactly why: organizations using flat component lists without transitive dependency graphs faced significant effort that shouldn't have been necessary just figuring out where they were exposed to the nested inclusions that constituted the actual attack surface.
What CISA's 2025 draft adds and why each new field changes what an SBOM can do
CISA published its public comment draft in August 2025, and the updated minimum elements replaced the NTIA 2021 baseline on July 29, 2026. Four new required fields do most of the work.
Component Hash requires a hash value and the algorithm used to generate it, or an explicit declaration that the SBOM author never had access to the original artifact. This is the field the 2021 baseline was missing most badly: it lets a consumer confirm that the component actually in the binary matches the component described in the document, which makes substitution attacks detectable rather than invisible.
Component License requires the license under which a component is available, in machine-processable form where that's possible, including flagging proprietary license conditions. This closes the legal-use gap the 2021 fields left wide open. Recording which tool generated the document supports auditability, since a tool with known gaps in its dependency resolution behaves differently from one without them, and a consumer needs to know which one produced the SBOM in front of them.
SBOM Generation Context records whether the document was produced pre-build, during the build, or through post-build inspection. It doesn't force build-time generation. It forces disclosure when a less reliable method was used, which lets downstream consumers calibrate how much to trust the document instead of assuming uniform reliability across every SBOM they receive.
CISA also renamed "supplier name" to "software producer," with a defined fallback of "unknown provenance" for cases where that information genuinely isn't available, a practical concession to how open-source ecosystems actually work. SWID is no longer favored, with SPDX and CycloneDX serving as the accepted formats going forward.
Taken together, these changes mark a shift from inventory to verifiability. The 2021 baseline asked what components exist. The 2025 draft asks whether those components can be confirmed and trusted, which is forensic readiness, not just documentation. And practically speaking, hashes, license data, and generation context can't be maintained accurately in a spreadsheet across any dependency graph of meaningful size. The new fields function as a forcing mechanism toward automated generation, whether or not that was the explicit intent.
How generation context connects SBOM accuracy to build environment discipline
Generation context is the field that makes build-time SBOM generation the industry's preferred method, because only a build-time SBOM captures transitive dependencies as they were actually resolved during that specific build, rather than as they were expected to resolve in theory. An SBOM assembled from inspecting a deployed container after the fact can miss components that got resolved and then discarded mid-build, or fail to catch a silent substitution the build system made along the way.
Environment drift is the mechanism that breaks build-time accuracy even when the process is followed correctly. If the build environment isn't locked down, the same source code can produce different binaries with different resolved dependencies on different runs, which means an SBOM generated on Tuesday may not describe what gets built on Thursday. Reproducible builds address this directly, and the results show the problem is solvable: as of July 2025, the Reproducible Builds project reported 99.5% reproducibility for SLES-16 packages, with only 9 of 3,319 source packages showing significant problems. That's not a lab result. That's a real distribution at scale.
The stakes of drift are structural, not cosmetic. A compromised or simply inconsistent build environment can affect every downstream artifact it touches, while the SBOM keeps asserting the original, clean dependency set it was generated against, oblivious to what actually shipped. The practical implication of generation context, then, is to generate a fresh SBOM per build and per image, and to alert on drift between releases, rather than treating an SBOM as a one-time artifact filed away at launch.
None of this bans post-hoc generation outright. It just requires teams to say so. That single disclosure requirement creates accountability pressure that didn't exist under the 2021 rules, where a spreadsheet from any point in the process satisfied the letter of the requirement.
Where SBOMs fit inside the larger evidence bundle that build integrity requires
An SBOM describes component transparency. It does not, on its own, establish build transparency, and conflating the two is where a lot of supply chain security programs quietly fail. Knowing what went into a build is not the same as cryptographically proving that what came out matches what went in.
Organizations converging on a serious supply chain security posture are assembling a three-part evidence bundle. Component transparency is the SBOM itself, listing dependencies, versions, and licenses. Build transparency comes from provenance attestations, cryptographic links between an artifact and the source commit, build environment, and CI workflow that produced it, using tooling like in-toto, Tekton Chains, and Sigstore. Vulnerability communication comes through VEX (Vulnerability Exploitability eXchange) statements, which tell a consumer which of the known CVEs sitting in the SBOM are actually exploitable in a given deployment, rather than leaving every listed component looking equally dangerous.
SLSA (Supply Chain Levels for Software Artifacts) provides the ladder for build transparency specifically. Level 1 requires a scripted, documented build process with basic traceability. The highest current level requires the strongest guarantees about build environment integrity and provenance trustworthiness. Under SLSA v1.0, Level 3 is the practical ceiling: reproducibility is treated as a best-effort goal rather than a hard requirement, and a formal Level 4 has been deferred to a future version of the spec.
Tooling designed for SLSA L3 provenance links each artifact to its source commit and CI workflow in a way that provides strong guarantees against forgery by parties involved in the build process. That distinction between observability and enforcement matters more than it might seem. A supply chain stack pairing SBOMs with provenance attestations and admission control illustrates it well: the SBOM gives visibility into what's there, but admission control is the actual gate that blocks an unverified image from running. An SBOM without enforcement behind it is documentation. It is not a control.
Teams that stop at "we generate an SBOM" have satisfied a paperwork requirement while leaving the actual trust gap wide open.
How SBOM requirements are spreading beyond federal procurement
Federal procurement was the starting point, not the endpoint. The FDA, effective March 29, 2023, requires manufacturers of "cyber devices," meaning devices that connect to a network or contain software with cybersecurity implications, to submit an SBOM during premarket review that meets or exceeds the NTIA minimum elements, plus end-of-life and support-level data per component and a vulnerability assessment with a remediation plan attached.
The U.S. Army's 2024 SBOM Directive converts the requirement into enforceable contract language for Army software procurement, which changes it from a policy expectation into something a vendor can actually be held to under contract. The EU's Cyber Resilience Act (CRA) goes further still, as binding legislation requiring SBOMs for products with digital elements sold into the EU market, covering manufacturers, importers, and distributors. Exact data field requirements under CRA, including how deep the dependency relationship must go, are deferred to future European Commission implementing acts, but the NTIA and CISA fields serve as the practical baseline vendors are building toward in the meantime.
PCI DSS 4.0 now carries software component inventory requirements for merchants and service providers handling cardholder data. Germany's BSI TR-03183-2 (v2.1.0) technical guideline defines concrete SBOM format and content requirements aligned with CRA, relevant to any vendor selling into German federal procurement. The UK's Software Security Code of Practice, published May 2025, is voluntary but sets baseline expectations for supply chain resilience and customer communication that B2B and SaaS vendors are already treating as a de facto standard.
What ties all of this together is format convergence. Every major framework assumes machine-readable SBOMs in a widely used format, CycloneDX or SPDX, and the FDA and other regulators explicitly reference the NTIA 2021 elements as their baseline, even as CISA's updated elements supersede that document at the source. Whatever framework a team is ultimately answering to, compliance work starts at the same seven fields.
What teams building or shipping software need to do with this in practice
SBOM generation belongs inside the build pipeline, generated automatically, not assembled by hand at release time. The generation context field exists specifically to expose the latter practice, and build-time generation is the only method that reliably captures transitive dependencies as they were actually resolved rather than as a manifest predicted they would be.
Format choice is largely settled at this point: SPDX and CycloneDX are accepted everywhere that matters, SWID has lost ground under CISA's updated guidance, and the practical task is picking one and confirming that existing tooling outputs it natively rather than requiring a conversion step that introduces its own errors.
Provenance and SBOM generation both need to be part of the development workflow from day one. A team that bolts SBOM generation onto the end of its release process will find that generation context, hash accuracy, and full transitive dependency coverage are much harder to retrofit than to build in from the start. Component hashes, for instance, require access to the original artifact at build time: teams building from source get this naturally, but teams consuming pre-built binaries need to confirm their tooling can actually resolve and record those hash values, or else declare the limitation honestly in the generation context field rather than leaving it silent.
License data collection tends to be the hardest field to automate well, especially across transitive dependencies of open-source components that carry mixed, inconsistent, or ambiguous license declarations. That work requires tooling that actually resolves licenses rather than tooling that just copies whatever a package's metadata claims, which is not always accurate. Dependency graphs, not flat lists, are the requirement now, which means tooling has to traverse transitive dependencies rather than stopping at what's declared directly in a manifest.
Underneath all of it sits the build environment itself. It has to be reproducible and locked, because an SBOM generated from a drifting environment describes a state that may no longer exist by the time anyone reads the document. Environment management approaches built on strict, Nix-style dependency pinning, the kind that underpin the reproducible builds work already showing results at scale, give teams the foundation that makes build-time SBOM generation something they can actually trust rather than something they merely produce.
The SBOM, in the end, is one component of a larger evidence bundle, not the whole of it. Treating it as the finish line is the single most common way organizations satisfy the paperwork while leaving the real question, whether what shipped can be trusted, entirely unanswered.
