Since 11 September 2026, the Cyber Resilience Act has imposed a vulnerability notification obligation on manufacturers of digital products. This deadline has focused security teams' attention on the reporting procedure. But one question remains in the blind spot: what happens when your product relies, like almost all modern software, on open source components?
The 2024 Open Source Security and Risk Analysis report by Synopsys found that 96 % of commercial codebases contain open source components. For these organisations, the CRA is not just a notification obligation: it redefines the chain of responsibility and requires an inventory that many have not yet built.
Open source "as such" is excluded, but your product is not
The CRA excludes from its scope free software developed outside any commercial activity. A developer who publishes a project on a public forge for the community, without economic consideration, is not subject to the regulation's obligations.
The boundary stops there. As soon as an open source component is integrated into a commercial product, the manufacturer of that product takes on full CRA responsibility. The licence of the component (MIT, Apache, GPL) has no effect on this allocation. You distribute the product, you answer for it.
This is the regulation's definition of "manufacturer": any entity that places a product containing digital elements on the European market, even if it wrote only a fraction of the code that makes it up.
The open-source software steward status
The CRA creates an intermediate status: the "open-source software steward". This term designates structures (generally foundations or consortia) that ensure the maintenance and sustainability of an open source project used in commercial environments, without being its direct manufacturers.
This status brings a lighter regime. Stewards are not subject to the essential security requirements or to the full conformity assessment procedures. In return, they must cooperate with supervisory authorities and put in place a vulnerability management policy.
For your organisation, this status changes little if you are an integrator. What matters is knowing whether an open source project you integrate has an active steward: this determines the maturity of its vulnerability disclosure process, and therefore how quickly you will be informed of an exploitable flaw in your product.
What the CRA concretely requires of you
The regulation requires the manufacturer to maintain a Software Bill of Materials (SBOM) for the entire lifetime of the product, for at least ten years after it is placed on the market. This SBOM must list every integrated component, including the transitive dependencies of open source libraries.
The minimum content of a compliant SBOM includes: the name and version of each component, the applicable CVE identifiers, and the licences. The SPDX and CycloneDX formats are the most widely used for interoperability with automated analysis tools.
Added to this traceability requirement are the notification obligations in force since 11 September 2026: an early warning within 24 hours of detecting an actively exploited vulnerability in your product, a full report within 72 hours, and a final report within one month.
If this vulnerability comes from an open source library you integrate, the 24-hour period starts as soon as you become aware of it, not when the maintainer publicly discloses it. Active monitoring of your dependencies is no longer an optional good practice.
Three priority actions
First action: map your open source dependencies beyond the direct ones, going down the dependency tree to the transitive dependencies. Tools such as Syft, Trivy or the SBOM capabilities of modern CI/CD pipelines automate this extraction. The result feeds your CRA SBOM directly.
Second action: connect your software chain to vulnerability data feeds. The EUVD (European Vulnerability Database) publishes CVEs relevant to the European market, relayed to the CERT-FR in France. Your teams must trace the relationship between each alert and the components in your inventory, in an automated way.
Third action: formalise your notification process. If you detect an exploited vulnerability in a component you distribute, the route to ENISA via your national CSIRT must be documented and tested before a real incident takes it. The CRA does not forgive improvisation within a 24-hour alert window.
The blind spot: your suppliers' dependencies
One last point often escapes the initial analysis. If you integrate a component developed by a supplier, and that component itself contains undeclared open source, your SBOM is incomplete and your CRA compliance is at risk.
The CRA's chain of responsibility pushes the question upstream in your software supply chain, exactly as NIS2 and DORA have done for operational supply chains. For organisations that have already structured their dependency management in this register, extending it to the CRA scope relies on the same tools. The article SBOM and software inventory under NIS2/DORA: the obligation your IT department has not yet addressed details the parallel requirements that already apply today.
Your contracts with software component suppliers must now include commitments on traceability and vulnerability disclosure. A supplier that cannot produce an SBOM for what it delivers to you represents a CRA risk that you bear alone.
What to take away
The CRA does not distinguish between code you wrote and code you integrated: it holds the manufacturer responsible for the whole product it distributes. For a product containing open source, this means a continuous traceability obligation, active monitoring of vulnerabilities in your dependencies, and the operational capacity to notify from the moment of detection.
These three elements are not long-term projects. With the 11 September 2026 deadline now passed, they fall under immediate compliance. Teams that have not yet built their SBOM or formalised their notification process must do so now.