Frequency
Define when SBOM data is generated or refreshed. A release process should make the timing predictable enough that consumers know whether the SBOM matches the software they are evaluating or operating.
Reviewed September 30, 2026CISA 2025 baseline
CISA's 2025 SBOM minimum elements turn the 2021 baseline into a more operational software inventory standard.
CISA's August 2025 Minimum Elements for a Software Bill of Materials updates the federal SBOM baseline with eleven minimum data fields, automation expectations, and practices for frequency, coverage, known unknowns, distribution, and updates. It also discusses SaaS, AI software systems, validation, and correlation with security advisories.
The 2021 NTIA minimum-elements report remains the historical foundation, but current implementation should use CISA's 2025 additions and revisions when defining a modern SBOM program.
2021 → 2025
Do not treat the old seven-field NTIA list as the complete current minimum.
The 2021 NTIA report established the core minimum-elements model around data fields, automation support, and practices/processes. CISA's 2025 update keeps that structure but materially revises it.
The most visible change is the data-field set. The 2025 document adds Component Hash, License, Tool Name, and Generation Context, while also making major or minor updates to several earlier fields. The result is an eleven-field current minimum set.
CISA also updates operational expectations around coverage, known unknowns, frequency, distribution and delivery, and how SBOM data is updated. Those process requirements matter because a technically valid file can still be useless if consumers cannot determine what it covers or when it is stale.
Minimum data fields
The 2025 CISA baseline identifies eleven fields.
Treat these as the minimum record needed to identify components and relationships. Your use case may require more.
| Field | What it tells the consumer |
|---|---|
| SBOM Author | Which entity created the SBOM data for the component. |
| Software Producer | Which entity creates, defines, and identifies the component. |
| Component Name | The producer-assigned name of the software component. |
| Component Version | The producer's identifier for the relevant software version. |
| Software Identifiers | Identifiers used to distinguish the component and support lookup/correlation. |
| Component Hash | A cryptographic value calculated from the software component. |
| License | The license or licenses under which the component is made available. |
| Dependency Relationship | How one component includes or is derived from another. |
| Tool Name | Which tool the SBOM author used to generate the SBOM. |
| Timestamp | When the SBOM data was most recently updated. |
| Generation Context | The lifecycle phase and information available when the SBOM was generated, such as before, during, or after build. |
Why the four new fields matter
Hash improves artifact/component correlation. License supports software asset and legal use cases. Tool Name makes generation provenance more inspectable. Generation Context helps a consumer understand why two SBOMs for the same product may differ depending on when in the lifecycle they were produced.
Automation support
Machine readability is necessary because the useful scale is larger than manual review.
CISA retains automation support as a minimum-element category. Operationally, that means the SBOM needs to be represented and exchanged in a form that tools can ingest and correlate rather than as an image or prose appendix.
Use industry-standard machine-readable representations supported by your producers, tooling, and consumers. The exact format matters less than whether component identifiers, relationships, versions, hashes, licensing information, generation context, and other required data survive the pipeline accurately.
Do not generate multiple formats merely to claim compatibility. Test ingestion into the systems that will actually use the SBOM: vulnerability management, asset inventory, supplier-risk workflows, product-security tooling, customer portals, or incident-response systems.
Practices and processes
The file is only one part of the minimum-elements model.
Coverage
State what the SBOM covers. A consumer needs to know whether dependencies, bundled libraries, operating-system packages, containers, generated assets, plugins, or other component classes are included or omitted.
Known unknowns
Do not hide incomplete knowledge. Record where component identity, dependency information, supplier data, or other required context is unavailable so consumers can make risk decisions with the gap visible.
Distribution and delivery
Define how authorized consumers obtain the SBOM, how access is controlled, how historical versions are retained, and how downstream users learn that a new version exists.
Accommodation of updates
Build a path for correcting and updating SBOM data without losing traceability to the software release it describes. Component information and vulnerability context can change after release.
Consumer readiness
Assign a system and owner that can ingest, search, correlate, and act on SBOM data. Requiring an SBOM from suppliers without a consumer workflow creates procurement paperwork rather than supply-chain visibility.
Implementation pattern
Generate at release, bind to the artifact, retain, distribute, and exercise.
1. Define product identity
Establish the product, release, artifact digest, repository revision, producer, and ownership model the SBOM will describe. The SBOM should be unambiguously associated with a release.
2. Generate from authoritative inputs
Prefer generation close to the build or release path where resolved dependencies, bundled packages, container contents, and the final artifact can be observed. Record the generation context.
3. Validate the eleven minimum fields
Fail, warn, or create an explicit exception when required values are absent. A syntactically valid SBOM can still be operationally incomplete.
4. Store with release evidence
Retain the SBOM with artifact digests, provenance/attestations, test evidence, approvals, and deployment records so later investigations can reconstruct what was released.
5. Deliver to the consumer
Use a predictable authenticated or public distribution path appropriate to the product. Define who can retrieve historical SBOMs and how corrections are published.
6. Test a vulnerability lookup
Select a real or simulated advisory and measure whether the organization can find affected products, versions, owners, suppliers, deployed environments, and required response actions.
Quality and validation
Test the SBOM against the software, not only against a schema.
Schema validation proves that the document is structurally acceptable. It does not prove completeness. Compare declared components against the built artifact, container/package inventory, dependency manifests, lockfiles, and other available evidence.
Track recurring gaps by ecosystem and build path: missing transitive dependencies, ambiguous package names, vendored code, dynamically downloaded components, base-image contents, generated binaries, embedded firmware, plugins, or SaaS-only dependencies may require different discovery methods.
CISA's 2025 discussion explicitly expands the operational conversation to SaaS/cloud environments and AI software systems. Those cases reinforce the need to define scope and generation context rather than assuming a traditional packaged binary model.
Supplier and procurement use
Ask for an SBOM only when your team knows how it will change a decision.
For suppliers, define the format or access method you can consume, the product/release granularity required, how quickly updated SBOMs must be available, whether historical versions remain accessible, and how missing or unknown components are handled.
Connect SBOM intake to supplier due diligence, vulnerability response, procurement, and incident management. The software supply-chain tooling guide covers the surrounding provenance, dependency, artifact-verification, and supplier-evidence model.
Primary sources
Current baseline and historical foundation
Continue learning
Related guides after CISA SBOM Minimum Elements 2025
Follow the next implementation topic without returning to search.
Software Supply Chain Tooling
Build verifiable software supply-chain controls
Continue readingCI Compliance
Integrate compliance evidence into CI workflows
Continue readingVulnerability Management Program
Prioritize and remediate vulnerabilities using asset, exploitation, exposure, ownership, exception, and verification evidence
Continue reading
Put this guide to work
Turn CISA SBOM Minimum Elements 2025: 11 Required Data Fields | Zeph Tech into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.