CRA Documentation for Open Source Components

Open-Source Components Belong in Product Cybersecurity Documentation

The CRA documentation duties apply to the manufacturer's product as a whole, including relevant third-party and open-source dependencies integrated into that product. Article 13(4) requires the cybersecurity risk assessment to form part of the technical documentation, while Annex I Part II requires manufacturers to identify and document components and vulnerabilities. The manufacturer should therefore be able to connect a material open-source dependency to the product version, architecture, risk assessment and vulnerability-handling process.

• Document dependencies in the context of the finished product.
• Connect components to relevant product versions.
• Connect components to the cybersecurity risk assessment.
• Maintain evidence throughout the support period.

The CRA Requires a Software Bill of Materials

Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials. The SBOM is therefore part of the vulnerability-handling requirements rather than merely an optional software supply-chain practice. Open-source libraries, frameworks and other dependencies within the relevant SBOM coverage should be represented in a way that allows the manufacturer to identify affected components when vulnerability information appears.

• The SBOM is part of Annex I vulnerability handling.
• It supports component identification.
• It supports vulnerability impact analysis.
• Open-source dependencies should not remain invisible.

The SBOM Must Use a Commonly Used Machine-Readable Format

The CRA requires the software bill of materials to use a commonly used and machine-readable format. The Regulation does not in Annex I mandate one named SBOM syntax. Article 13(24) empowers the Commission to specify the format and elements of the SBOM through implementing acts taking account of standards and best practices. Manufacturers should therefore use a structured format that can be processed by tooling and monitor future implementing measures affecting required SBOM format or content.

• The format must be machine readable.
• The format should be commonly used.
• Annex I does not name one mandatory syntax.
• Future implementing acts can specify format and elements.

The CRA Minimum Is At Least Top-Level Dependencies

Annex I Part II states that the SBOM must cover at least the top-level dependencies of the product. This is a legal minimum, not necessarily the depth most useful for security operations. A manufacturer can maintain deeper dependency information where needed to understand transitive exposure, inherited libraries or nested package relationships. The compliance record should distinguish the CRA minimum from any broader internal software-composition inventory the organisation maintains for effective vulnerability management.

• Top-level dependencies are the minimum statutory coverage.
• Deeper dependency information can be operationally useful.
• Transitive dependencies can create real product risk.
• Internal inventories can exceed the CRA minimum.

Annex VII Requires Component Architecture Information

Annex VII requires technical documentation to contain necessary information on product design and development, including where applicable a description of the system architecture explaining how software components build on or feed into one another and integrate into the overall processing. An SBOM alone does not provide that architectural explanation. For material open-source components, the manufacturer should know where the component sits, what other modules depend on it, what privileges it has and what security boundary it affects.

• Architecture documentation and SBOM serve different purposes.
• Describe how components interact.
• Describe how components integrate into overall processing.
• Record important trust and dependency relationships.

The Cybersecurity Risk Assessment Should Reflect Dependency Risk

Article 13 requires a cybersecurity risk assessment and Article 13(4) requires that assessment to be included in the technical documentation. Where an open-source dependency performs security-sensitive processing, exposes network functionality, handles credentials or creates another material attack surface, the manufacturer's assessment should reflect those characteristics. The fact that the dependency is widely used or maintained by a reputable project does not eliminate the need to assess its role within the manufacturer's own product.

• Assess the dependency in its product context.
• Consider privileges and exposed interfaces.
• Consider consequences of component compromise.
• Update the assessment when material dependency risks change.

Document Vulnerabilities and Relevant Third-Party Information

Article 13(7) requires manufacturers to systematically document, proportionately to the nature and cybersecurity risks of the product, relevant cybersecurity aspects including vulnerabilities of which they become aware and relevant information provided by third parties. For open-source components, this can include upstream advisories, maintainer disclosures, vulnerability database information, security audit findings and internal analysis. The manufacturer should preserve enough context to explain whether the product was affected and what action was taken.

Annex VII Requires Vulnerability-Handling Process Documentation

Annex VII requires necessary information and specifications concerning the manufacturer's vulnerability-handling processes. It specifically includes the software bill of materials, coordinated vulnerability disclosure policy, evidence that a contact address for vulnerability reporting has been provided and a description of the technical solutions chosen for secure distribution of updates. These requirements apply to the manufacturer's product process, even where many of the vulnerabilities originate in third-party or open-source dependencies.

• Include the SBOM.
• Include the coordinated vulnerability disclosure policy.
• Provide evidence of a vulnerability reporting contact.
• Describe secure update distribution.

Record Upstream Maintainer and Project Information

Article 13(6) requires manufacturers to report identified component vulnerabilities to the person or entity manufacturing or maintaining the component. For important open-source dependencies, maintaining project and security contact information therefore supports compliance as well as engineering operations. The record can identify the upstream project, repository, security policy, vulnerability reporting mechanism and relevant release source so that security teams do not need to reconstruct those relationships during an urgent incident.

• Record the upstream project.
• Record the authoritative source or repository.
• Record security contact information.
• Record vulnerability reporting procedures.
• Record the version source.

Document Local Patches and Forks

A product can contain an open-source component that differs materially from the upstream release because the manufacturer maintains local patches or a fork. Technical documentation should preserve those changes where they affect cybersecurity, because vulnerability status cannot then be inferred solely from the upstream version number. The manufacturer should know which upstream fixes have been incorporated, which local changes alter attack surfaces and whether a local vulnerability fix should be shared upstream under Article 13(6).

• Record material local patches.
• Record the upstream base version.
• Track security-relevant divergence.
• Link local fixes to vulnerability records.
• Consider upstream fix sharing.

The SBOM Does Not Automatically Have to Be Public

The CRA requires manufacturers to draw up the SBOM, but the Regulation does not create a general rule that every manufacturer's complete SBOM must be publicly posted. Annex II instead provides that if the manufacturer decides to make the SBOM available to the user, the user information should state where it can be accessed. Market surveillance authorities can also obtain relevant SBOM information in circumstances provided by the Regulation. Manufacturers should therefore separate the obligation to create and maintain the SBOM from any decision or separate requirement concerning disclosure.

• Creating the SBOM is required.
• General public publication is a separate question.
• Annex II addresses access information if the manufacturer chooses to make it available.
• Authorities can have information-access powers under the CRA.

Keep Documentation Aligned With Product Versions

Open-source dependencies change frequently. A technical file describing one release can become inaccurate after dependency upgrades, backports or local security patches. Manufacturers should therefore connect SBOMs, architecture information, risk assessments and vulnerability records to identifiable product versions. Article 13(7) also requires the cybersecurity risk assessment to be updated where applicable when relevant cybersecurity information changes.

• Version the SBOM.
• Version architecture evidence where necessary.
• Track component upgrades.
• Track security backports.
• Update risk evidence when applicable.

Build One Evidence Chain From Dependency to Remediation

A strong CRA evidence chain should let a reviewer move from an open-source dependency entry to its product version, architectural role, cybersecurity risk assessment, upstream project information, known vulnerability history, local modifications and remediation decisions. The goal is not to create paperwork for every trivial package. Documentation should be proportionate to the nature and cybersecurity risks of the product, while still satisfying the specific SBOM and technical-documentation requirements imposed by the CRA.

• Link component identity to product version.
• Link component to architecture.
• Link material risks to the cybersecurity assessment.
• Link vulnerabilities to remediation evidence.
• Keep documentation proportionate and reproducible.