SBOM: what it contains and how to generate, sign and use it

What must an SBOM contain?

The baseline is CISA's 2026 Minimum Elements for a Software Bill of Materials, version 2.1, dated 29 July 2026. It "updates and replaces" the 2021 NTIA minimum elements, whose data fields were supplier name, component name, component version, other unique identifiers, dependency relationship, author of SBOM data and timestamp. CISA says its elements "do not create new requirements; they refine how organizations should generate and request SBOMs".

For vulnerability checks, CISA gives coverage an explicit test: the 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." By that test, an SBOM that stops at the top-level dependencies cannot clear a product, because the affected component may sit deeper.

Generation context is a new element. Component data "may differ based on the phase of the software lifecycle during which the SBOM was generated", so the SBOM now says which phase it came from. CISA's examples: "before build" for an SBOM generated from source code, "after build" for binary analysis tools.

Which laws and customers require an SBOM?

Each row follows the wording of its primary text.

Four details matter. The CRA names no format beyond "a commonly used and machine-readable format", and Article 13(24) says the Commission "may" specify the format and elements by implementing act. Annex VII has the SBOM, "where applicable", go to a market surveillance authority "further to a reasoned request", and Annex II lets the manufacturer decide whether users get it. The CRA's floor, the top-level dependencies, is lower than CISA's coverage. And FDA's guidance, issued before CISA's update, recommends machine-readable SBOMs "consistent with the minimum elements" that NTIA identified in October 2021.

For a contract, CISA advises that an organization "should explicitly address these elements in any policy, contract, or arrangement to ask for or provide SBOMs". Specify the format and version (CISA says to avoid accepting SBOMs for new software in deprecated versions of any format), how often SBOMs arrive, how they are delivered and how unknown fields are marked.

Which format should you use: SPDX or CycloneDX?

CISA names two data formats "widely used by software ecosystem stakeholders to generate and consume SBOMs": SPDX and CycloneDX. It advises organizations to "accept any widely used, interoperable, and machine-processable SBOM format", so let your customer and your toolchain decide. SPDX describes its specification as an international open standard, ISO/IEC 5962:2021, and lists 3.0 as the current document version. CycloneDX lists 1.7 (released 21 October 2025) as current, and the Ecma International standard ECMA-424 as published on 10 December 2025.

CISA's Component Identifiers element asks for "at least one software identifier" that serves as a look-up key for databases, and points to two: CPE, "a structured naming scheme for information technology systems, software, and packages", and the Package URL (purl), a URL of seven components, scheme:type/namespace/name@version?qualifiers#subpath. Ecma International standardized purl as ECMA-427 in December 2025.

Here is a minimal CycloneDX 1.7 document for a container image with two components. All values are illustrative and sbom-tool is a made-up tool name. The file has been checked against the CycloneDX 1.7 JSON schema.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:4f4e7a60-b501-413b-a9a6-48f463ac575c",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-09T15:04:05Z",
    "lifecycles": [{ "phase": "post-build" }],
    "tools": {
      "components": [
        { "type": "application", "name": "sbom-tool", "version": "1.0.0" }
      ]
    },
    "manufacturer": { "name": "Example Corp" },
    "component": {
      "type": "container",
      "bom-ref": "shop-api",
      "name": "shop-api",
      "version": "2.4.0",
      "purl": "pkg:oci/shop-api@sha256:fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/acme-parser@2.1.0",
      "name": "acme-parser",
      "version": "2.1.0",
      "purl": "pkg:npm/acme-parser@2.1.0",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "pkg:deb/debian/libacme1@1.4.2-1?arch=amd64&distro=debian-12",
      "name": "libacme1",
      "version": "1.4.2-1",
      "purl": "pkg:deb/debian/libacme1@1.4.2-1?arch=amd64&distro=debian-12"
    }
  ],
  "dependencies": [
    {
      "ref": "shop-api",
      "dependsOn": [
        "pkg:npm/acme-parser@2.1.0",
        "pkg:deb/debian/libacme1@1.4.2-1?arch=amd64&distro=debian-12"
      ]
    },
    { "ref": "pkg:npm/acme-parser@2.1.0", "dependsOn": [] }
  ]
}

In CycloneDX, purl carries the identifier, dependencies carries the relationships and lifecycles carries the generation context. The value post-build is the phase for a BOM made after a build process has completed.

How do you generate an SBOM?

Where you generate the SBOM decides what it can see, which is why CISA added generation context. These commands come from each tool's documentation.

If customers ask for different formats, Syft can write several in one run: syft IMAGE -o spdx-json=./spdx.json -o cyclonedx-json=./cdx.json.

