On July 29, 2026, CISA published the 2026 Minimum Elements for a Software Bill of Materials (SBOM), replacing the NTIA baseline in place since 2021, co-authored with the NSA, the FBI, and 15 international cybersecurity agencies.
The 2026 Minimum Elements for a Software Bill of Materials (SBOM) is CISA's updated specification for what data an SBOM must contain, and the most consequential change is structural, not numerical: the 2026 elements do not prohibit SBOMs generated from source manifests, but they do require authors to declare how the SBOM was generated, to hash the executable artifact, and to label each field they could not populate. A manifest-only SBOM now discloses its own gaps in machine-readable form.
MetaDefender Software Supply Chain is OPSWAT's software supply chain security platform, designed to analyze artifacts, binaries, and container image layers — the exact data category the new hash, generation-context, and coverage requirements now demand.
At a Glance
- 17 data fields — 9 SBOM Metadata, 8 Component Data
- 6 practices and processes
- 10 new fields, 8 major updates, 1 removal (Access Control, folded into Distribution and Delivery)
- Applies to all software, "including open source software, AI software, and SaaS"
- Not new requirements — a refinement of how organizations generate and request SBOMs
2026 SBOM Changes That Are Hardest for Source-Only SBOMs to Meet
1. Component Hash Value Requires the Executable Artifact
Component Hash Value and Component Hash Algorithm are specific about what gets hashed: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Not the manifest entry, and not the declared version string.
- A parser reading package-lock.json, pom.xml, or requirements.txt does not touch an executable artifact, so both hash fields return unknown
- Where a hash exists, the algorithm must use IANA Hash Function Textual Names and be approved by an authority such as NIST
- Hashes are what allow a recipient to confirm that the component described is the component shipped
2. SBOM Generation Context Makes the Method Part of the Record
SBOM Generation Context is the quietest addition, and the most structurally significant: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM." CISA defines three values — before build, build, and after build — and ties each to how the SBOM was produced: an SBOM drawn from source code maps to the earliest phase, while binary analysis tools land it at the latest.
- Procurement teams can specify which lifecycle phase they'll accept, favoring SBOMs drawn from the compiled artifact over source-level ones
- Vulnerability management platforms can weight findings by the declared context
- A source-derived SBOM remains permissible, but can no longer be presented as equivalent to one produced from the finished binary
3. Coverage Replaces Depth, With No Minimum
The 2021 Depth element required top-level dependencies only — a definition CISA now says "reflected the capabilities of SBOM tooling at the time rather than the depth of information needed to make informed security decisions." Coverage is more demanding: "all components that make up the target software, including transitive dependencies. There is no minimum depth."
The test is functional. A recipient "should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the component associated with the vulnerability." Absence becomes evidence, which holds only when coverage is sufficiently complete. Manifest parsing alone is unlikely to reach that standard for:
- Statically linked and vendored code — leaves no manifest entry
- C and C++ projects — no universal package manager tracks the DLLs and shared objects pulled in at build time
- Copied source code — which CISA describes as "effectively a dependency that is better tracked as a fork and a dependency relationship"
- Container image layers — packages installed by layer commands rather than declared in a manifest
Unknown Information Must Now Be Declared
- Authors should distinguish information unknown to them from information deliberately withheld
- Authors are recommended to maintain a process for recipients to inquire about redacted security-related content
- "Organizations may consider an SBOM incomplete if the SBOM author withholds essential component data"
- Accommodation of Mistakes was replaced on the basis that recipients "can expect SBOM data to be accurate" — errors from "selection of inadequate tools" are now legitimate input to a recipient's risk assessment
Additional Changes CISA Made to the 2026 SBOM Elements
Change | What it is | Why it matters |
SBOM Author Signature (new) | A digital signature tied to the SBOM author | Lets a recipient confirm the SBOM is authentic and wasn't altered after signing |
Component License (new) | The license each component ships under | Surfaces copyright and compliance risk; CISA points to SPDX license IDs |
Machine-Processable Data (was Automation Support) | SPDX and CycloneDX only | SWID dropped as not widely used; narrows accepted formats to two |
Component Producer (was Supplier Name) | One named org per component | Adds an explicit "unknown provenance" fallback when the source is unclear |
Frequency (updated) | A new SBOM for every version, update, and build that pulls in changed components | That cadence is hard to sustain by hand, which pushes teams toward automated generation |
Closing the Post-Build Gap
The 2026 update reflects CISA's assessment that SBOM tooling has matured enough to demand more, and the information it now expects resides on the far side of the build.
MetaDefender™ Software Supply Chain generates SBOM data directly from the built artifact:
- Scans artifacts, binaries, and container image layers rather than dependency files alone
- Identifies C, C++, and C# binaries through Portable Executable metadata and signature-based identification
- Generates SBOMs in CycloneDX and SPDX, and enriches existing reports to surface components and CVEs missed by prior scans
- Cross-references GHSA, CVE, and EUVD, and flags non-compliant licenses
- Integrates with CI/CD pipelines and artifact registries such as JFrog Artifactory, so SBOM generation can accompany each build
To learn how MetaDefender Software Supply Chain can support SBOM requirements across the development lifecycle:
FAQ
What changed in the CISA 2026 SBOM minimum elements?
The update adds ten new data fields, makes eight major revisions, and removes one element. The most significant structural change replaces Depth with Coverage, and new fields including Component Hash Value, SBOM Generation Context, and SBOM Author Signature raise expectations for how SBOM data is produced and verified.
Are the CISA 2026 SBOM minimum elements mandatory?
No. CISA sets no compliance deadline or enforcement mechanism, and states the document "does not constitute advice for compliance, regulatory, or legal purposes." Practical force comes from procurement requirements and from regulations that reference SBOM baselines, such as the EU Cyber Resilience Act.
Do the CISA 2026 SBOM minimum elements require binary or post-build analysis?
Not explicitly. However, Component Hash Value requires access to the executable artifact, SBOM Generation Context requires authors to declare the lifecycle phase, and unpopulated fields must be labeled unknown. A source-only SBOM therefore satisfies the format while documenting its own gaps.
Do the CISA 2026 minimum elements apply to AI software and SaaS?
Yes. Scope covers all software, including open source, AI, and SaaS. CISA notes these categories may warrant additional elements but does not define them here, referring instead to the G7 joint guidance on SBOM for AI published in May 2026.
Which SBOM formats are accepted in the CISA 2026 minimum elements?
SPDX and CycloneDX, described as the two formats widely used to generate and consume SBOMs. SWID tags were removed as "not a widely used SBOM data format for which multiple tools exist." Deprecated versions of any format should not be used for new software.
