← All posts
· 5 min read ·
SecurityCI/CDSBOMComplianceDevSecOps

CISA's 2025 SBOM Minimum Elements Raised the Bar: Are Your SBOMs Compliant?

The 2021 NTIA minimum elements defined the floor. CISA's 2025 revision adds Component Hash, License, Tool Name, and Generation Context as required fields. Here is what changed, what tooling meets the new bar, and how to integrate compliant SBOMs into your pipeline.

Documents and compliance paperwork on a desk

A Software Bill of Materials is only useful if it contains enough information to act on. The 2021 NTIA minimum elements were a starting point - they established that SBOMs should exist and defined seven basic fields. The CISA 2025 revision, published for public comment in August 2025, adds four required fields that close significant gaps in the original specification.

If your organisation supplies software to US federal agencies, or if you have been building SBOM generation into your CI pipelines based on the 2021 spec, the 2025 requirements change what “compliant” means.

What the 2021 NTIA Spec Required

The original seven minimum elements were:

  1. Supplier name
  2. Component name
  3. Version of the component
  4. Other unique identifiers (package URL, CPE)
  5. Dependency relationship
  6. Author of the SBOM data
  7. Timestamp

These are sufficient to identify what components exist in software. They are not sufficient to verify that the component has not been tampered with, understand its licence obligations, know what tool generated the SBOM (and therefore how much to trust the completeness of the data), or understand whether the SBOM was generated from source or from a built artifact.

The Four New Required Fields

Component Hash - A cryptographic hash of each component, enabling verification that the declared component is exactly what is present in the artifact. Without a hash, a component entry is a claim, not a verifiable fact. SHA-256 is the expected algorithm; SPDX 3.0 and CycloneDX 1.6 both support it natively.

License - The SPDX licence expression for each component. This was optional in 2021, which created a gap between “we have an SBOM” and “we know our licence obligations.” The 2025 revision makes it required. For components under multiple licences, the expression should reflect the applicable licence for the distribution context (e.g., Apache-2.0 OR MIT).

Tool Name and Version - The software that generated the SBOM. This matters because different tools have different levels of completeness and accuracy. An SBOM generated by Syft from a container image has different coverage characteristics than one generated by cdxgen from source. An auditor needs to know which tool was used to assess the reliability of the component list.

Generation Context - Whether the SBOM was generated from source, from a built binary, from a container image, or from a deployed artifact. This is the most semantically significant addition. An SBOM generated from source describes what the developer intended to include. An SBOM generated from a container image describes what is actually present in the deployed artifact. These can differ if build scripts add or remove components, if base image layers introduce dependencies, or if the build process was tampered with.

What Tooling Meets the 2025 Bar

Not all SBOM generators produce all four new fields correctly.

Syft (Anchore) generates SPDX 3.0 and CycloneDX 1.6 documents with component hashes, licence data (sourced from package manifests and licence files), and tool metadata. Generation context requires configuration - by default it notes the source type (image, directory, binary) but does not produce a structured generation-context field as specified in the 2025 draft. Expect an update before the requirement is finalised.

syft myapp:latest -o spdx-json > sbom.spdx.json
syft myapp:latest -o cyclonedx-json > sbom.cyclonedx.json

cdxgen produces CycloneDX 1.6 documents with strong licence data (particularly for Java, Node, and Python ecosystems) and includes tool metadata in the metadata.tools section. Component hashes are included for most package types. The generation-context field maps to CycloneDX’s metadata.component.type which distinguishes between library, application, container, and operating-system sources.

Trivy (--format cyclonedx) includes vulnerability data alongside component metadata, which is useful but outside the SBOM specification scope. The CycloneDX output includes hashes and tool metadata. Licence data quality depends on the ecosystem - it is strong for container image layers and npm, weaker for compiled Go binaries where licence files are not always embedded.

For a pipeline that needs to meet the 2025 requirements today, Syft or cdxgen with CycloneDX 1.6 output is the most defensible choice.

Integrating into CI

Generating the SBOM at build time and attesting it alongside the artifact is the pattern that satisfies both the 2025 minimum elements and the traceability requirements:

- name: Build image
  run: docker build -t $IMAGE_TAG .

- name: Generate SBOM
  uses: anchore/sbom-action@f325610c9f50a54015d37c8d16cb3b0e2c8f4de5
  with:
    image: ${{ env.IMAGE_TAG }}
    artifact-name: sbom.cyclonedx.json
    output-file: sbom.cyclonedx.json
    format: cyclonedx-json

- name: Attest SBOM
  uses: actions/attest-sbom@bd218ee8dde1af2bf0b526795b1d43e01d02da2e
  with:
    subject-image-ref: ${{ env.IMAGE_TAG }}
    sbom-path: sbom.cyclonedx.json

The attestation step links the SBOM document to the artifact via a Sigstore-signed record in the Rekor transparency log. This addresses the “who generated this SBOM and when” question that the Generation Context requirement implies - the Sigstore record provides a cryptographically verifiable timestamp and signer identity.

The Policy Context

OMB Memorandum M-26-05 (January 2026) rescinded the mandatory attestation memos M-22-18 and M-23-16, shifting to an agency-led risk-based approach. This does not mean SBOMs are no longer required - EO 14028 (May 2021) remains in effect and continues to mandate SBOMs for software sold to federal agencies. What changed is the specific attestation form and the centralised enforcement mechanism; individual agency procurement requirements now carry the obligation.

For commercial software vendors selling to the federal market, the practical implication is that compliance now requires understanding each agency’s specific SBOM requirements rather than relying on a single federal standard. In practice, the 2025 CISA minimum elements are the baseline that agencies are converging on, making compliance with that specification the safest default position.

The Gap Between “Has an SBOM” and “Has a Useful SBOM”

The motivation behind the 2025 additions is that 2021-era SBOMs were frequently incomplete in ways that made them difficult to act on during a security incident. When a critical CVE is announced for a component you may or may not have included, you need to answer three questions:

  1. Is this component in my software? (component name and version - 2021)
  2. Is this the same binary as the reported vulnerable version? (component hash - 2025)
  3. Was this component present in what we actually shipped or just what the developer declared? (generation context - 2025)

Without component hashes and generation context, the answer to questions 2 and 3 is always “we believe so.” The 2025 requirements move the answer to “we can verify.”

That shift from belief to verification is the point of the update.

← All posts