Scanning an image and scanning a source tree give different answers. Syft's cataloger documentation says an image scan finds installed packages, while a directory scan finds both installed packages and declared dependencies. Declared dependencies are weaker evidence: a requirements.txt "might specify a package without a version, or with a version range", which most of the time cannot give the exact version that would be installed. After the build tooling has run, an image scan "can provide more accurate version information". What it can miss is the build itself: BuildKit's SBOM leaves out "build-time dependencies installed in earlier stages, or that exist in the build context" unless you set the build arguments BUILDKIT_SBOM_SCAN_STAGE and BUILDKIT_SBOM_SCAN_CONTEXT.

Copied code needs deliberate handling: CISA's footnote says it "is effectively a dependency that is better tracked as a fork and a dependency relationship". A workable default: generate from the built image in every CI run and record it as "after build", then add a source-level SBOM ("before build") when a customer wants what the project declares as well as what shipped.

How do you sign an SBOM and check the signature?

CISA says a recipient "may be concerned about verifying the source of the SBOM data and confirming its integrity". It added an SBOM Author Signature element for that, and says to use "existing software signing infrastructure, tools, and key management".

For container images, one way to do this is an attestation. An in-toto attestation is "authenticated metadata about one or more software artifacts". Its predicate holds the metadata, here the SBOM, and its statement binds the attestation to a subject, here the image digest, which identifies the exact image being attested. An envelope handles authentication and serialization: cosign signs with the "DSSE signing spec", as the Sigstore documentation puts it. The commands follow the attest and verify-attestation references for cosign v3.1.3:

cosign attest --yes --type cyclonedx --predicate sbom.cdx.json \
  ghcr.io/example-corp/shop-api@sha256:<digest>

cosign verify-attestation --type cyclonedx \
  --certificate-identity <signer identity> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/example-corp/shop-api@sha256:<digest>

For keyless flows, verify-attestation must be told which identity and which OIDC issuer to expect; the issuer above is the one GitHub Actions OIDC tokens carry. The Sigstore documentation warns that "Signatures can guarantee a file has not been tampered with, but they can't guarantee the file arrives at all", and that systems should "fail closed rather than open". Design the deploy gate so that a missing attestation blocks a release as surely as a wrong one. How a cluster enforces image signatures differs by platform; our OpenShift vs Kubernetes comparison has a row on it.

On GitHub, actions/attest does the same job inside a workflow. Passing sbom-path makes it create an SBOM attestation from an SPDX or CycloneDX JSON file of up to 16 MB, signed with a short-lived Sigstore certificate. It recognizes a CycloneDX file only if bomFormat, serialNumber and specVersion are all present, and gives it the predicate type https://cyclonedx.org/bom. Artifact attestations are available in public repositories on all current GitHub plans; private or internal repositories need GitHub Enterprise Cloud, and GitHub Enterprise Server is not supported.

Check it with gh attestation verify. By default the command enforces the https://slsa.dev/provenance/v1 predicate type, so an SBOM check names its own type with --predicate-type. The manual says that ideally the path of the signer workflow is validated too, with --signer-workflow:

gh attestation verify oci://ghcr.io/example-corp/shop-api@sha256:<digest> \
  --owner example-corp \
  --signer-workflow example-corp/shop-api/.github/workflows/release.yml \
  --predicate-type https://cyclonedx.org/bom

SLSA, Supply-chain Levels for Software Artifacts, is "a security framework, a checklist of standards and controls to prevent tampering", and it answers a different question from an SBOM. Version 1.2, announced on 24 November 2025, introduced the Source Track alongside the Build Track. Build levels run from L1, where provenance exists but "is trivial to bypass or forge", to L3, where builds run on "a hardened build platform that offers strong tamper protection". The SLSA FAQ says SBOMs and provenance "operate at different levels of abstraction": an SBOM describes the components in an artifact, provenance describes the build, and provenance "can increase the trustworthiness of an SBOM by describing how the SBOM was created".

How do you generate and sign an SBOM in GitHub Actions?

This workflow builds an image, generates a CycloneDX SBOM from the pushed image by digest, and attaches it as a signed attestation. It is adapted from each action's documentation and has not been run end to end for this article, so try it on a test repository first. Each action is pinned to the commit SHA of its latest release as resolved on 9 October 2026.

name: release
on:
  push:
    tags: ["v*"]
