SBOMs and Supply-Chain Attestations Explained

Software bills of materials (SBOMs) and supply-chain attestations help developers, platform teams, and security responders answer two different questions: what components are in a release, and how was that release produced? As software is assembled from external packages and automated builds, these records make dependencies and artifact provenance easier to inspect. They are evidence for investigation and policy, not certificates that software is safe.

Why SBOMs and Supply-Chain Attestations Are Being Discussed

Modern releases can combine thousands of direct and transitive dependencies, generated files, build tools, and deployment steps. A vulnerability disclosure or supplier incident can leave operators asking which shipped products are affected, while a suspicious artifact can raise the question of whether it came from the expected source and build process. Those answers are difficult to establish from a package name or release tag alone.

An SBOM gives teams a structured inventory to search when a component changes or a vulnerability is disclosed. An attestation records a claim about an artifact, such as the source revision or build workflow that produced it. Together, they support inventory, incident response, and release verification. The CISA SBOM resource describes SBOM practices and minimum elements; GitHub’s artifact attestation documentation shows how build and SBOM claims can be attached to software and verified by consumers.

What Are SBOMs and Supply-Chain Attestations?

An SBOM is a machine-readable record of software components associated with a product or artifact. Depending on how it is produced, it can identify component names and versions, suppliers, package identifiers, dependency relationships, and the creator of the inventory. A useful SBOM describes a particular release or build, rather than an abstract application that may change between releases.

An SBOM is not the same thing as a package lockfile. A lockfile tells a package manager which dependency versions to resolve for an install or build. An SBOM communicates component inventory to other tools and people, and may describe a built artifact after packaging. The two can complement each other, but they can differ in scope and detail.

An attestation is a structured statement about a subject, commonly an artifact identified by its cryptographic digest. Its predicate contains a claim, for example build provenance or an SBOM. A signing identity and signature let a verifier check who made the statement and whether it has changed. Formats such as the in-toto Statement define how a subject and predicate are represented. A verifier must still decide whether the signer and claim are trusted.

Provenance is one kind of attestation: it records information about how an artifact was built, such as the source revision and builder. The SLSA specification defines a model for describing and assessing software supply-chain security, including build provenance. Provenance can make a build traceable, but cannot establish that the reviewed source is free of vulnerabilities or malicious behavior.

The Problem These Records Solve

Without an SBOM, a team may have to reconstruct each released product’s dependencies from source repositories, build logs, package registries, and individual developers’ knowledge. That process is slow and prone to gaps, particularly when a component is pulled in transitively or embedded in a container image. During an incident, an incomplete inventory can delay containment or lead teams to miss affected versions.

Without provenance, a consumer may know an artifact’s name and download location but not which source or workflow produced its bytes. A compromised build runner, release credential, or registry can publish an artifact that appears to be a normal update. A signature alone says that a particular identity signed particular content; it does not explain the build inputs or prove the signer was uncompromised.

These records make separate gaps more visible. Inventory supports the question “What components are present?” Provenance supports “Where did this artifact come from, and how was it built?” Combining both with access controls, vulnerability analysis, and a recovery plan improves response without implying that evidence alone prevents attacks. For broader attack paths and controls, see software supply-chain attacks and defenses.

How SBOMs and Attestations Work

An SBOM producer inspects a source tree, package graph, container image, or other build output and serializes the discovered components in a standard format. The resulting inventory is useful only for the scope it actually scanned. A source-directory SBOM may omit build-time downloads or generated files; an image SBOM may include operating-system packages that are not visible in an application’s lockfile.

An attestation producer creates a statement whose subject identifies an artifact, typically by digest, and whose predicate describes a claim. The statement can be signed and stored beside the artifact or in an attestation service. A verifier checks the artifact identity, signature, signer or workload identity, and any required predicate fields. A deployment policy might accept only artifacts produced by a protected release workflow from a particular repository.

The SPDX project and Ecma’s CycloneDX specification define format details. Format choice should follow the data consumers need and the tooling they support; two standards do not guarantee equally complete inventories. An SBOM can also be distributed as a file or carried as an attestation attached to the release artifact.

Attestation verification adds a trust decision on top of parsing a statement. A result that says the signature is mathematically valid is not enough if the signing identity is unexpected, the subject digest does not match the release, or the predicate omits required fields. Similarly, a correctly signed SBOM can still be stale or incomplete. Automation should fail closed when a required check fails, while recording enough diagnostic information for maintainers to correct the policy or rebuild the artifact.

Key Formats and Concepts

