Software supply chains have become very complex. A product may incorporate operating-system packages, commercial libraries, open-source components, frameworks, firmware, and dependencies originating from many different suppliers.
Understanding exactly which software components are contained in a product is therefore an essential part of cybersecurity risk management. This visibility is important for establishing an effective, accurate, and, where possible, automated vulnerability-handling process. Knowing which components and versions are present enables manufacturers to identify potentially affected products when new vulnerabilities are disclosed, assess their relevance and impact, and take appropriate remediation measures throughout the product lifecycle.
With the introduction of the EU Cyber Resilience Act Regulation (EU) 2024/2847 SBOMs have also become an explicit regulatory consideration for manufacturers of products with digital elements.
An SBOM (Software Bill of Materials) can be understood as a structured inventory of the software components contained in a product. Rather than simply providing a list of software names, a mature SBOM can provide information such as:
The objective is not documentation for documentation's sake. An SBOM provides the manufacturer with visibility over its software supply chain and can significantly improve its ability to answer an important cybersecurity question: “Does this vulnerability affect any component contained in my product and on my final product?”
That capability is particularly important when responding to newly discovered vulnerabilities in widely used third-party components.
Machine-readable formats enable this information to be processed automatically by development, vulnerability-management and product-security tools, and two of the most commonly used SBOM formats are CycloneDX and SPDX.
Yes. The Cyber Resilience Act establishes a direct requirement relating to SBOMs in Annex I, Part II, point 1, as part of the vulnerability-handling requirements applicable to manufacturers:
Manufacturers of products with digital elements shall:
(1) 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.
As seen, the CRA does not prescribe one particular SBOM format, nor does the Regulation itself define an exhaustive list of mandatory SBOM fields. Article 13(24) nevertheless allows the European Commission to specify the format and elements of the SBOM through implementing acts, considering European or international standards and best practices.
Manufacturers should therefore consider the CRA requirement as a minimum regulatory baseline rather than a complete technical specification for SBOM implementation.
An SBOM should not be viewed as an isolated compliance document. Under the CRA, it forms part of the manufacturer's wider vulnerability-handling obligations.
Annex I, Part II requires manufacturers, among other things, to identify and document vulnerabilities and software components, address and remediate vulnerabilities without delay, provide security updates, disclose relevant information about fixed vulnerabilities or provide mechanisms for the secure distribution of updates. An SBOM becomes particularly useful when integrated into this process.
For example, when a new CVE (Common Vulnerabilities and Exposures) affecting a third-party library is published, the manufacturer should be able to determine whether the affected component (and the relevant version) exists within one or more product versions.
The real value of an SBOM therefore lies not simply in generating the file, but in maintaining the processes that make the information accurate, traceable, and actionable throughout the product lifecycle.
Where third-party conformity assessment is applicable under the CRA, the question is unlikely to be simply if the SBOM file exists, but the more relevant assessment questions concern whether the manufacturer has established an effective and repeatable process.
Here are some questions organizations should ask themselves to help ensure their SBOM processes are effective and compliant:
The SBOM should ultimately be considered one piece of evidence within a broader cybersecurity lifecycle.
From a conformity-assessment perspective, several questions are particularly relevant.
Software composition changes over time. An SBOM should therefore be clearly associated with the relevant product and software version. A generic component inventory that cannot be linked to a specific product release may have limited value as compliance evidence.
The technical documentation required by the CRA must itself identify software versions affecting conformity with the essential cybersecurity requirements.
A spreadsheet or manually maintained PDF may be useful internally, but the CRA specifically refers to a commonly used and machine-readable format.
Using established formats such as SPDX or CycloneDX can facilitate automated processing, vulnerability matching, and exchange of component information across supply chains.
A component name alone may not be sufficient. For example, two packages with similar names can originate from different ecosystems or suppliers.
Where possible, component records should contain identifiers that allow the precise software artefact to be determined. Examples may include version information, package URLs, supplier information, and cryptographic hashes.
The CRA explicitly requires coverage of at least top-level dependencies.
Modern software frequently depends on components that themselves depend on further components. Vulnerabilities may therefore occur at several levels below the software directly integrated by the manufacturer.
The required minimum and the level of information needed for effective product-security management should not automatically be assumed to be the same.
Manufacturers should understand how the information has been produced. Depending on the development environment, SBOM information may be obtained from source-code dependency analysis, package managers, build systems, container images, and Software Composition Analysis tools, and other sources.
Automated generation can improve repeatability, particularly when integrated into CI/CD processes. However, automated generation does not by itself guarantee completeness or correctness.
Manufacturers remain responsible for understanding the cybersecurity risks associated with components incorporated into their products. Supplier-provided SBOM information can therefore become an important part of the software supply-chain assurance process.
Manufacturers may need to establish contractual or technical mechanisms to obtain adequate component information from software suppliers.
An SBOM created at the beginning of product development and never updated quickly loses its value.
Component information should remain aligned with released product versions and with changes made during the support period.
The CRA requires technical documentation to be continuously updated where appropriate, at least during the support period.
Completeness should not be assessed only in terms of the number of fields populated. The more important question is whether the SBOM enables the manufacturer to identify affected products when new vulnerabilities emerge.
Organizations should therefore consider integrating SBOM information with vulnerability intelligence such as CVE information, vulnerability databases and, where appropriate, VEX (Vulnerability Exploitability eXchange) information.
Not necessarily. The CRA does not establish a general obligation to publish the SBOM publicly. The SBOM forms part of the technical documentation, and Annex VII provides it to be made available following a reasoned request from a market-surveillance authority where necessary to verify compliance.
This distinction is important because SBOM generation, SBOM maintenance, and SBOM publication are separate questions.
An SBOM that is automatically generated but incomplete, outdated or disconnected from vulnerability management provides little cybersecurity benefit. A useful SBOM should allow a manufacturer to answer questions such as:
When those questions can be answered consistently, the SBOM becomes more than compliance with documentation. It becomes an operational element of software supply chain security.
The following sources provide useful starting points for organizations preparing their SBOM processes:
Applus+ uses first-party and third-party cookies for analytical purposes and to show you personalized advertising based on a profile drawn up based on your browsing habits (eg. visited websites). You can accept all cookies by pressing the "Accept" button or configure or reject their use. Consult our Cookies Policy for more information.
They allow the operation of the website, loading media content and its security. See the cookies we store in our Cookies Policy.
They allow us to know how you interact with the website, the number of visits in the different sections and to create statistics to improve our business practices. See the cookies we store in our Cookies Policy.
Based on your behavior on the website (where you click, how long you browse, etc.) we establish parameters and a profile for you to display ads that correspond to your interests. See the cookies we store in our Cookies Policy.