Supply chain security spent several years as a procurement questionnaire. It is now a set of files your build has to emit, in named formats, with cryptographic material attached — and the specification for what those files must contain changed last month.
In July 2026, CISA, NSA, FBI, and international partners published the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the minimum elements NTIA published in 2021. It incorporates feedback from a 2025 public comment period, and it applies to SBOMs for all software — including open source, AI software, and SaaS.
For engineering teams, the practical question is narrow: what does the pipeline have to produce, and what does producing it cost?
What changed in the SBOM baseline
The 2021 NTIA elements were a short list: supplier, component name, version, other unique identifiers, dependency relationship, author, and timestamp. Component hash was recommended, not required — which created a long-running mismatch, since some sector regulators treated it as mandatory anyway.
The 2026 revision closes that gap and adds fields aimed squarely at automated consumption. The new required fields reported at publication include Component Hash Algorithm, Component License, SBOM Tool Name, and SBOM Generation Context. Reporting on the release describes the required field count expanding from seven to seventeen.
The logic behind the additions is worth understanding, because it tells you what the document is for. A hash lets a consumer verify that the component described is the component shipped. A tool name and generation context let a consumer judge how much to trust the SBOM’s completeness — an SBOM produced by scanning a built container tells you something different from one produced from a lockfile at build time, and until now nothing in the format distinguished them. Licenses let legal review run without a second inventory pass.
None of that is aimed at a human reading the file. The 2026 baseline assumes SBOMs are machine inputs at a volume no one reviews by hand.
Generation: where in the pipeline matters more than which tool
Both major formats — SPDX and CycloneDX — satisfy the elements. The consequential decision is when you generate.
From the lockfile, pre-build. Fast, accurate about declared direct and transitive dependencies, blind to anything the build adds — base image contents, system packages, vendored code, binaries pulled by a post-install script.
From the built artifact, post-build. Sees what actually shipped, including base image layers. Weaker on provenance for anything statically linked or bundled, and noisier.
Teams that need a defensible SBOM generally end up doing both and merging, because the union is what a consumer actually wants: declared dependencies with resolved versions, plus what the image contains. The new SBOM Generation Context field exists precisely because these two artifacts are not interchangeable and consumers were previously unable to tell which one they had received.
Generate on every build, tie it to the artifact digest, and store it as a build output. An SBOM generated on a schedule, disconnected from a specific artifact, describes nothing verifiable.
Signing: keyless is the default worth adopting
The signing question used to involve key management, which is why most teams skipped it. Sigstore removed that objection.
The keyless flow in a CI environment works like this: the pipeline requests a short-lived OIDC token identifying the workflow, exchanges it with Fulcio for a short-lived signing certificate bound to that identity, signs the artifact, and records the event in the Rekor transparency log. No long-lived private key is created, stored, or rotated. In GitHub Actions this requires the id-token: write permission on the job.
What you get is a signature that says “this artifact was produced by this workflow, in this repository, at this commit” — verifiable by anyone, without your organization running a PKI. That identity binding is stronger than a key-based signature in the common case, because a leaked key proves nothing about where the artifact came from.
Sign the SBOM as well as the artifact. An unsigned inventory attached to a signed binary is a claim anyone can substitute.
SLSA levels are about the builder, not the code
SLSA is frequently misread as a code-quality standard. It is a provenance standard: it describes how much you can trust the claim that a given artifact came from a given source through a given build process.
The levels that matter for most teams:
- Build Level 1 — provenance exists and is available. Automated build, provenance document generated.
- Build Level 2 — provenance is signed and generated by a hosted build service. The service, not the build script, attests.
- Build Level 3 — the build runs in an isolated environment where the build definition cannot tamper with the provenance. In practice this means non-falsifiable provenance from a trusted builder.
The gap between Level 2 and Level 3 is the interesting one, because it is where most teams’ pipelines actually fail. If your build job can write to the same context that generates its own provenance, a compromised build step can forge its own attestation. Reaching Level 3 typically means moving builds into reusable, centrally-defined workflows that the calling repository cannot modify.
GitHub’s built-in attestation support, along with cosign and the SLSA GitHub generator, gets most artifact types to Level 2 quickly. Level 3 is an org-level change to how builds are defined, and it should be scoped as one.
What to put in the pipeline this quarter
A realistic order of operations, each step useful on its own:
- Generate an SBOM per build, tied to the artifact digest, in SPDX or CycloneDX. Include component hashes and licenses — both are now required fields, and both are usually already available to the generator.
- Sign artifacts keylessly with Sigstore. This is a permissions change and a pipeline step, not a project.
- Sign the SBOM too, and publish both alongside the artifact rather than in a separate system.
- Emit SLSA provenance at Build Level 2 using your CI provider’s attestation support.
- Verify on consumption. Every step above produces evidence nobody checks unless deployment gates on it. A policy that rejects unsigned or unattested artifacts at deploy time is what converts the files from compliance artifacts into a control.
- Then consider Level 3, which requires restructuring who can define a build.
Step 5 is the one teams skip, and skipping it is what makes supply chain work feel like paperwork. Generating provenance nobody verifies is a slower way to ship the same artifact. Verification is where the security actually lives — everything before it is just making verification possible.