• Component identity: Names and versions can be ambiguous across ecosystems. Package URLs and other identifiers help tools distinguish packages; teams should understand which identifiers their scanner and vulnerability sources use.
• Dependency relationship: An inventory may represent direct dependencies and relationships between components. Teams should verify whether the producer discovers transitive packages and what it can detect in the chosen artifact.
• Subject digest: A digest ties the attestation to particular artifact content. A mutable tag can point to different content, so consumers should verify the digest they actually deploy.
• Predicate: The claim inside an attestation, such as a provenance statement or SBOM. Predicate type and schema determine how a consumer interprets its fields.
• Signer identity: A certificate or key can associate a statement with a user or build workload. A useful policy constrains the expected identity and issuer rather than trusting any valid signature.
• Freshness and scope: An inventory should describe the release being assessed. Reusing an SBOM from a different commit, image layer, or build can create false confidence.

The Sigstore Cosign image-signing guide explains how signatures and attestations can be used with container images. Signatures, transparency records, and build provenance each contribute different evidence; none replaces component review or vulnerability response.

Real-World Uses

When a vulnerability is disclosed in a widely used library, an organization can search release SBOMs for matching package names and versions, then check which products and deployments contain them. Teams still need to validate identifiers and affected version ranges against authoritative advisories. The SBOM narrows the investigation; it does not determine whether a particular deployment is exploitable.

A software publisher can produce provenance for each release and give customers a way to verify it. A customer might require that artifacts come from a protected branch and an approved build workflow before deployment. If verification fails, the release can be quarantined while maintainers investigate a digest mismatch, identity change, or build-policy violation.

An organization consuming supplier software can retain SBOMs and attestations alongside the version and deployment records. This improves the ability to respond to supplier notices and compare releases. The customer may not be able to inspect or control the supplier’s build, so the evidence should be treated as an input to risk decisions, not as proof of independent assurance.

Getting Started: Generate and Verify an SBOM

For a project directory or container image supported by Syft, generate an SPDX JSON inventory and inspect its top-level data:

# Scan the directory whose components you want to inventory.
syft dir:./app -o spdx-json=sbom.spdx.json

# Confirm the document version and number of listed packages.
jq -r '"SPDX: \(.spdxVersion); packages: \(.packages | length)"' sbom.spdx.json

Run the scan against the release contents or image where possible, and record the artifact digest and scan scope with the output. Review whether the SBOM contains the expected package set before publishing it. A successful command only means the tool produced a document; it does not certify that every dependency was found.

GitHub Actions can create an artifact attestation for a built file and associate an SBOM with it. The workflow needs narrowly scoped permissions and an SBOM generated for the same artifact:

permissions:
  id-token: write
  contents: read
  attestations: write

steps:
  - name: Generate SBOM attestation
    uses: actions/attest@v4
    with:
      subject-path: dist/my-app.tar.gz
      sbom-path: sbom.spdx.json

Replace the paths with the actual build output and its matching SBOM. Protect the workflow that receives the identity token, and do not grant attestation permissions to untrusted pull-request jobs. For an SPDX SBOM attestation, a maintainer or consumer can use GitHub CLI to verify the subject and repository:

gh attestation verify dist/my-app.tar.gz \
  --repo OWNER/REPOSITORY \
  --predicate-type https://spdx.dev/Document/v2.3

Use the predicate type that matches the format and statement being verified; CycloneDX uses a different predicate type. Verification should also be followed by review of the reported signer and statement fields against the expected repository, workflow, source, and artifact. See GitHub’s artifact attestation guide for container-specific examples and output inspection.

Common problems include scanning the wrong directory, attaching an SBOM for one build to another artifact, omitting the required workflow permissions, and verifying against the wrong repository or predicate type. When a check fails, compare the artifact digest and attestation subject first, then inspect the signer identity and predicate. Do not weaken verification rules until the mismatch is understood.

Common Misconceptions

“An SBOM proves the software is secure.” It is an inventory, not a security verdict. It may help identify known vulnerable components, but it does not assess every vulnerability, detect all malicious behavior, or prove the inventory is complete.

“A signed attestation makes the claim true.” A signature ties a claim to a signer and protects its integrity. The signer can make an incorrect claim, and a compromised authorized workflow can produce misleading evidence. Consumers must evaluate identity, provenance, subject, and predicate content.

“One SBOM covers every version and deployment.” Component sets vary with build options, platform, dependency resolution, and packaging. Generate and retain inventories that correspond to shipped artifacts, and keep them associated with their exact versions or digests.

Related Articles

• Software Supply-Chain Attacks: Risks and Defenses
• Sigstore Cosign: Image Signing and Verification
• DevOps Pipeline Security
• Container Security Best Practices

Changelog

• First published.