+1. Introduction
---+1.1 Introduction
---+1.2 Scope and Context
---+1.3 Note on the current version of the document

1. Introduction

Introduction

1. Übersicht

Bezeichnung Standard
1.1 Introduction

Modern software products contain hundreds or thousands of components, each potentially harbouring vulnerabilities that threaten application and operating system security. Without component visibility, organisations operate blindly, discovering exposures only after exploitation occurs.

The Software Bill of Materials (SBOM) supports proactive vulnerability tracking by identifying components with potential vulnerabilities, allowing security teams to correlate component inventories against publicly disclosed security vulnerabilities and respond to emerging risks. Beyond immediate vulnerabilities, SBOM data supports the assessment of component viability and supply chain sustainability risks.

An SBOM is a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements. The SBOM should be drawn in a commonly used and machine-readable format identifying and documenting components contained in the products with digital elements. It can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, in particular it helps manufacturers and users to track known newly emerged vulnerabilities and cybersecurity risks (1).

Core Capabilities

  • Transparency . Reveals third-party and open-source components comprising modern software.
  • Traceability . Links deployed software to upstream suppliers and downstream consumers.
  • Compliance . Provides auditable records for regulatory and contractual requirements.
  • Security . Supports vulnerability detection and software provenance verification.

SBOMs form a foundational data layer rather than a complete security solution. Their value emerges through integration with security processes such as timely patching, mitigation activities, and documented vulnerability handling decisions, with continuous maintenance, and systematic deployment across the software development lifecycle (SDLC).

This document provides practical guidance on the adoption of SBOM, and it is intended for organizations especially micro-, small and medium enterprises (SMEs) and stewards seeking to set up the initial capabilities to enhance the software supply chain transparency. It aligns with the security principles from the ENISA Secure by Design and Default Playbook (2), particularly supply chain controls, lifecycle management, and secure coding and verification practices. It introduces key concepts, industry standards, use cases and implementation practices to support organisations initiating their SBOM journey. In particular, this document:

  • outlines the SBOM implementation architecture and data flows based on a defined lifecycle;
  • presents an indicative SBOM threat model along with targeted risks;
  • lists measures to address the security issues across the SBOM ecosystem.

This technical advisory considers regulatory requirements such as those set out in the Cyber Resilience Act (CRA) (3), in particular essential requirements related to SBOM obligations for manufacturers but essentially describes recommended best practices that may go beyond those requirements.

It aims to provide technical context to such requirements by describing common threats across the SBOM lifecycle along with practical recommendations to mitigate them. However, this document should not be considered as a legal interpretation of the CRA.

1.2 Scope and Context

This technical advisory is intended for guidance purposes only. The recommendations and best practices described herein are non-mandatory and do not create or modify any legal, regulatory, or compliance obligations.

The scope of this technical advisory is limited to Software Bill of Materials and does not cover other emerging Bill of Materials (BOM), such as Software Bill of Materials for AI, Hardware Bill of Materials (HBOM), Cryptographic Bill of Materials (CBOM) or other variants. While all artifacts may share some common principles, they also have differentiators and therefore are considered out of scope for this advisory.

This technical advisory remains sector-agnostic and applicable across all types of organisations regardless of their operational environment or industry. It is primarily focused on organisations that are at the early stage of SBOM adoption, and it does not provide a framework for assessing and improving organisational maturity. Future editions may cover the topic more extensively.

1.3 Note on the current version of the document

The current version of the document is released as a result of the ENISA call for feedback (4) which took place between the 17 th of December 2025 and the 23 rd of January 2026 and it is heavily influenced by the survey results presented at ENISA’s SBOM Adoption State of Play 2026 published on the 9 th of June 2026 (5). Via the call for feedback ENISA received 67 contributions from public and private stakeholders, cybersecurity experts, and the open-source community.

Based on this feedback and the survey results, ENISA recognised the need to transform the “ SBOM

Landscape Analysis: Towards an implementation guide ” into a “ Technical Advisory for Software

Bills of Materials ” to better respond to the needs and feedback of the ecosystem.

Finaly, this version also reflects the feedback provided by experts participating in the SBOM Workstrand under the CRA Expert Group as part of the review cycle conducted between 31 July and 11 September 2026.

Acknowledgements

We would like to publicly thank all stakeholders that provided their views and feedback! All

contributions have been reviewed and, to the maximum extent possible, the recommendations and observations have been addressed in this final version. This document may go through regular revisions.

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Zugehörige Regulierungen

2. Identifizierte Anforderungen

Anforderungen
Quelle Anforderung

3. Zugehörige Regulierungen

Regulierungen
Quelle Regulierung