Deep Dive - CRA Requirement (1) Identify & Document Vulnerabilities

The first vulnerability-handling requirement under the EU Cyber Resilience Act (CRA) introduces a clear obligation: manufacturers must maintain visibility into the components that make up their products, including external libraries and dependencies, by documenting them and identifying vulnerabilities:

“(1) identify and document vulnerabilities and components contained in the product, 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 product;”

This requirement establishes visibility as a cornerstone of product security. By mandating the identification and documentation of vulnerabilities and components, the CRA ensures that manufacturers, and ultimately users, have a clear understanding of what is inside a product and where risks may exist.

What this requirement means

A product cannot be secured if the manufacturer does not know what it contains. Hidden or unknown software components create blind spots that attackers can exploit. This requirement addresses that risk by making sure manufacturers always have an up-to-date view of the building blocks inside their products.

This requirement means that manufacturers of products with digital elements must have a clear understanding of what software components are included in their products. Specifically, they are expected to identify and keep track of all the major software building blocks (known as top-level dependencies) used in the product. Alongside this, they must be aware of any known vulnerabilities in those components. To ensure this transparency, the manufacturer must create a Software Bill of Materials (SBOM), which is essentially a detailed inventory of the software components and implement vulnerability scanners in their CI/CD pipeline. This SBOM is typically produced in a commonly used, machine-readable format so that it can be easily analyzed, updated, and shared with relevant stakeholders.

Relevant Standards and Guidelines

Although the CRA does not prescribe specific technical standards, several frameworks and standards can support compliance with the requirement to identify and document vulnerabilities and components through a Software Bill of Materials (SBOM):

• ISO/IEC 27036 (Parts 1–3) provides guidance on managing information security risks in supplier relationships, including third-party software components. It is relevant for SBOM in the context of supply chain security but does not directly address SBOM creation, management, or exchange. Its value lies in setting a structured approach to supplier due diligence across design, surveillance, and maintenance phases.

• SPDX is a Linux Foundation standard widely used to share software component details, licenses, copyrights, and security data in a consistent, machine-readable SBOM format. It supports automated vulnerability matching and transparency in open-source and commercial software.

• CycloneDX is another SBOM specification designed for application security and supply chain analysis. It offers a lightweight, composable format for describing software components and metadata, with strong adoption in security tooling and DevSecOps pipelines.

• NTIA’s Software Component Transparency Initiative (U.S.) has helped consolidate best practices and interoperability for SBOMs, further strengthening industry adoption.

• ECSO Supply Chain Management & Product Certification Composition and IIoTSBOM (EU initiative by LSEC, Flanders Make, and KU Leuven with support from CISA) extend SBOM thinking into industrial and IoT/OT contexts, addressing gaps in constrained environments.

Taken together, these standards help manufacturers meet CRA obligations by ensuring that all libraries, external components, and version numbers are documented in a commonly used and machine-readable SBOM, aligned to supply chain monitoring practices.

However, as ENISA's Standards Mapping highlights, ISO/IEC 27036 on its own leaves a gap: it secures the supplier relationship, but does not guarantee SBOM generation or exchange.

How to approach Implementation

To implement this requirement in practice, manufacturers can rely on automated tools that support vulnerability scanning and SBOM generation. Vulnerability scanning tools are able to analyze software directly, checking code, libraries, and dependencies for known security issues. SBOM generation tools create a structured list of all components included in the product, which helps to increase transparency and traceability.

A common way to set this up is to integrate these tools directly into the development pipeline. This ensures that every time new software is built or existing software is updated, an up-to-date SBOM is produced automatically. At the same time, vulnerability scans can be triggered to identify any issues in the new or updated code. The scanner checks the identified components against public vulnerability databases, such as the CVE database or the EU Vulnerability Database (EUVD). When an SBOM is shared with customers or received from suppliers, it can also be provided as input to vulnerability scanning tools. This combination allows security checks to be automated, repeatable, and consistently applied throughout the product lifecycle.

To ensure interoperability and broad tool support, SBOMs are typically created in standardized formats. The most widely adopted formats today are CycloneDX and SPDX. Both are supported by a broad range of open-source and commercial tools, which makes it easier for manufacturers to select a solution that fits their development environment. By adopting these practices, manufacturers can establish a reliable process that keeps track of all software components, continuously scans for known vulnerabilities, and improves overall product security.

Strategic Considerations beyond Compliance

For many organizations, the requirement to identify and document vulnerabilities and components through a Software Bill of Materials (SBOM) represents more than a compliance checkbox, it signals a shift in how supply chain risk is managed. Traditionally, component tracking has been ad hoc, often left to individual developers or siloed teams without a consistent process. This made it difficult to answer basic questions like: Which version of a library is in use? Where is it deployed? Who is responsible if a vulnerability is discovered? The CRA forces companies to confront these blind spots and establish systematic visibility across their entire software stack.

Meeting this requirement is not just about producing an SBOM file; it’s about adopting a new discipline of software transparency. That means automating dependency tracking, integrating SBOM generation and vulnerability scanning into CI/CD pipelines, and ensuring that procurement, legal, and security teams can all access the same source of truth. Beyond compliance, this enables faster vulnerability response, clearer accountability with suppliers, and greater trust with customers who increasingly expect visibility into software provenance.

Ultimately, embracing SBOMs as a strategic tool rather than a regulatory burden can transform product security and reduce firefighting costs when vulnerabilities emerge.

In our next post, we will explore Requirement (2): Risk Management & Security Updates, an obligation that redefines how security issues are fixed.

Next Blog CRA Vulnerability Handling Requirement (2): https://www.tributech.io/blog/cra-vulnerability-handling-requirement-2-risk-management-security-updates