ENISA's SBOM advisory: the trust layer is now official guidance

TL;DR. ENISA’s new SBOM advisory says that generating an SBOM is not enough anymore. You need to sign it, tie it to the exact artifact it describes, check its quality and keep the evidence for every release, so you can answer an auditor or a CVE question about software you shipped a year ago.

Chainloop does all of that in your existing CI. Fortune 500 companies and regulated financial institutions have run it in production since we first wrote about SBOMs you can trust in 2023.

The advisory in short

On 22 October 2026 ENISA, the EU cybersecurity agency, published its Technical Advisory for Software Bill of Materials (PDF). It describes how to produce SBOMs that others can trust and act on. Generating an SBOM is the easy part.

ENISA wrote the advisory for smaller companies that are starting with SBOMs, with the CRA’s SBOM requirements in mind. It is guidance, not a legal interpretation of the CRA. Even so, when an auditor or a customer asks what a good SBOM process looks like, this is the document they will point to.

At the centre of the advisory is the SBOM lifecycle in Figure 1, where you generate the SBOM, validate it, sign it, store it, use it and keep it up to date.

1. Validate before you sign

A signed SBOM that misses half your dependencies is a well-protected list of the wrong things. That is why ENISA puts a validation step between generation and signing. It checks the format and the required fields, and catches SBOMs that are incomplete, inaccurate or out of date.

Most SBOM checks today test for the minimum fields of the 2021 NTIA list. Table 1 of the advisory lines up the newer CISA 2026 Minimum Elements with the fields required by the German BSI TR-03183-2, so that one SBOM can satisfy both.

ENISA also asks you to declare your “known unknowns”, the dependencies you could not identify, instead of leaving them out. The market is behind here. In ENISA’s adoption survey, 36% of respondents need SBOMs with all direct dependencies and declared known unknowns, and only 29% receive them.

2. Sign the SBOM and bind it to the artifact

ENISA checks the whole SBOM pipeline for threats with STRIDE, Microsoft’s threat model. Three of its six categories mean that someone fakes the SBOM, changes it or denies publishing it, and ENISA’s answer to them is nearly always a signature, an attestation or an audit log. CISA 2026 goes further and adds the SBOM author’s signature as a minimum element, so integrity is now part of the SBOM itself.

A second risk is an SBOM that is not tied to the exact artifact it describes. ENISA’s fix is to bind the SBOM to the artifact by digest, and to record provenance that links the source, the build, the SBOM and the artifact.

3. Keep evidence for every release

ENISA lists insufficient retention as a risk of its own. If you drop old SBOMs and their signatures, you cannot tell whether a version you shipped last year contains the component in this morning’s CVE. The advisory asks you to keep generation logs, validation results, signatures and timestamps for every release, so you can answer an auditor or an incident responder later.

Most teams stop short of that. In the survey, 41% of organisations aim to fully automate SBOM generation for every build, but only 26% expect to automate SBOM updates across the product’s support period.

Implementing the advisory with Chainloop

ENISA’s advisory agrees with our 2023 post on trust, and adds quality. It turns the lifecycle into a reference CI/CD pipeline that generates, validates, signs and stores the SBOM, and stops if any step fails.

The dashed CI/CD box in the middle of ENISA’s diagram is what Chainloop runs. Chainloop is an opinionated control plane that programmatically gathers, validates, signs and stores SBOMs and any other evidence from your CI/CD system.

It builds on the same open standards as the tools ENISA recommends, CycloneDX, SPDX, Sigstore and in-toto, so it works with the generators and scanners you already use.

Here is how Chainloop covers each phase.

Generation

An SBOM produced outside the build can describe a different version than the one you ship. Chainloop generates the SBOM, or collects the one your existing generator produces, as part of the CI run.

Validation

An incomplete or wrong SBOM should fail the build before anyone signs it. Policies do the validation, and a violation can stop the pipeline, like the “NO” branches in the diagram. Two sets of policies cover most of what ENISA lists under validation:

• sbom-quality checks that the SBOM is present, has licences, is recent, and contains no banned licences or components. It includes sbom-ntia, which checks the NTIA minimum elements.
• Eight sbom-bsi-* policies check the BSI TR-03183-2 fields on CycloneDX SBOMs, such as the component fields, the creator, the dependencies and the SBOM-URI.

Cryptographic signing and storage

After the build, someone can still fake, change or lose the SBOM. Chainloop puts every SBOM into a signed in-toto attestation, together with the details of the CI run that produced it, and stores the SBOM in content-addressable storage (CAS). These are the two building blocks of the trust layer from our 2023 post. Chainloop relies on CAS, which identifies every SBOM by its content, not by a name or a path that someone can overwrite.

ENISA threat	Chainloop
Spoofed SBOM author	Every attestation is signed, and keyless signing ties the signature to the CI identity
Spoofed CI/CD pipeline	The attestation records the CI run, and per-project authorization limits which pipelines can produce evidence for a project
Tampered SBOM	CAS stores every SBOM under its SHA-256 digest, so a changed SBOM gets a new digest and cannot replace the original
Producer denies publishing an SBOM	The signed, timestamped attestation records which pipeline published which SBOM and when
SBOM repository not available	CAS stores SBOMs across backends such as OCI registries, Amazon S3 and Azure Blob Storage

For the binding, the SBOM and the container image it describes go into the same signed attestation, each referenced by its digest. The containers-with-sbom policy checks that every image has an SBOM. Policy results go into the attestation too, so the validation results become part of the evidence. Every SBOM is also attached to a project version, and a product version collects the SBOMs of all its projects, so you can find every SBOM of a product release in one place.

Maintenance and update

An SBOM goes out of date while the software it describes is still in use. When the attestation runs in your CI on every build, each release gets its own SBOM and its own evidence with no manual step. Between releases, Chainloop can regenerate SBOMs on a schedule, and the sbom-freshness policy flags any SBOM older than the limit you set. CAS keeps every SBOM version, so when a new CVE comes in you can still check the SBOM of a release you shipped a year ago.

What we are working on

The advisory is a big step in the right direction for SBOMs, and it also shows gaps in our platform that we are actively working on.

• A signature inside the SBOM. We are adding a signature to the SBOM document itself, next to the signed attestation, to fill CISA’s SBOM author signature field.
• Better SPDX support for BSI. The sbom-bsi-* policies read CycloneDX today, and we are extending them to SPDX, including the check for declared known unknowns.
• Retention policies. CAS keeps every version, and we want to let you set a retention policy and a disposal procedure per project.
• SBOM sharing. We want to improve how you share SBOMs with customers and partners, with access control over who sees which SBOM.

If you are running into these challenges, or need guidance on meeting ENISA’s recommendations or the SBOM requirements of the Cyber Resilience Act, contact us. We are happy to help.