Most teams I talk to can generate an SBOM. Far fewer can tell you whether it’s complete, who signed it, where last year’s version is stored, or what happens when a new CVE matches one of its components. In October 2026, ENISA published the Technical Advisory for Software Bill of Materials, and that second set of questions is what it’s about. This article summarizes the advisory and adds notes from our own SCA work.
What the advisory is, and what it isn’t
The advisory is the final version of a document that started as a draft called “SBOM Landscape Analysis: Towards an implementation guide”. ENISA put that draft out for feedback between 17 December 2025 and 23 January 2026 and received 67 contributions. It also drew on its SBOM Adoption State of Play 2026 survey, published in June 2026, and on a review by the SBOM workstrand of the CRA Expert Group between 31 July and 11 September 2026. The feedback convinced ENISA to turn the draft into a technical advisory, the same format as its advisory on the secure use of package managers.
A few things to know before you read it:
- It’s written for organizations that are just starting with SBOMs, especially SMEs and open-source stewards. It deliberately doesn’t offer a maturity model.
- It’s guidance. The recommendations are non-mandatory, ENISA says the document isn’t a legal interpretation of the CRA, and some practices go beyond what the CRA requires.
- It covers software only. AI, hardware and cryptographic bills of materials are out of scope.
- It’s licensed under CC BY 4.0 and follows the principles of ENISA’s Secure by Design and Default Playbook.
ENISA uses the CRA’s definition of an SBOM: “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”. Then it makes a point worth repeating to anyone who treats SBOMs as a compliance deliverable. SBOMs are “a foundational data layer rather than a complete security solution”. The value comes from what you do with them: patching, documented vulnerability decisions, license checks and procurement.
The gap between what buyers need and what they get
The advisory quotes the State of Play survey throughout, and the numbers explain why it spends more time on the lifecycle than on generation.
| SBOM depth | Organizations that need it | Organizations that receive it |
|---|---|---|
| All primary components and direct dependencies, with declared known unknowns | 36% | 29% |
| Full depth analysis | 24% | 14% |
| Depth analysis including declared known unknowns | 27% | 12% |
A “known unknown” is a component whose dependencies couldn’t be determined, declared as such in the SBOM instead of silently left out. Buyers want to know where the blind spots are.
Automation tells the same story. 41% of respondents aim to fully automate SBOM generation for every build or release, but only 26% expect to fully automate SBOM updates across the support period, and about 23% expect to automate them partially. Generating an SBOM is largely a solved problem. Keeping it accurate for as long as the product is supported is not.
What goes into an SBOM
ENISA doesn’t define its own field list. It maps the two baselines most organizations will run into: the German BSI’s TR-03183-2 (version 2.1.0) and CISA’s 2026 Minimum Elements for a Software Bill of Materials, published in summer 2026 as joint guidance with the NSA, the FBI and partner agencies in other countries.
The core is the same in both: who created the SBOM and when, and for each component its creator, name, version, identifiers, hash, license and dependencies. The differences are in the details.
| Only in BSI TR-03183-2 | Only in the CISA 2026 minimum elements |
|---|---|
| SBOM URI | SBOM version |
| Separate URIs for a component's source code and its deployable form | SBOM data format name and version |
| Hash of the component's source code (optional) | SBOM author signature |
| Distribution, original and effective licenses as separate fields | Name and version of the tool that generated the SBOM |
| Executable, archive and structured properties | Generation context: before, during or after the build |
| URL of the component creator's security.txt (optional) | Hash algorithm |
BSI also wants an email address for the SBOM creator and each component creator, or a URL when there’s no email address. CISA asks for a name.
If you deliver to customers in Germany and the US, generate the union of both lists. Tool name and version, format and timestamp come from any decent generator. The BSI-specific properties, the effective license and the signature are the ones that need extra steps in your pipeline.
Formats and types
73% of the organizations in the survey use CycloneDX or SPDX, and the advisory compares the current versions of both.
| SPDX 3.0.1 | CycloneDX 1.7 | |
|---|---|---|
| Standardization | SPDX 2.2.1 is ISO/IEC 5962:2021, SPDX 3.0 is an OMG standard, and SPDX 3 is in progress at ISO | Ratified as ECMA-424, maintained through Ecma TC54, and on the ISO/IEC JTC 1 fast track |
| Focus | Detailed component metadata for licensing, provenance and risk analysis across product lines | Security use cases: vulnerability tracking with native VEX, services and APIs, cryptographic integrity |
For CRA purposes either one works. Pick the format your customers and your tools read. OWASP Dependency-Track, for example, only ingests CycloneDX. If you need both, OpenSSF’s Protobom converts between them.
The format is half the story. When you generate the SBOM decides what’s in it. ENISA uses CISA’s six SBOM types:
| Type | Generated from | Typical use |
|---|---|---|
| Design | The intended design, including components that may not exist yet | Architecture decisions, license purchases, threat modeling |
| Source | The development environment, source files and declared dependencies | Dependency visibility, early vulnerability detection |
| Build | The build process: source files, resolved dependencies, built components and build-time data | Regulatory compliance, vulnerability assessment, transparency |
| Analyzed | Analysis of finished artifacts such as executables, packages, containers and VM images, usually with heuristics; sometimes called a third-party SBOM | License compliance, provenance verification, supply chain risk |
| Deployed | The software present on a system, combining SBOMs with analysis of the configuration | Asset inventory, patch management, configuration management |
| Runtime | Instrumenting the running system, including dynamically loaded libraries, plug-ins and injected agents | Threat detection, attack surface assessment, runtime monitoring |
CISA’s new generation context field exists so a consumer can tell which of these they’re looking at. For a minimum viable implementation, ENISA is clear: start with the build SBOM, because that’s when the dependencies are known most accurately.
The SBOM lifecycle
The advisory describes the SBOM as a lifecycle in seven phases, built around four principles: continuous, trustworthy, actionable and up to date.
- Build
- Generation
- Validation
- Signing
- Storage
- Consumption
- Maintenance and update
It then turns the lifecycle into a reference architecture for a CI/CD pipeline. Each phase is a gate. If it fails, the pipeline stops and raises an alert.
- Generation detects components and their direct and transitive dependencies, captures metadata such as versions, licenses and PURLs, builds the dependency graph, normalizes package names and version formats, and writes SPDX or CycloneDX.
- Validation checks the schema, the metadata, the consistency of identifiers and dependency references, optionally a profile such as the BSI required fields, and whether the SBOM matches the artifact. ENISA singles out the component identifiers as something you must validate.
- Signing canonicalizes the SBOM, calculates a SHA-256 digest, signs it, binds the signature to an identity through an X.509 certificate or Sigstore, and adds a timestamp.
- Storage puts the signed SBOM in an immutable, versioned, access-controlled repository with tamper evidence, backups and a retention policy.
- Consumption feeds vulnerability management, license compliance, vendor risk management, open-source governance, regulatory compliance and software asset management.
- Maintenance regenerates the SBOM whenever something changes: a new build or release, dependency updates, security patches, OS package updates, added or removed libraries, or a change in the build configuration.
The list of consumers in the lifecycle diagram includes market surveillance authorities, next to security, development and compliance teams, vendors and customers. Under the CRA an authority can ask for your SBOM, and you’ll want to hand over the one that matches the exact product version it’s asking about.
Tools for every phase
The advisory maps open-source tools to the lifecycle phases. One in three organizations in the survey relies on open-source tooling, and ENISA presents the list as indicative, not exhaustive.
| Phase | CycloneDX | SPDX |
|---|---|---|
| Generation | cyclonedx-maven-plugin, @cyclonedx/cyclonedx-npm, cyclonedx-gomod, CycloneDX .NET tool, cdxgen, Syft, SBOMit | spdx-gradle-plugin, spdx-maven-plugin, SPDX tools for Python, Java and Go, Yocto, Linux (make spdx), Zephyr (west spdx), kubernetes-sigs/bom, GitHub SBOM, Microsoft sbom-tool, Syft, Trivy, ORT, SBOMit |
| Schema validation | CycloneDX CLI | SPDX online validator and NTIA checker |
| Quality score | sbomqs, sbom-scorecard | |
| Signing | GitHub CLI attestations, Cosign with Sigstore keyless signing | |
| Storage | GitHub Actions workflow artifacts (actions/upload-artifact) | |
| Consumption | Grype, Trivy, OWASP Dependency-Check, OWASP Dependency-Track, GitHub Dependency Review, OWASP dep-scan, OSV-Scanner, CVE Binary Tool | Fossology, sbomify, sbom-cve-check, SPDX 3 visualizer, GitHub Dependency Review |
Two entries need a caveat. OWASP Dependency-Check scans project files and dependencies directly and isn’t built to ingest SBOMs. The OWASP tool that reads and monitors SBOMs is Dependency-Track, and our Dependency-Track deployment guide shows how to run it on your own infrastructure.
Workflow artifacts also expire after their retention period, which doesn’t fit the advisory’s own advice on immutable storage and retention. The CRA expects you to keep the technical documentation for at least ten years after the product is placed on the market, or for the support period if that’s longer. Store SBOMs in an artifact repository you control.
A threat model for the SBOM pipeline
The advisory includes a STRIDE threat model. It covers the whole SBOM ecosystem, not only the file: the generators, the validation and signing services, the repositories and the consuming pipelines.
| STRIDE | Example threats | Indicative mitigations |
|---|---|---|
| Spoofing | An impersonated SBOM author, a fake consumer requesting a restricted SBOM, a spoofed CI/CD pipeline or generation tool, stolen signing certificates, a compromised repository mirror | Digital signatures, supplier and consumer identity verification, build attestations, authenticated pipelines, key management, certificate revocation |
| Tampering | Components, versions or dependencies changed after generation; metadata changed before generation; altered hashes, provenance, PURLs or CPEs | Integrity and signature verification, signed attestations, verification of external references |
| Repudiation | A producer denies generating, publishing or distributing an SBOM | Signatures, timestamps, audit and repository logs, signed releases |
| Information disclosure | The SBOM reveals the technology stack, proprietary components, supplier relationships, the dependency graph, exact versions, or internal certificates and release processes | Controlled sharing, access control, audit logging |
| Denial of service | An unavailable repository, very large or deeply nested SBOMs that exhaust parsers, SBOM volume that fills storage and stalls pipelines | Redundancy and DDoS protection, size limits, parser hardening, a retention policy |
| Elevation of privilege | Privilege escalation in the build pipeline, the SBOM repository or the signing infrastructure | Access control, pipeline hardening, key management |
Two rows deserve more attention than they usually get. Information disclosure is the reason the CRA lets you keep the SBOM in your technical documentation instead of publishing it: a list of exact versions is a list of CVEs to try. Decide per customer what you share and on what terms. And the parser denial of service matters as soon as you accept SBOMs from suppliers. Treat them as untrusted input.
Use the table as a starting point, not as your threat model. Your pipeline has its own trust boundaries, and the questions that find them are the same as for any other system. The Secure by Design and Default Playbook offers a lightweight way to do that if your team hasn’t threat modeled its build system before.
Ten risks that make SBOMs less useful
Next to the threats, the advisory lists general risks that undermine the accuracy, integrity or use of SBOMs.
| Risk | What it looks like | Indicative mitigation |
|---|---|---|
| Non-standard format | A proprietary or custom format | Use SPDX or CycloneDX |
| Not machine-readable | A PDF or spreadsheet meant for people | A machine-readable format suited to automated processing |
| Incomplete SBOM | Components or dependencies are missing | Automatic generation at release, CI/CD integration, documented known unknowns and missing metadata |
| Outdated SBOM | The SBOM no longer matches the software | Regenerate on the maintenance triggers |
| Poor component identification | Components can't be matched across ecosystems | The upstream repository URL, or a PURL with namespace, exact version and hashes, or a consistently applied CPE with exact version and hashes |
| Insufficient accuracy | Heuristics add components that aren't there, miss ones that are, or report wrong versions | Pick the generation technique per ecosystem and artifact type, validate SBOMs against artifacts, check completeness and identifiers |
| Weak SBOM-to-artifact binding | It's unclear which build, image or package the SBOM describes | Bind the SBOM to the artifact with a hash or immutable digest and verify the association |
| Limited operationalization | SBOMs are generated but never used | Consume them for asset, vulnerability and license management |
| Insufficient retention | Old SBOMs, signatures and VEX documents are gone | A retention policy, SBOMs per release, version history, SBOM-to-artifact traceability, disposal procedures |
| No vulnerability prioritization | Every finding is treated as equally urgent | Combine SBOM data with VEX, asset criticality and exposure in a risk-based process |
Poor component identification is the one I run into most. For C and C++ it’s the default state: generators add a PURL at best, while the NVD records vulnerabilities in libraries like OpenSSL and zlib against CPEs. ENISA’s mitigation, a consistently applied CPE with the exact version, is the approach in our article on CPE enrichment for C++ libraries in Conan builds.
Retention is the one teams discover too late. When a CVE comes out for a library, the question isn’t only whether today’s build is affected, but which shipped versions are. You can only answer that with the SBOMs of those versions. For prioritization, the mitigation stage in our package managers article shows how EPSS, the KEV catalog, VEX and reachability fit together.
Where to start: build-time integration
ENISA’s advice for a minimum viable implementation is to start at build time and use the CI infrastructure you already have. It breaks this down into six steps:
- Identify integration points in the current pipeline, such as post-compilation, pre-packaging and release preparation.
- Configure generation: format, level of detail, component scope, dependency traversal depth, and environment variables for consistent runs.
- Add a dedicated pipeline stage that runs after the build tasks it depends on, with failure handling that keeps incomplete SBOM generation from blocking critical paths.
- Define triggers, for example merges to main, tagged releases and scheduled baseline runs, and skip documentation-only changes.
- Store SBOMs close to the build artifacts, with versioning aligned to your software versions and retention matching the artifact lifecycle.
- Validate the format, check that required fields are filled, and verify signatures where you use attestations.
Step 3 sits awkwardly next to the reference architecture, where every failed phase stops the pipeline. Both make sense, so decide up front which SBOM failures block a release and which only raise an alert. A missing SBOM for a release candidate should block. A flaky quality score probably shouldn’t.
The advisory describes two integration patterns. Build-time integration generates the SBOM right after a successful compilation, while the build context is still available. Build systems such as Yocto, Kubernetes, Linux and Zephyr already have SBOM generation built in, so you only have to enable it. Event-triggered generation uses repository webhooks on commits, pull requests and releases, with queueing for concurrent requests and a generation history for audits.
The common configuration advice is practical: a dedicated directory for SBOMs, source SBOMs kept apart from generated ones, naming conventions that link each SBOM to its component, ignore patterns so SBOMs don’t end up in builds, reusable pipeline templates, and validation checkpoints before anything is published. Vulnerabilities found through the SBOM should be linked to remediation timelines, severity thresholds and escalation paths, with timelines based on severity, exploitability, exposure, product criticality, patch availability and compensating controls.
Two last recommendations stand out. SBOM processes should produce evidence for internal audits, conformity assessments, incident response and supervisory requests: generation logs, validation results, signatures, timestamps, release links and retention records. And organizations should document the known gaps, exceptions and known unknowns in their SBOM coverage, especially where dependencies can’t be identified, supplier information is missing or binary-only components can’t be fully analyzed.
Security controls for the pipeline
The advisory closes with security controls across the SBOM pipeline. For all phases, it lists role-based access control, MFA, least privilege, TLS 1.3 with certificate validation, audit logging, alerts on failed validations and signatures, code review and branch protection for pipeline definitions, version-controlled configuration, and verifying the integrity of the generators and other tools before they run. Generation adds trusted registries and verifiable build provenance. Signing and storage add secrets in a vault, cryptographic binding between SBOM and artifact, tamper-evident storage, integrity monitoring, version history, and backup and recovery for repositories, signing material and audit logs.
None of this is specific to SBOMs. It’s the hardening your build system needs anyway. An SBOM is only as trustworthy as the pipeline that produced it.
What it means for the CRA
Annex I part II of the Cyber Resilience Act requires manufacturers to “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Article 13(5) adds due diligence for third-party components, open source included. The SBOM is part of the technical documentation, which a market surveillance authority can request (Annex VII, point 8). Article 13(24) allows the Commission to specify the format and elements of the SBOM in an implementing act. The obligation applies from 11 December 2027, together with the rest of Annex I.
The advisory doesn’t interpret those obligations, but it fills in much of the how. Two things are worth taking from it. The legal minimum is top-level dependencies, while the survey shows buyers asking for depth, so your customers will set the bar higher than the regulation. And almost every recommendation produces evidence: logs, validation results, signatures, retention records. That’s the material a conformity assessment body or authority will ask for.
On the standards side, EN 40000-1-3 covers the vulnerability handling requirements of Annex I part II, which is where the SBOM obligation sits. Our harmonised standards overview tracks its status, and our CRA guide for SMBs covers the other obligations.
Our take
This is the most practical SBOM document an EU body has published so far. The BSI and CISA mapping saves anyone serving both markets a day with a spreadsheet, the CI/CD reference architecture gives teams a picture to aim for, and the STRIDE model treats the SBOM pipeline as attack surface, which most organizations still don’t.
It has gaps. It’s written from the producer’s side: checking the quality of SBOMs you receive from suppliers, and what to do when they fall short, gets little attention, and that’s where many SMEs will spend their time once suppliers start delivering CRA SBOMs. VEX shows up in the risk table but not in the lifecycle or the pipeline. And the tooling table needs a sanity check before you copy it.
If you’re starting from zero, follow the advisory’s order. Generate a CycloneDX or SPDX SBOM at build time in CI, validate the schema and the component identifiers, sign it, store it somewhere you control, and monitor it continuously with a tool such as Dependency-Track. Get that working for one product before you think about runtime SBOMs.
Sources: ENISA, Technical Advisory for Software Bill of Materials, October 2026; ENISA, SBOM Adoption State of Play 2026; BSI TR-03183-2, version 2.1.0; CISA, 2026 Minimum Elements for a Software Bill of Materials; Regulation (EU) 2024/2847, the Cyber Resilience Act.