Open source and the Cyber Resilience Act: managing responsibilities

Who is legally responsible for a vulnerability in a library downloaded from a public repository, maintained for free by a volunteer contributor, when that library ends up at the heart of a CE-marked commercial product? With the Cyber Resilience Act, this question stops being theoretical and becomes a risk management problem for every European CTO.

Open source technologies are used by 90% of organizations worldwide, according to the Linux Foundation¹. This is not a marginal detail: a 2022 study by the Linux Foundation itself estimates that 70-90% of any modern codebase is composed of free and open source components.² Similarly, the 2024 Synopsys report indicates that 96% of commercial codebases contain open source software and 77% of all code in those same examined codebases originated from open source code.³

In other words: for the most part, companies did not write the software they sell.

This is where the central tension of the Cyber Resilience Act (CRA) arises: the European regulation introduces legal responsibilities for products built largely on components that, formally, no one “owns”. When you integrate dozens of libraries into a commercial product, who is responsible for the vulnerability? The answer is no longer obvious.

In this article, we clarify what changes for those who use and contribute to open source, which risks concretely fall on the company, and how to structure a software supply chain governance compliant with the CRA, without stopping to benefit from the competitive advantage that open source code guarantees.

What is meant by open source and is software really free?

Open source is software whose source code is publicly accessible, modifiable, and redistributable according to licenses approved by the Open Source Initiative (OSI). But free accessibility of the code does not mean zero cost: the cost shifts to integration, maintenance, security, and compliance. Those who confuse “free” with “at no cost” underestimate the very items that the CRA now makes mandatory.

The distinction between terms matters more than it seems. Free software, in the sense of the Free Software Foundation (FSF) founded by Richard Stallman, focuses on user freedoms and adopts copyleft licenses like the GNU General Public License (GPL), which obliges the redistribution of derivative works under the same conditions. Open source, promoted by the OSI, also allows for more permissive licenses oriented toward commercial adoption. Proprietary software, on the other hand, closes the code and transfers operational responsibility to the vendor, at the price of vendor lock-in.

The pervasiveness of open source in companies is concrete and daily, well beyond technical environments:

• Open source ERP and CRM systems that manage core business processes (with solutions like Odoo or Dolibarr ERP CRM challenging traditional vendors).

• Open source intranet applications for internal collaboration and document management.

• Open source IT auditing software for continuous security monitoring and compliance.

• Office application suites as alternatives to proprietary platforms, such as the historic Apache OpenOffice and LibreOffice, or the new Euro-Office launched in June 2026.

• Open source software for financial management (e.g., Money Manager Ex) and flexible e-commerce platforms.

Beneath this application surface operates an entirely open infrastructure: Linux as the server operating system, Kubernetes for container orchestration under the aegis of the Cloud Native Computing Foundation, Apache Kafka for data streaming, Ansible for automation. The vision of open source as a public good and a lever for sovereignty, which at SparkFabrik we consider the foundation of our software development, stems precisely from recognizing that this invisible layer supports the entire digital economy.

Open source, free software, or proprietary: a comparison table

The strategic takeaway is clear: open source reduces vendor lock-in but redistributes operational and security responsibility to the user. It is exactly this shift that the CRA formalizes on a legal level.

How the Cyber Resilience Act redistributes responsibilities for open source

The CRA introduces the figure of the open source steward and transfers security obligations to those who place products on the market, not to those who develop code collaboratively. However, the original wording of the regulation did not draw this line clearly, risking involving even upstream contributors in responsibilities they could not reasonably sustain.

The legal crux was effectively illustrated by Mirko Boehm of Linux Foundation Europe: the CRA, in its first version, did not distinguish between upstream collaborative development and placing a product on the market, and did not limit responsibility to the intended use. A volunteer contributor could have been held liable for vulnerabilities even in completely unforeseen use scenarios, such as the paradoxical case of a code fragment ending up controlling a nuclear power plant. It is the type of risk that alarmed the entire community, a debate that we reconstructed by analyzing the concerns of the open source world.

Why can’t foundations simply absorb these obligations? For a well-documented economic reason. Many open source projects receive no funding and, even by distributing available funds equally across all projects, it would amount to little more than $250,000 each: a figure that is perhaps enough to pay a community manager and organize a few meetups, but certainly not to maintain full-time security personnel.⁴ Furthermore, as Linux Foundation Europe clarifies, those funds arrive tied to specific projects by donors (donor-directed funds), to the point that not even the foundation itself could divert them to solve the security problems of another project; and other open source foundations often have even more limited resources.

Loading open source maintainers with the security-by-design obligations of the CRA⁵, at a stage where the long-term sustainability of many projects is already being questioned by the contributors themselves, risks proving counterproductive.

The response was the #FixTheCRA initiative, coordinated by Linux Foundation Europe on five fronts: proposing amendments through Open Forum Europe, disseminating critical issues, an open letter signed by a coalition of open source foundations, roundtables with European institutions (with panels at KubeCon Europe and the Open Source Summit), and the creation of permanent collaboration venues. SparkFabrik participates in this ecosystem as a member of Linux Foundation Europe and OpenSSF⁶, and our CTO Paolo Mainardi sits on the LF Europe Advisory Board.

Who is responsible for vulnerabilities: upstream, steward, or manufacturer?

The CRA distinguishes three roles with different responsibilities:

