Open Source Vulnerability Management Under the CRA

Open Source Vulnerability Management Is Role Dependent

The CRA does not assign one universal vulnerability-management duty to everyone touching open-source code. A qualifying open-source software steward has the tailored Article 24 regime. A manufacturer incorporating open-source software into a commercial product has the manufacturer obligations in Article 13 and Annex I. An individual maintainer or contributor who is neither the manufacturer nor part of a qualifying steward does not automatically acquire those obligations merely because they receive issues or merge patches. A project should therefore establish the legal roles around the codebase before assigning CRA vulnerability responsibilities.

• Identify the manufacturer.
• Identify any open-source software steward.
• Identify maintainers and contributors separately.
• Do not assign legal duties from community titles alone.

Stewards Must Foster Effective Vulnerability Handling

Article 24(1) requires a qualifying open-source software steward to put in place and document in a verifiable manner a cybersecurity policy. That policy must foster development of secure products and effective handling of vulnerabilities by the developers of supported products. It must reflect the steward's nature and organisational arrangements. For an open-source foundation or similar steward, this means vulnerability management should be embedded into project governance rather than treated as an informal activity dependent on one maintainer.

• The cybersecurity policy must be documented.
• The documentation must be verifiable.
• Secure development should be fostered.
• Effective vulnerability handling should be supported.
• The policy should fit the organisation's actual governance.

The Steward Policy Must Address Documentation, Response and Remediation

Article 24 specifically refers to documenting, addressing and remediating vulnerabilities. A steward policy should therefore define how supported projects receive vulnerability information, record security issues, route reports to appropriate maintainers, coordinate technical analysis and support remediation. The CRA does not require every supported project to use one identical workflow. The important point is that the steward can demonstrate a systematic security process that helps developers handle vulnerabilities effectively.

• Document reported vulnerabilities.
• Define triage and ownership.
• Support remediation.
• Keep security-sensitive information appropriately controlled.
• Maintain evidence that the process operates.

Voluntary Vulnerability Reporting Should Be Encouraged

Article 24(1) requires the steward's cybersecurity policy to foster voluntary reporting of vulnerabilities by developers as referred to in Article 15. This is different from mandatory reporting of actively exploited vulnerabilities under Article 24(3). Voluntary reporting supports the wider open-source security ecosystem by creating routes through which researchers, developers and users can disclose vulnerabilities before exploitation is known. The steward should therefore provide or support clear vulnerability-reporting channels and coordinated handling processes.

• Voluntary reporting and mandatory reporting are different.
• Projects should provide clear vulnerability reporting channels.
• Security contacts should be maintainable over time.
• Reports should reach the appropriate project team.

Information Sharing Within the Open-Source Community Matters

Article 24 also requires the cybersecurity policy to promote sharing of information concerning discovered vulnerabilities within the open-source community. This reflects the collaborative nature of upstream security work. Information sharing can help related projects, downstream users and maintainers understand affected versions, fixes and dependency relationships. Disclosure should still be coordinated so that publication does not unnecessarily increase exploitation risk before users have an opportunity to apply a fix.

• Promote useful vulnerability information sharing.
• Identify affected versions clearly.
• Coordinate information with remediation.
• Avoid unnecessary exposure before fixes are available.

Downstream Manufacturers Keep Their Own Vulnerability Responsibilities

A manufacturer integrating open-source software into its product cannot treat upstream project activity as a substitute for its own vulnerability-handling duties. Annex I Part II requires manufacturers to identify and document vulnerabilities and components, remediate vulnerabilities without delay in relation to product risks, perform effective security testing and maintain coordinated vulnerability-disclosure processes. The downstream manufacturer therefore needs to monitor its open-source dependencies during the support period even where an active upstream maintainer or steward exists.

Manufacturers Must Coordinate Component Vulnerabilities Upstream

Article 13(6) creates a specific coordination duty. When a manufacturer identifies a vulnerability in an integrated component, including an open-source component, it must report that vulnerability to the person or entity manufacturing or maintaining the component. This creates an upstream feedback loop rather than allowing every downstream manufacturer to keep component vulnerabilities private. The manufacturer must also address and remediate the vulnerability in its own product in accordance with the Annex I vulnerability-handling requirements.

• Component vulnerabilities should be reported upstream.
• Open-source components are expressly covered.
• Upstream reporting does not replace downstream remediation.
• The downstream product remains the manufacturer's responsibility.

Downstream Fixes May Need to Be Shared With the Upstream Maintainer

Where a manufacturer develops a software or hardware modification to address a vulnerability in an integrated component, Article 13(6) requires the relevant code or documentation to be shared with the person or entity manufacturing or maintaining that component where appropriate. The Regulation also refers to machine-readable format where appropriate. This provision supports upstream remediation and reduces the risk that a security fix remains trapped in one downstream fork while other users remain exposed.

• Manufacturer-developed component fixes can require upstream sharing.
• Code or documentation can be relevant.
• Machine-readable form can be appropriate.
• Sharing supports broader remediation.

An Upstream Fix Does Not End the Downstream Manufacturer's Work

Even when an upstream project publishes a security fix, the downstream manufacturer must determine whether and how that fix applies to its product. The manufacturer may use a different component version, maintain local patches or expose the vulnerable code through a different architecture. The manufacturer's cybersecurity risk assessment and testing therefore remain necessary. A fixed upstream release is important evidence, but it does not by itself prove that every downstream product is remediated.

• Map upstream fixes to the exact integrated version.
• Consider downstream patches and forks.
• Retest the finished product.
• Update risk documentation where applicable.

SBOMs Support Open-Source Vulnerability Management

Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies. The SBOM helps a manufacturer answer a basic vulnerability-management question quickly: whether a newly disclosed open-source vulnerability affects the product. It should be maintained as product dependencies and versions change rather than created once only for the conformity assessment.

• Identify integrated software components.
• Record dependency information.
• Use a commonly used machine-readable format.
• Cover at least top-level dependencies.
• Keep dependency information aligned with product versions.

Article 25 Can Support the Open-Source Security Ecosystem

Article 25 empowers the Commission to establish voluntary security attestation programmes for qualifying free and open-source software in order to facilitate the Article 13(5) due diligence of downstream manufacturers. Such programmes can allow developers, users and other third parties to assess conformity with certain CRA requirements. They do not transfer the downstream manufacturer's responsibility, but they can provide additional structured evidence when evaluating open-source components.

• Article 25 supports voluntary security attestation.
• The purpose includes facilitating downstream due diligence.
• Developers, users and third parties can participate under the framework.
• Attestation does not replace manufacturer responsibility.

Build a Vulnerability Process Across Upstream and Downstream Roles

A mature open-source CRA workflow should connect the upstream project's vulnerability intake with downstream dependency monitoring. The steward, where one exists, supports secure project processes. Maintainers analyse and remediate code within the project governance model. Downstream manufacturers monitor integrated versions, evaluate risk, notify upstream maintainers when they identify component vulnerabilities, deploy fixes to their own products and preserve the documentation needed for CRA compliance. Clear role boundaries make collaboration stronger because responsibility is explicit rather than assumed.

• Define upstream vulnerability contacts.
• Track downstream component versions.
• Create escalation paths between manufacturer and maintainer.
• Record remediation decisions.
• Retain product-specific evidence.