Open-source dependency management should combine provenance, maintainer health, update history, vulnerability intelligence, release inventory and remediation planning. Licensing remains important, but CRA readiness requires a cybersecurity process beyond licence compliance alone.
Open Source Is Explicitly Included in Component Due Diligence
Article 13(5) expressly includes free and open-source software components in the manufacturer's due-diligence duty, including components that were not made available on the market in the course of a commercial activity. Using a community-maintained package therefore does not remove the need for a security assessment.
Assess Maintainer and Project Health
Before adopting an important dependency, review release activity, security-update history, vulnerability response, governance and signs of abandonment. The appropriate depth of review should reflect how critical the component is to the product and how difficult it would be to replace.
Record Provenance and Exact Versions
Document where the component came from, the exact version or commit used and how it entered the build. This reduces the risk of confusing similarly named packages or relying on a repository state that differs from the code actually shipped.
Include Open Source in the SBOM
Open-source software components that form part of the product should be represented in the component inventory and the SBOM as applicable. Release-linked records make it possible to determine which product versions are affected when a project publishes a security advisory.
Monitor Vulnerabilities After Release
Open-source dependency due diligence is not complete at integration. Manufacturers need ongoing monitoring during the support period because vulnerabilities can be disclosed long after a dependency first enters the product.
Notify the Maintainer When You Identify a Vulnerability
Article 13(6) requires manufacturers that identify a vulnerability in an integrated component to report it to the person or entity manufacturing or maintaining the component. For open source, that can mean following the project's security-reporting process rather than disclosing the issue publicly without coordination.
Share Relevant Fixes Upstream Where Appropriate
Where the manufacturer develops a modification to address the component vulnerability, Article 13 requires relevant code or documentation to be shared with the maintainer where appropriate. Internal forks should therefore not automatically become a dead end for security fixes.
Plan for Abandoned Dependencies
A dependency with no active maintainer can create long-term support risk. Product teams should define replacement, internal maintenance or isolation strategies before the component becomes an unsupported single point of failure during the product support period.
Do Not Confuse OSS Licensing With CRA Security Compliance
Licence review answers different questions from CRA cybersecurity due diligence. A component can be licence-compliant and still be poorly maintained, vulnerable or unsuitable for the product's risk profile.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.