Designing responsibility in the software supply chain
The first question addressed by the panel was where responsibility ultimately lies when software products rely heavily on open-source components: with the manufacturer, the open-source project, the integrator, or the distributor?
Roman Zhukov argued that responsibility follows economic value. “The entity that extracts revenue or the ultimate value is liable,” he explained. Manufacturers may depend on suppliers, but they remain responsible for conducting due diligence and maintaining formal relationships. Open-source maintainers, however, are under no obligation to support commercial users. This makes collaboration essential. Manufacturers benefit from open source and should actively support the projects they rely on.
Building on this point, Maxim Baele noted that the CRA could strengthen the relationship between manufacturers and the open-source community. Rather than maintaining isolated forks of software, organisations are encouraged to contribute improvements upstream. “By supporting communication between manufacturers and maintainers, the CRA transforms what could be seen as a regulatory burden into a catalyst for collaborative support and healthier upstream contributions.”
The discussion then turned to the legal definition of a manufacturer. Lara Brito cautioned that organisations can unexpectedly fall within scope depending on their economic relationship with software. She recommended consulting the European Commission’s draft guidance, particularly for open-source projects and non-profits. “If you are a non-profit, ensure your accountant can prove that every bit of money received is for personal costs or reasonable expenses.”
Pedro Demolder reinforced the central role of manufacturers within the CRA framework. “The manufacturer is the sun at the centre of the system,” he said. Manufacturers bear the primary obligations and serve as the main gateway for products entering the market. Other actors, such as distributors, have responsibilities that flow from the manufacturer’s role.
Demolder also stressed that open source is treated as a legal classification rather than a general concept. Broadly speaking, software falls into three categories: commercial software, non-commercial software maintained by open-source stewards, and freely available non-commercial software. The boundary between commercial activity and legitimate cost recovery remains unclear, meaning organisations, particularly non-profits, must be able to demonstrate that any revenue only covers reasonable expenses if they wish to avoid being classified as commercial manufacturers.
The role and limitations of SBOMs
The conversation then shifted to Software Bills of Materials (SBOMs) and their role in demonstrating compliance.
Nessim Kisserli described the SBOM as an important starting point, but not the end goal. “The CRA requires you to develop secure software demonstrably,” he explained. An SBOM provides a list of software components, enabling organisations to identify known vulnerabilities and assess whether they are relevant and impactful.
Maxim Baele agreed that SBOMs are valuable but emphasised that they represent only one piece of the puzzle. “The SBOM is an artifact. It proves that you have an idea what is in your software. But I’d look at other artifacts as well.”
For Lara Brito, the key challenge is maintaining accuracy over time. Software changes constantly, and organisations must be able to demonstrate which versions of which components are present in every product release. In that sense, the SBOM becomes evidence of due diligence.
Roman Zhukov observed that historically, SBOMs have often been generated as paperwork rather than operational tools that are used effectively. The CRA creates an opportunity to change that. Adding metadata, such as information about component origins, can make SBOMs far more useful for managing security risks instead of simply satisfying compliance requirements.
Managing open-source vulnerabilities
The discussion then moved to one of the most practical challenges facing manufacturers: deciding what to do when vulnerabilities are discovered in open-source components. The moderator posed a straightforward question: should organisations patch, fork, replace, or accept risk for a vulnerable open-source dependency?
Nessim Kisserli framed the issue as a risk-based decision. “The CRA doesn’t aim to produce work for the sake of work; it aims for secure products.” If an organisation can demonstrate that a vulnerability presents no meaningful risk, patching may not always be necessary, he continued. However, he warned that forking should generally be viewed as a last resort. Once a company maintains its own fork, it effectively assumes responsibility for that software and the associated CRA obligations.
Pedro Demolder took a stricter regulatory view. Referring to European Commission guidance, he argued that “As the manufacturer, you cannot simply place a vulnerable product on the market and say you accept the risk.” Manufacturers must meet a regulatory standard, regardless of whether upstream maintainers provide support.
Lara Brito suggested reframing the discussion. Rather than talking about risk acceptance, organisations should focus on risk treatment. “The authorities want to see your logic: how you thought about the risk and why you treated it a certain way.” Risk treatment can include mitigation measures, user communication, or other documented actions. What matters is demonstrating a structured decision-making process that considers both intended use and foreseeable misuse.
Picture 1 – Nessim Kisserli & Roman Zhukov
Picture 2 – Roman Zhukov – Maxim Baele – Lara Brito – Pedro Demolder
