The European Union Agency for Cybersecurity (ENISA) issued technical guidance on implementing software bills of materials (SBOMs), urging organizations to use structured, machine-readable inventories to improve software supply chain transparency, identify vulnerable components and track dependencies. It outlines how manufacturers and software users can document software components, their origins, versions, licenses and relationships to support vulnerability management, software asset inventory and compliance processes. ENISA said SBOMs provide a foundation for security rather than a complete solution, with their value depending on integration into established security workflows, timely patching and documented vulnerability-handling decisions.
In its ‘ENISA Technical Advisory for Software Bill of Materials,’ the agency warns that SBOMs can introduce security and operational risks if they are inaccurate, outdated, tampered with or shared without adequate access controls. ENISA recommends using established formats such as SPDX and CycloneDX, validating inventories against software artifacts, verifying digital signatures and integrating SBOM generation into software development and continuous integration and delivery pipelines.
The guidance also calls for risk-based vulnerability prioritization that weighs exploitability, asset criticality, and exposure. ENISA said the advisory reflects stakeholder feedback and is intended to help organizations, particularly SMEs. In particular, it outlines the SBOM implementation architecture and data flows across a defined lifecycle, presents an indicative SBOM threat model with targeted risks, and lists measures to address security issues across the SBOM ecosystem.
The agency identified that SBOM generators pull information from several sources to identify first-party code, open-source and third-party commercial libraries, operating system packages and container images. Typical sources include source code repositories, build artifacts, package manager manifests, lock files, container images and binary analysis. For each component, the generator collects and correlates metadata such as name, version, creator, unique identifiers, licence information, external references and dependencies. How complete this metadata is depends on its availability, generator’s analysis methods and chosen data model, such as CycloneDX or SPDX.
Once software composition analysis and relationship discovery are complete, the SBOM is produced in a standard machine-readable format, most commonly CycloneDX or SPDX, and can be stored as JSON, XML, YAML or Tag-Value. The output is more than a component list, as it also maps dependency relationships. SBOMs can be generated at different phases of the software development lifecycle, and each phase yields different information to serve different needs.
Generating an SBOM delivers limited value unless it is actively used in operational and security processes, including vulnerability management, software asset inventory, licence compliance, procurement and regulatory compliance. The ENISA SBOM Adoption State of Play 2026 reflects this view. Respondents ranked industry consensus on best practices for integrating SBOM production and consumption into development as the top priority (23%), followed by integrating SBOMs into risk and compliance processes (19%) and guidance on how production and consumption methods should evolve (19%). Organisations therefore see operational integration into existing development, security and governance workflows as essential for mature SBOM adoption.
ENISA detailed the SBOM lifecycle and architecture. The SBOM provides added value when it is continuously managed throughout the SDLC and follows the software’s evolution while components are added, updated, altered or deleted through new software releases. A structured and automated SBOM lifecycle aims at ensuring that SBOMs are properly produced and consumed internally and externally. To highlight the need for this notion, a big gap was identified in the ENISA SBOM Adoption State of Play 2026, between what organisations need from SBOMs and what they actually receive.
While 36 % of respondents stated that their organisations need all primary components and direct dependencies with declared known unknowns, only 29 % actually receive them. Furthermore, 24 % need SBOMs with full depth analysis, but only 14 % receive them.
Finally, 27 % require SBOMs with depth analysis including declared known unknowns, yet only 12 % receive them. It presents the SBOM lifecycle from both a conceptual and a technical perspective and starts by illustrating the SBOM lifecycle phases from generation to consumption and continuous maintenance, then presents how these phases can be integrated and automated into a CI/CD pipeline and lists available open-source tool stack to support defined phases.
Integrating SBOM generation and consumption into CI/CD pipelines is increasingly seen as a best practice for achieving completeness, accuracy and trustworthiness. Automation lets organisations generate, validate, update and consume current SBOMs. The ENISA SBOM Adoption State of Play 2026 reflects this: 41% of organisations aim to fully automate SBOM generation for each release or build. Automation after the build stage lags, however, as only 26% expect to fully automate SBOM updates across product support period, and almost 23% expect partial automation.
Building on the conceptual SBOM lifecycle presented earlier, this section turns to technical implementation. The architectural diagram aligns with the lifecycle phases and shows how SBOM integration and automation could work across the SDLC. Each phase lists the key elements and processes needed for success, along with basic failure points.
The process starts with the source code build, which produces the information sources and triggers SBOM generation. The generator identifies software components, extracts metadata, analyses dependencies and produces a machine-readable SBOM in a standard format such as SPDX or CycloneDX. Validation then checks that the SBOM is syntactically correct, conforms to the chosen specification and contains the required metadata, including valid component identifiers. Once validated, the SBOM is cryptographically signed to ensure authenticity and integrity, then stored in a repository or registry for downstream security tools to consume.
The maintenance and update phase keeps the SBOM synchronised with the current software version, with automatic triggers prompting regeneration and a return to the earlier lifecycle phases. Security controls and trust mechanisms protect the integrity, authenticity and availability of SBOMs throughout the pipeline. Together, they allow organisations to produce reliable SBOMs that development, security, operations, procurement and compliance teams can all use.
ENISA’s technical advisory presents an SBOM-focused threat model built on Microsoft’s STRIDE framework, which provides a structured basis for continuously assessing threats across six categories: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The threats it identifies go beyond the SBOM artifact itself and cover the wider ecosystem, including generation tools, validation and signing services, repositories and consumption pipelines.
Spoofing and tampering threats focus on trust. Attackers could impersonate an SBOM author, software producer, consumer, CI/CD pipeline or generation tool, or use stolen certificates and compromised repository mirrors to distribute malicious SBOMs that appear legitimate. Tampering with components, versions, hashes, provenance or external references such as PURLs and CPEs after or before generation could lead to flawed dependency analysis, missed vulnerabilities and inaccurate inventories. Indicative mitigations include digital signatures, supplier and consumer identity verification, build attestations, secure key management, certificate revocation and integrity checks.
Repudiation and information disclosure threats concern accountability and confidentiality. If producers or authors can deny generating or distributing an SBOM, accountability and supply chain transparency suffer, a risk addressed through timestamps, audit logs, repository logging and signed releases. Uncontrolled sharing can expose technology stacks, proprietary components, supplier relationships, dependency graphs and exact versions, which hands attackers material for reconnaissance and speeds up exploitation of known CVEs. It can also breach intellectual property rights. ENISA points to controlled SBOM sharing, access control and key management as the main safeguards.
Denial of service and elevation of privilege threats target availability and control. Repository outages could leave SBOMs unavailable during incident response or procurement, while oversized or deeply nested files could exhaust parser resources and large volumes could fill storage and disrupt CI/CD pipelines where SBOMs are a mandatory step.
Mitigations include redundant infrastructure, DDoS protection, size and number limits, parser hardening and retention policies. Privilege escalation in the build pipeline, the repository or the signing infrastructure could allow corrupted SBOMs to be generated, distributed or signed as trusted, which makes access control, pipeline hardening and strong key management essential.
ENISA’s guidance on secure SBOM integration and automation recommends starting with build-time integration as the minimum viable implementation. This approach captures dependencies when they are most accurately known and requires minimal infrastructure change. Organisations can add SBOM generation as a stage in their existing CI infrastructure, use command-line tools compatible with current build environments, store SBOMs alongside build artifacts in existing repositories, and validate them through standard pipeline testing. Many build environments, including Yocto, Kubernetes, Linux and Zephyr, already offer automatic SBOM generation that only needs to be enabled.
Two integration patterns are described. In the build-time pattern, generation follows successful compilation so that direct and transitive dependencies are captured while build context is still available, along with supplementary metadata such as build environment details and compilation parameters. In the event-triggered pattern, repository webhooks start generation on commits, pull requests or releases, with queuing for concurrent requests and a generation history retained for audit and rollback.
Common configuration requirements cover repository structure, pipeline orchestration and validation. SBOMs should sit in a dedicated directory, separate from generated outputs, with naming conventions that tie them to their components and ignore patterns that keep them out of builds. Pipeline templates should be reusable, parameterised for multiple project types, and include standard validation, error handling and retry logic. Checkpoints should enforce format validation before publication, verify licence compatibility against policy and validate signatures where attestation is required.
Vulnerabilities found through SBOM consumption should be tied to remediation timelines, severity thresholds and escalation paths, shaped by severity, exploitability, exposure, product criticality, patch availability and compensating controls.
Automation removes manual inconsistencies and ensures every build has a matching SBOM. It enables immediate vulnerability assessment when new threats emerge, supports forensic analysis and compliance demonstration through historical retention, and keeps non-compliant SBOMs out of production. Success depends on mature CI infrastructure, standardised build processes, clear policies on triggers, storage and retention, and monitoring of generation success rates.
SBOM processes should also produce evidence for audits, conformity assessments, incident response and supervisory requests, including logs, validation results, signatures, timestamps, release links and retention records. Organisations should document known gaps and exceptions, especially where dependencies cannot be identified, supplier information is missing or binary-only components cannot be fully analysed.