jobs:
  image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
      attestations: write
      artifact-metadata: write
    env:
      IMAGE: ghcr.io/example-corp/shop-api
    steps:
      - uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/setup-buildx-action@f87e5991a6d7451dcb8d9637bfbc97413f497069 # v4.4.1
      - id: push
        uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc # v7.4.0
        with:
          push: true
          tags: ${{ env.IMAGE }}:${{ github.ref_name }}
      - uses: anchore/sbom-action@66cbf4bc1f1c0d2edc94016e65bc221b6bb0ad6c # v0.24.3
        with:
          image: ${{ env.IMAGE }}@${{ steps.push.outputs.digest }}
          format: cyclonedx-json
          output-file: sbom.cdx.json
      - uses: actions/attest@1e69f48acb82d1966a394da916b4c1698aa569d6 # v4.2.2
        with:
          subject-name: ${{ env.IMAGE }}
          subject-digest: ${{ steps.push.outputs.digest }}
          sbom-path: sbom.cdx.json
          push-to-registry: true

GitHub's secure use reference says pinning to a full-length commit SHA "is currently the only way to use an action as an immutable release". build-push-action uses the Git context by default, so no checkout step is needed, and its digest output feeds the later steps. The sbom-action fetches the image with the Docker daemon if it is available, "which will use any authentication available to the daemon", so the earlier login applies. With push-to-registry, actions/attest needs subject-name to be the fully qualified image name: "Do NOT include a tag as part of the image name", because the digest identifies the image.

Docker's attestation example sets up Buildx before the build, so this workflow does too. The same page says build-push-action adds a provenance attestation by default, with mode=max in public repositories, and that it then contains the values of build arguments. Pass secrets with secret mounts instead of build arguments.

How do you use an SBOM to find vulnerable components?

A stored SBOM turns a new advisory into a lookup. CISA says that after learning new vulnerability information, "an organization can assess whether its SBOMs contain or reference a vulnerable component, significantly improving response time compared to organizations without SBOMs." These tools do the matching from a file:

Dependency-Track runs this matching as a service: its version 5 documentation says it is "built around the Bill of Materials (BOM) concept" and surfaces known vulnerabilities "as they emerge". A finding there is "the association between a component in one of your projects and a vulnerability that affects it".

Matching has to be repeated, because the SBOM stays the same while vulnerability data changes. Re-run it on a schedule against every stored SBOM, and in CI on each pull request. Our secure coding checklist covers keeping dependencies under control.

A match is not yet a priority. Our guide to predicting which vulnerabilities to patch first covers the signals for ranking them, and our guide to penetration testing vs vulnerability scanning explains what a scanner can and cannot find. Outdated components also count as debt, and our technical debt guide shows how to measure dependency age and end-of-life dates.

What is VEX, and how does it cut false alerts?

A match is not proof of exposure: the vulnerable code may not be present in your product, or may never execute. VEX, the Vulnerability Exploitability eXchange, lets the producer say so in a machine-readable way. Several formats carry it. OpenVEX is "designed to be lightweight, and embeddable". CSAF is an OASIS standard whose VEX profile exists "to state that and why a certain product is, or is not, affected by a vulnerability". CycloneDX VEX conveys "the exploitability of vulnerable components in the context of the product in which they're used".

An OpenVEX statement has one of four statuses: not_affected, affected, fixed or under_investigation. A not_affected statement needs one of five fixed justification labels or a free-text impact statement, which the specification calls "highly discouraged for automated systems". This document says the libacme1 package in the example image does not contain the vulnerable code. CVE-2023-12345 is the identifier the OpenVEX specification uses in its own samples:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://vex.example.com/shop-api/2.4.0/1",
  "author": "Example Corp Product Security",
  "timestamp": "2026-10-09T16:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-12345" },
      "products": [
        {
          "@id": "pkg:oci/shop-api@sha256:fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210",
          "subcomponents": [
            {
              "@id": "pkg:deb/debian/libacme1@1.4.2-1?arch=amd64&distro=debian-12"
            }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

Feed it to Grype with grype IMAGE@sha256:<digest> --vex vex.json. Grype accepts OpenVEX and CSAF VEX documents and, by default, moves not_affected and fixed results to its ignored list; --show-suppressed brings them back, marked "(suppressed by VEX)". Its documentation matches a VEX product by image digest (the most reliable form), by tag (less reliable, because tags can move) or by package purl, as the subcomponents entry above does. Dependency-Track "both produces and consumes VEX documents in CycloneDX format", and cosign can attest a VEX document with --type openvex.

What goes wrong with SBOMs in practice?

What should you do first?

1. Ask each customer or regulator for the format, version and elements they need, and write CISA's 2026 elements into your policy.
2. Generate an SBOM from each image in CI on every release, and record the generation context.
3. Sign it as an attestation on the image digest, and make one pipeline step verify it with the signer identity you expect.
4. Store the SBOMs where security can query them, and re-match them against vulnerability data on a schedule.
5. Publish VEX statements for matches that do not apply.

For help setting this up, Computese's security testing service lists Syft and Grype among its code and supply-chain tools, and its cloud transformation work covers signed images and SBOMs.