• Upstream contributor: develops code collaboratively, outside of commercial logic. They are excluded from the direct obligations of the regulation.

• Open source steward: a new figure introduced by the CRA, with reduced and proportionate obligations (typically foundations and organizations that support projects).

• Commercial manufacturer: the one who places the product on the market with the CE marking. They assume full legal responsibility for security.

The takeaway for the decision-maker is direct: if your company integrates open source into a commercial product, the legal responsibility falls on you, not on the upstream project. The CE marking certifies that you are the one guaranteeing the compliance of the entire stack, dependencies included.

What risks do European companies building on open source face?

There are three main risks: the increase in compliance costs borne especially by SMEs, the possible withdrawal of software from the EU market by communities, and the impact on European digital sovereignty initiatives. These are risks that hit asymmetrically those who use open source to compete.

Analyzed by level, the risks are structured as follows:

• Economic risk: the CRA could impose additional costs on the use of and contributions to open source, primarily borne by European companies, penalizing SMEs that base their ability to compete with large incumbents on open innovation.

• Supply chain continuity risk: communities might refuse to make software available in the EU, leaving distribution to non-EU commercial intermediaries, impacting Gaia-X⁷, SovereignEdge⁸, and Next Generation Internet⁹.

• Strategic risk: the CRA’s critical product classes coincide with fundamental open source technologies.

This third point deserves attention because it contains a paradox. Class II of the CRA, subject to some of the strictest security requirements, includes server operating systems, hypervisors, and container runtimes: exactly the open technologies that support the European cloud infrastructure. We explored this tension between regulation and competitiveness in the analysis of how the CRA affects the strategic autonomy of the Union.

The paradox deepens on the sovereign cloud front. Offerings like AWS European Sovereign Cloud, Google S3NS, and the Bleu project present themselves as European but remain architecturally controlled by non-European hyperscalers¹⁰. In this framework, open source, and not the “sovereign” label applied to proprietary technologies, remains the real lever of technological independence for the continent’s organizations. For a European CTO, this means prioritizing stacks based on verifiable open source technologies in their cloud procurement strategy.

How to manage open source responsibilities in compliance with the CRA

Managing responsibilities means moving from passive consumption of open source to structured governance: dependency inventory, security-by-design, active contribution to projects, and documentary transparency toward the market. It is not a bureaucratic fulfillment, but a change in how the company conceives its software supply chain.

The first pillar is supply chain governance. Total visibility of dependencies is needed, including transitive ones that no one consciously selected. In this area, our experience is direct: SparkFabrik is the maintainer of DruBOM, a Drupal module that integrates Anchore Syft to generate the complete Software Bill of Materials of an installation, including PHP and JavaScript dependencies. It is the same approach we described when talking about how to map dependency risks for CE marking.

The second pillar is methodological. Software development compliant with the CRA requires security controls integrated from the early stages, not added later. At SparkFabrik, we practice a principle of security enablement over enforcement: security is not a gate imposed downstream by compliance teams, but a capability placed in the hands of developers, who become conscious actors in the product’s security posture.

The third pillar is cultural: moving from users to contributors. Sachiko Muto, in the context of Drupal4GovEU, argued that institutions must participate in open projects by contributing their own developers, not just by funding them¹¹. It is the same philosophy summarized by Paolo Mainardi, CTO of SparkFabrik¹²:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Contributing actively reduces strategic risk and strengthens the sustainability of the projects the company depends on.

In operational terms, the high-level path is divided into five steps:

1. Map all dependencies, direct and transitive, with composition analysis tools.
2. Classify products by risk class according to the CRA scope.
3. Integrate security controls into the development cycle, from a DevSecOps perspective.
4. Define update and vulnerability disclosure policies.
5. Contribute upstream to projects critical to your business.

It is worth noting that openness does not only concern traditional infrastructure but extends to the dual relationship between open source and artificial intelligence. On one hand, AI allows for managing open projects on an unprecedented scale, allowing a single developer to quickly reach the productivity of an entire team; on the other, open source accelerates the progress of AI itself through shared models and frameworks. 72% of developers, according to the 2024 Stack Overflow survey, declare a favorable position toward the use of AI tools in their workflow¹³. Integrating these new generative components into your commercial products means inheriting further dependencies: the governance you build today must also withstand this complexity, ensuring that AI adoption respects the same traceability and security obligations imposed by the CRA.

From passive dependency to open source governance

The CRA is not a threat to open source, but an accelerator toward a mature management of software supply chain responsibilities. The regulation formalizes on a legal level a truth that technical teams have known for a long time: whoever sells a product is entirely responsible for it, including the parts inherited from open source code.

Companies that structure open source governance today, with dependency inventory, security integrated by design, and active contribution to the projects they depend on, transform a regulatory obligation into a competitive advantage and a concrete lever for digital sovereignty. It is the difference between suffering compliance and using it as a quality accelerator.

In the next article in the series, we will address how to manage the complexity of multiple Software Bills of Materials in large, multi-service projects, between SPDX and CycloneDX formats and the automation of transitive dependencies.

If you want to evaluate the maturity of your open source supply chain and plan for regulatory compliance, our support path on the Cyber Resilience Act provides the experience of a KCSP team, member of CNCF, Linux Foundation Europe, and OpenSSF. Contact us and tell us about your challenges.

Notes and sources