The gradual entry into force of the Cyber Resilience Act (CRA) is reshaping the obligations of the European open source ecosystem. As of September 11, 2026, manufacturers of digital products must report actively exploited vulnerabilities and serious incidents, according to Article 14 of the regulation. General enforcement is scheduled for December 11, 2027, and not all open source projects are treated equally.
CRA and open source software: differentiated obligations between maintainers and volunteers
The CRA introduces an operational distinction that we have been anticipating since the publication of the text. Qualified professional maintainers (stewards) of open source software, those who sustainably support projects integrated into commercial products, fall within the regulatory scope. They will need to document their vulnerability management processes and contribute to the compliance chain.
Individual volunteer contributors remain outside the main scope. This dividing line is based on the commercial nature of the activity, not on the license used. A developer who publishes a patch over the weekend does not face the same constraints as a foundation that maintains a critical library deployed in thousands of products.
For SMEs and modest-sized open source projects, a free CRA preparedness tool has been released as part of the European OCCTET project, coordinated by the Eclipse Foundation. It covers dependency inventory, vulnerability management, SBOM generation (Software Bill of Materials), and compliance documentation. Additional resources are regularly referenced on mondelibre.org, which aggregates French-language publications around these regulatory developments.
European Union open source strategy: a framework covering the entire lifecycle
The new EU open source strategy is no longer limited to the adoption of open source software in administrations. It now covers the entire software lifecycle, from design to maintenance, including contribution governance. We are observing a change in posture: open source software is no longer treated as a budget-saving tool but as a lever for technological sovereignty.
This approach is part of a broader package on European technological sovereignty. It articulates the CRA requirements with interoperability and digital security policies. Public administrations are encouraged to actively contribute to the projects they use, not just to consume them.
OSPO and CRA compliance in organizations
Open Source Program Offices (OSPO) centralize the management of open source dependencies, license tracking, and contribution coordination. These internal structures, still rare in France, are an asset for CRA compliance. An operational OSPO provides an up-to-date software inventory and established vulnerability reporting processes.
Companies without an equivalent structure will need to build these processes from scratch before December 2027. The organizational cost far exceeds the technical cost.
Strategic acquisitions: Nvidia, Hugging Face, and the question of openness
Nvidia’s acquisition of Hugging Face for $12.93 billion represents the most significant capital movement of the year in the open source ecosystem. Nvidia claims it wants to preserve the openness of the platform to various models, clouds, and accelerators.
This promise deserves technical scrutiny. Hugging Face hosts models trained on various architectures (Nvidia GPUs, AMD, TPU accelerators). The platform’s hardware neutrality is its main asset. If Nvidia favored its own accelerators in model ranking or inference tools, the community would quickly migrate away.
AWS has also announced the acquisition of DuckLabs, with a similar commitment to preserving the open source model. These operations follow a recurring pattern: acquiring a high-traction community project, promising openness, and then gradually monetizing through managed services. The question is not whether openness will be maintained, but what exact scope will remain under a free license.
Security of open source projects and software supply chain
Securing the open source software supply chain is becoming a central issue as open weight models spread without systematic verification. The points of attention for maintainers are as follows:
- Verify the cryptographic provenance of artifacts published on registries (npm, PyPI, crates.io) to ensure that a package has not been altered between compilation and distribution
- Maintain an up-to-date SBOM for each release, including transitive dependencies often overlooked in manual audits
- Integrate security scoring tools (like Scorecard) into CI/CD pipelines to detect security posture regressions before publication
Open source compliance is becoming a market in its own right, with dedicated solutions emerging to meet the growing demands of regulated sectors.
Open governance and sustainability of community projects
The open governance model, where technical decisions are made by a committee elected by contributors, remains the exception rather than the norm. The majority of critical open source projects still depend on one or two main maintainers without a formalized governance structure.
The sustainability of package registries poses a structural problem. These infrastructures (npm, PyPI, Maven Central) function as public services for software development, but their funding largely relies on voluntary support from companies. Without sustainable commitment from industrial players, the risk of degradation of these registries increases as the number of published packages grows.
The European regulatory framework, acquisition movements, and the gradual structuring of security converge on the same observation: open source is entering a phase where governance, compliance, and funding matter as much as the code itself. Organizations that have not yet formalized their open source policy have just over a year before the CRA deadline.
