Mikaël Barbero is Head of Security at the Eclipse Foundation, where he leads the security team in building best practices and programmes that help protect the Foundation’s members and the open-source projects it governs.
The Eclipse Foundation is a Brussels-based open-source software foundation and one of the largest in the world. It hosts more than 400 projects across software-defined vehicles, AI, Cloud and Edge computing, embedded systems, IoT, and RISC-V hardware cores. It is also known to developers for widely adopting technologies such as the Open VSX Registry, Jakarta EE, Adoptium, and the Eclipse IDE.
In this Q&A, Barbero looks at how AI is reshaping the cybersecurity landscape for open source, and what the EU Cyber Resilience Act (CRA) means for organisations now that its first obligations are live. He covers where responsibility sits between manufacturers and open-source communities, the 11th September reporting deadline, AI-generated code, and how organisations can prepare for the evolving regulatory environment.
Individual developers and unmonetized projects sit outside CRA scope, with the burden falling on manufacturers. Has that boundary held up in practice?
The boundary has held, but applying it has required clarification. The Commission’s guidance continues to protect contributions to open source and software supplied outside commercial activity.
Crucially, a manufacturer incorporating an open source component into a commercial product does not transfer its responsibility for that product upstream.
So the principle remains sound. We are still early in implementation, and the real test will be whether commercial users support the communities they depend on sufficiently to make it work.
Is AI currently doing more to help defenders or attackers in open source?
In our own work, AI is already delivering meaningful benefits to defenders. Across open source as a whole, I would be cautious about declaring a winner.
At the Eclipse Foundation, our participation in Project Glasswing has shown that AI can uncover credible vulnerabilities that would be difficult to find manually.
Attackers are benefiting too … For open source, the bottleneck is increasingly the capacity to act on findings. Even a correct report needs someone to reproduce the issue, assess its impact, review a fix, and coordinate a release.
My view is that AI gives defenders a substantial opportunity, provided we invest in remediation as seriously as discovery.
What does the 11th September 2026 reporting deadline mean, in practical terms, for open-source projects and the CRA’s “software stewards”?
We need to distinguish two dates. Manufacturers’ reporting obligations began on 11th September 2026. The Commission explicitly states that open source software stewards’ reporting obligations under Article 24(3) apply from 11 December 2027.
Correspondingly, open source projects aiming for commercial adoption must explicitly establish their terms of engagement by publishing reporting channels, designated contacts, accurate version tracking, and clear processes for coordinated disclosure and fix management.
Now that the first obligations are live, is the “new relationship” you predicted between foundations and manufacturers actually happening?
Yes, there is concrete evidence that it is taking shape, although it is too early to judge the effects of obligations that have only just started applying.
The work has become much more operational. Through the Open Regulatory Compliance Working Group, we are developing shared implementation resources and training.
The OCCTET toolkit is another example. Released in September, it gives SMEs and open-source projects practical tools to assess readiness, identify dependencies, manage vulnerabilities, and document decisions.
The new relationship is beginning. Its success will depend on whether the organisations that benefit commercially from open source also help sustain the people and processes that keep it secure.
What gap in existing guidance was the ORC Learning Hub designed to close, and what has the response been so far?
As we approached the first CRA deadline, a lot of information became available, but one of the gaps ORC aimed to fill was practical guidance that speaks to the different roles open source plays in the software supply chain.
We started with two modules for different audiences … So far we have had hundreds of participants and expect even more participation when we launch our next module focused on SBOMs and vulnerability management.
What was the thinking behind the Eclipse Foundation-OWASP MoU, and how does it differ from what ORC already does?
The agreement combines the Eclipse Foundation’s expertise in open source governance, industry collaboration, and regulatory readiness with OWASP’s globally recognised security projects, standards, education, and community.
The MoU builds on that existing relationship, bringing closer collaboration to strengthen the work ORC is doing, rather than duplicating it.
Does the CRA adequately account for AI-assisted or AI-generated code, or is that an open question?
I think the CRA provides a sound baseline, although the engineering practices needed to apply it are still evolving. Its requirements focus on product risks, secure development, and vulnerability handling. My reading is that those responsibilities apply regardless of whether a developer wrote the code manually or used an AI assistant.
AI changes the development process. As code generation gets faster, review and testing need to keep pace. I would expect teams to verify suggested dependencies, examine security assumptions, test failure cases, and ensure that someone understands and takes responsibility for each contribution they accept.
We should also distinguish AI-generated code from a product that incorporates an AI model. The latter introduces additional concerns, such as model integrity, data poisoning, and how untrusted inputs affect behaviour.
What’s the biggest misconception about what CRA compliance requires of organisations using open-source AI components vs what it requires of upstream projects?
The misconception I would most like to correct is that compliance is something you can inherit from an upstream project.
If you are the manufacturer of a product within CRA scope, you are responsible for the security of that product, including how you integrate its dependencies … An upstream project cannot perform your product-specific assessment for you.
For AI components, I would encourage manufacturers to understand which model and software versions they use, where those components came from, and how their integration affects security.
How do you expect the regulatory environment for AI and cybersecurity to evolve, and what should organisations do now to stay ahead?
I expect closer coordination between AI governance, product security and organisational cybersecurity, with more attention to evidence that security processes work throughout a product’s life.
For manufacturers, the CRA’s broader requirements apply from 11th December 2027. The AI Act has its own phased timetable, which organisations need to assess against their particular products and roles.
Organisations should now build a current inventory of software and AI components, assign clear ownership for security decisions, retain evidence from reviews and testing, and rehearse vulnerability response. They should also participate in standards work and establish relationships with critical upstream projects.
Is there anything else you would like to add?
I would emphasise that open source security depends on sustained investment in people. AI can accelerate development and vulnerability discovery, but every useful finding still creates work: understanding the issue, validating a fix, coordinating a release, and helping users update.
For a company whose products depend on open source, supporting that work should be part of the product’s security budget.
I would judge success by whether maintainers have more capacity, manufacturers better understand their dependencies, and users receive secure products and timely updates.
