How the CRA treats open-source software
The CRA distinguishes between open-source software (OSS) developed in a non-commercial context and OSS provided as part of a commercial activity. If OSS is placed on the EU market for profit or as part of a paid service, the entity providing it is treated as a "manufacturer" and must ensure full compliance with the Act's security requirements.
What it means
The intent of the CRA is to avoid placing an undue burden on individual contributors, non-profit foundations, or community-driven projects that do not generate revenue from their software. Purely non-commercial open-source development remains largely outside the scope of the mandatory obligations.
However, once OSS is integrated into a commercial product or provided as a paid support/subscription service, it becomes "products with digital elements." In these cases, the entity that puts the product on the EU market—regardless of whether they wrote the code or simply bundled existing open-source libraries—is legally responsible for its security and compliance.
In practice, this means commercial vendors cannot use the "open source" nature of their software as a shield against liability. If you profit from the distribution of OSS in the EU, you must treat those components with the same rigor as proprietary code.
How to meet it
- Conduct a Commerciality Assessment: Determine if your distribution of OSS constitutes a "commercial activity" (e.g., selling licenses, charging for support, or bundling software into a paid product).
- Maintain a Software Bill of Materials (SBOM): Create and maintain a detailed inventory of all open-source components, versions, and licenses used in the commercial version of the software.
- Implement Vulnerability Monitoring: Establish a process to monitor upstream OSS projects for reported vulnerabilities (CVEs) affecting your specific versions.
- Establish a Patching Pipeline: Create a mechanism to quickly integrate security updates from upstream open-source projects into your commercial distribution and push them to users.
- Perform Security Testing: Conduct vulnerability scanning and penetration testing on the final integrated product, ensuring that OSS components are configured securely.
- Define Legal Responsibility: Clearly identify which entity in your organization or supply chain is the "manufacturer" responsible for EU compliance declarations.
Evidence an auditor asks for
- SBOM Records: A machine-readable list of all open-source dependencies and their respective versions.
- Vulnerability Management Logs: Documentation showing when a vulnerability in an OSS component was identified and the timestamp of when the fix was deployed to customers.
- Compliance Declaration (EU Declaration of Conformity): For commercial products, the signed document stating that the product meets CRA security requirements.
- Security Policy for Third-Party Code: A written internal policy detailing how open-source components are vetted and approved before being integrated into a commercial release.
Common pitfalls
- The "Open Source Exemption" Myth: Assuming that because software is licensed under an OSS license (like MIT or Apache), it is automatically exempt from the CRA regardless of how it is sold.
- Ignoring Transitive Dependencies: Focusing only on direct dependencies while failing to track and secure deep-level libraries brought in by those dependencies.
- Lack of Upstream Tracking: Failing to monitor the original project for security advisories, relying instead on generic scanners that may have a lag time.
- Undefined Responsibility: In partnerships where one entity provides the OSS and another sells it, failing to contractually agree on who is responsible for maintaining compliance evidence.