Posts Tagged ‘security’
Frontier AI and the next phase of software vulnerability defence
As advanced AI lowers the cost of discovering and exploiting software vulnerabilities, Europe must treat open source security and rapid patch deployment as critical resilience infrastructure
Context. Frontier AI systems have crossed an important threshold for cybersecurity and software resilience. They are no longer limited to code completion, triage, or report writing; the most capable models can now assist with vulnerability discovery, exploitability analysis, and, increasingly, patch generation. Anthropic’s Project Glasswing, launched on April 7, 2026, put this shift in the public eye by giving selected critical software operators and maintainers early access to Claude Mythos Preview for defensive security work. Anthropic described Glasswing as an initiative to secure critical software with early access to frontier AI, involving major infrastructure, cloud, financial, and open source actors, and extending access to more than 40 organisations that build or maintain critical software infrastructure. Through our longstanding partnership with the Alpha Omega Project, the Eclipse Foundation has been part of the Glasswing Project since its inception, giving us direct experience with this emerging model of AI-assisted vulnerability discovery. To our knowledge, we are currently the only EU-domiciled organisation participating in the initiative, giving us a unique vantage point on how frontier AI capabilities are beginning to reshape software security and resilience.
Why this matters now. The capability jump appears not to be limited to one model, one vendor, or ecosystem. The UK AI Security Institute found that Claude Mythos Preview represented a step-change in cyber performance, including autonomous progress on multi-step attack simulations and high success on expert-level cyber tasks. Less than three weeks later, AISI reported that OpenAI GPT-5.5 reached a similar level of performance on its cyber evaluations and was the second model to complete one of AISI’s multi-step cyber-attack simulations end-to-end. Open-weight models are also narrowing the gap: CAISI’s May 2026 evaluation described DeepSeek V4 Pro as the most capable Chinese model it had evaluated across cyber, software engineering, science, reasoning, and mathematics, while still lagging the leading U.S. frontier by roughly eight months. The implication is that capabilities currently concentrated among a small number of frontier AI providers will quickly become cheaper, more widely available, and harder to govern. This makes early institutional experience with frontier defensive AI workflows strategically important.
The immediate risk: a vulnerability and patching imbalance. Critical infrastructure operators, including energy, transportation, water, health, public services, and financial services, are especially exposed because many run complex, legacy, opaque software estates where patching is slow, cautious, and operationally disruptive. This is not a hypothetical concern: the US Government’s GAO’s 2025 review of critical federal legacy systems found outdated languages, unsupported hardware or software, and known cybersecurity vulnerabilities in systems supporting missions such as critical infrastructure, tax processing, and national security. CISA similarly warns that outdated software is a gateway for threat actors in critical infrastructure contexts, including public-facing routers, VPNs, and firewalls used to reach operational systems. NCSC now expects a “vulnerability patch wave”: a rush of software updates across open source and commercial software stacks as AI accelerates discovery of long-standing technical debt.
The systemic threat. AI-assisted vulnerability discovery changes the economics of offense. It lowers the time, expertise, and cost needed to find flaws, validate exploitability, and turn known-but-unpatched vulnerabilities into working attacks. This is particularly dangerous where many institutions depend on the same software, libraries, cloud providers, identity systems, network appliances, or open source software components. For decades, many IT and operational technology environments have treated patching as an operational disruption to be minimized, especially when systems appear to be running correctly. In some cases, this caution is understandable: outages can have safety, economic, regulatory, and reputational consequences. But the balance of risk is changing. When AI can accelerate vulnerability discovery and exploitation, “stable but unpatched” systems can quickly become systematically exposed. Changing this culture and making rapid, well-tested patch deployment a core resilience function may be one of the hardest short-term challenges. The most serious concern is the possibility that threat actors will use AI to discover and exploit “zero day” vulnerabilities before patches are available. The IMF warned on May 7, 2026 that advanced AI models can reduce the time and cost of identifying and exploiting vulnerabilities, increasing the likelihood of correlated failures across widely used systems; it specifically identified financial intermediation, payments, and confidence as systemic risk channels. The same concern applies to cross-sector dependencies among finance, energy, telecommunications, public services, and digital infrastructure.
The Eclipse Foundation’s key finding. Our most important finding from the one-month experiment with Mythos was that operational workflows, validation pipelines, and human oversight matter at least as much as the model. Glasswing’s real significance is not simply that one frontier model found more vulnerabilities. It is that a community of security researchers can iteratively improve prompts, agentic harnesses, target selection methods, reproduction pipelines, and triage workflows, and then apply those methods across multiple market-available models, including cheaper and more widely accessible ones. Anthropic’s own technical write-up reinforces this point: its vulnerability work used agentic scaffolds, containers, target ranking, repeated runs, and validation methods rather than a bare chatbot prompt. NCSC likewise stresses that practical AI cyber capability comes from AI systems—models combined with tools, workflows, and human oversight—not from raw model capability alone.
The opportunity: shared defence capacity at machine speed. The same tools that raise offensive risk can strengthen defense if deployed first and responsibly. AI can continuously scan code and dependencies, generate fuzzing harnesses, prioritize findings by exploitability and exposure, propose patches, produce regression tests, summarize impact for maintainers, and accelerate coordinated vulnerability disclosure. NCSC identifies three high-value defensive uses: reducing attack surface through AI-enabled testing and hardening, improving detection and investigation, and automating mitigation and response where carefully governed. The strategic objective should be to convert AI-driven discovery into AI-assisted remediation faster than adversaries can convert discovery into exploitation. Organisations that are not using AI to strengthen threat detection, prevention, and mitigation risk being outpaced by AI-enabled attackers.
What Europe should do now. Europe should treat AI-enabled open source security as shared digital resilience infrastructure. That means investing in trusted vulnerability discovery, coordinated disclosure, maintainer support, patch validation, and deployment readiness across the software components that underpin critical services. No single vendor, foundation, institution, or member state can solve this alone; it requires an ecosystem response. Europe should also ensure that trusted public institutions and open source ecosystems remain directly involved in frontier AI cybersecurity evaluation and remediation efforts, rather than relying on commercial actors outside Europe.
Open source is not the problem; it is the solution. The risk does not come from open source. It comes from the fact that many organisations depend on software they do not fully understand, cannot fully inventory, and cannot patch quickly enough. Open source makes that dependency visible, auditable, and repairable. Open source governance structures may become increasingly important in AI-enabled remediation ecosystems because their transparency, global maintainer communities, reproducible builds, public issue tracking, coordinated disclosure practices, and shared security tooling make them uniquely capable of operating at ecosystem scale. CISA’s Open Source Software Security Roadmap explicitly recognizes OSS as a public good supported by diverse communities and calls for supporting critical OSS components relied on by government and critical infrastructure. Furthermore, AI is enabling increasingly sophisticated reverse engineering tools that can generate source code from proprietary binaries, making “security through obfuscation” an implausible strategy.
Conclusion. This is a global software resilience issue, with direct implications for Europe’s security, digital sovereignty, and strategic autonomy. Critical infrastructure and financial services everywhere rely on globally developed open source components, shared platforms, and common supply chains. Local champions will matter, but isolated national responses will not be sufficient. The priority is coordinated action: shared AI-enabled vulnerability discovery, trusted disclosure channels, maintainer support, rapid patch production, dependency intelligence, and deployment capacity across public and private sectors. Ultimately, resilience will depend not only on AI capability itself, but on trusted ecosystems capable of coordinating remediation rapidly across shared infrastructure. The Eclipse Foundation will work with public institutions, industry, and open source communities to help strengthen these shared resilience capabilities across the European software ecosystem. Ultimately, resilience will depend not only on AI capability itself, but on trusted ecosystems capable of coordinating remediation rapidly across shared infrastructure. Open source should be treated not as the weak link, but as the coordination layer through which Europe and its global partners can find, fix, validate, and deploy security improvements at the speed modern resilience now requires.
The Cyber Resilience Act is Here
With the recent publication of the EU’s Cyber Resilience Act (CRA) in the EU official journal, a 3 year race now begins for compliance by the global technology industry. This legislation sets new cybersecurity requirements that manufacturers and the open source projects they rely upon must meet. The open source community via the Open Regulatory Compliance (ORC) Working Group, is working with numerous open source foundations, SMEs, and industry to establish processes to comply with this new regulatory landscape.
The Race to Compliance
The CRA defines clear targets and timelines, marking the start of a sustained compliance journey. This effort will require time, energy, and resources and the ORC Working Group is here to support the open source ecosystem. Our mission is to guide open source participants and adopters in aligning with CRA requirements through practical frameworks and expertise to support their regulatory journey from start to finish.
How the ORC Working Group Supports Open Source Compliance
The many foundations and other stakeholders which are members of the ORC Working Group are dedicated to guiding the open source community toward successful CRA compliance. Through active community engagement, we’re creating practical resources and adaptable frameworks that empower projects to meet regulatory standards, while preserving open source values. As a community, we have identified the following 4 pillars to guide this effort:
- Bridging the Knowledge Gap: The ORC Working Group prioritises education and training to empower the community with tools to adopt compliant development practices. By creating resources, like cyber resilience guidelines for example, and continuously updating them to align with emerging regulations, we simplify CRA compliance for open source maintainers, projects, communities, and foundations.
- Establishing Compliance Frameworks: We’re defining best practices, processes, and tools that can be translated into specifications addressing regulatory needs. These frameworks prioritise security and compliance for open source projects. Additionally, we will work with standardisation bodies to ensure that open source perspectives help shape global regulatory standards.
- Institutional Engagement: Collaboration with regulatory authorities is central to effective compliance. The ORC Working Group is committed to engaging with these institutions, gathering feedback, and supporting the adoption of community-driven compliance frameworks. This ensures our work aligns with both industry standards and regulatory expectations.
- Strengthening Community Support: Community engagement drives this effort. Through events, workshops, and comprehensive documentation, we keep members informed and prepared for CRA compliance. In the coming months, the ORC will launch additional guidance initiatives to ensure that the open source community is supported every step of the way.
Ultimately, the CRA provides the community and industry an opportunity to deliver more secure products while making open source more sustainable. It will be a new challenge for our community. However, by working together on practices and standards to facilitate compliance we will achieve its laudable goal: making the digital products that are so prevalent in our lives more secure.
Join the Effort
Joining ORC is your opportunity to contribute directly to a compliance strategy that not only upholds cybersecurity requirements but also supports ongoing open source innovation. Early involvement with the ORC Working Group offers a chance to contribute to the foundational compliance framework that will guide our community and influence how standards are implemented industry-wide. Join us in shaping how the CRA is implemented to set the open source community up for success under these new regulations.
Securing the Future of Open Source: Launching the Open Regulatory Compliance Working Group
Today marks an important milestone for the open source community. As open source software continues to drive innovation across industries, ensuring its relevance and compliance with emerging regulations has never been more critical.
To address these challenges, the Eclipse Foundation is proud to announce the formal launch of the Open Regulatory Compliance (ORC) Working Group. This initiative is designed to ensure that open source remains a powerful force for innovation while meeting the increasingly complex regulatory requirements that commercial organisations face globally.
As previously announced, this initiative has garnered the support of the world’s open source foundations, including Apache Software Foundation, Blender Foundation, FreeBSD Foundation, Matrix.org Foundation, NLnet Labs, OpenInfra Foundation, OWASP, PHP Foundation, Python Software Foundation, Ruby Central, and Rust Foundation. We also have the support of numerous civil society organisations, industry organisations, and SMEs including CodeDay, iJUG, Obeo, Open Elements, OpenForum Europe, Open Source Initiative, Payara Services, Scanoss, and Software Heritage. Today we are also announcing that we have the support of European industry heavyweights Bosch, Mercedes-Benz, Nokia, and Siemens.
This diverse collaboration highlights the industry’s shared commitment to navigating regulatory changes together and ensuring that open source continues to thrive as a pillar of modern technology.
Securing the Future of Open Source Innovation
In an era where businesses rely on open source for mission-critical applications, the ORC Working Group is essential to maintaining the competitive advantage that comes from using and contributing to open source software. As regulations evolve, commercial organisations need a clear path to stay compliant while continuing to innovate. The ORC Working Group addresses this need by helping to formalise industry-aligned best practices, helping companies leverage the full potential of open source without the risk of falling behind on new regulations.
Immediate Focus: The European Cyber Resilience Act
Open source is a cornerstone of global digital innovation, and Europe’s regulatory landscape is playing a pivotal role in shaping its future. The ORC Working Group is committed to ensuring that open source remains a vital part of the world economy, and complying with the EU’s Cyber Resilience Act (CRA) is a critical part of this. Through collaboration with European institutions, the working group is working to facilitate compliance with the CRA and similar regulations, helping businesses and developers alike stay ahead of the curve.
Keeping Innovation Compliant and Secure
With the Cyber Resilience Act as a primary focus, the ORC Working Group is looking to make progress in developing cybersecurity process specifications and best practices to support compliance. Liaison status with the European Committee for Standardization (CEN) and the European Committee for Electrotechnical Standardization (CENELEC) further strengthens the working group.
Get Involved: Shaping the Future of Open Source Compliance
As the open source ecosystem faces unprecedented regulatory challenges, now is the time for all stakeholders — developers, companies, foundations, and regulatory bodies — to come together and ensure that open source innovation remains sustainable and compliant. The Open Regulatory Compliance (ORC) Working Group offers a unique opportunity to actively shape the future of open source by helping define the standards and best practices that will keep it relevant and competitive in the face of evolving global regulations.
We invite anyone involved in the open source community — whether you’re a developer, legal expert, corporate leader, or part of a standards organisation — to join this critical effort. Your participation will not only help safeguard the future of open source, but also ensure that your organisation stays ahead of the regulatory curve.Join the ORC Working Group and the ORC mailing list today to help define the future of open source compliance.
The Open Source Community is Building Cybersecurity Processes for CRA Compliance
tl;dr – Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation, and Eclipse Foundation are jointly announcing our intention to collaborate on the establishment of common specifications for secure software development based on existing open source best practices.
In an effort to meet the real challenges of cybersecurity in the open source ecosystem, and to demonstrate full cooperation with, and to support the implementation of, the European Union’s Cyber Resilience Act (CRA), Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation, and Eclipse Foundation are announcing an initiative to establish common specifications for secure software development based on open source best practices.
This collaborative effort will be hosted at the Brussels-based Eclipse Foundation AISBL under the auspices of the Eclipse Foundation Specification Process and a new working group. As Europe’s largest open source foundation, which also supports a robust open specification process, the Eclipse Foundation is a natural home for this effort. Other code-hosting open source foundations, SMEs, industry players, and researchers are invited to join in as well. The starting point for this highly technical standardisation effort will be today’s existing security policies and procedures of the respective open source foundations, and similar documents describing best practices. The governance of the working group will follow the Eclipse Foundation’s usual member-led model but will be augmented by explicit representation from the open source community to ensure diversity and balance in decision-making. The deliverables will consist of one or more process specifications made available under a liberal specification copyright licence and a royalty-free patent licence.
The reasons for this collaboration extend beyond compliance. In an era where software, particularly open source software, plays an increasingly vital role in modern society, the need for reliability, safety, and security has steadily increased. New regulations, exemplified by the impending CRA, underscore the urgency for secure by design and robust supply chain security standards well before the new regulation comes into force in 2027.
While open source communities and foundations generally adhere to and have historically established industry best practices around security, their approaches often lack alignment and comprehensive documentation. The open source community and the broader software industry now share a common challenge: legislation has introduced an urgent need for cybersecurity process standards.
The CRA will lead to numerous standards requests from the Commission to the European Standards Organisations. And these are only the European requirements – additional demands from the US and other regions can be anticipated.
The CRA also creates a new type of economic actor – the “Open Source Software Steward”. It is in this context that we, as open source foundations, want to respond to the challenge of establishing common specifications for secure software development.
This challenge is compounded by the following:
- Today’s global software infrastructure is over 80% open source. The software stack that underpins any product with digital elements is typically built using open source software. As a result, it is fair to say that when we discuss the “software supply chain,” we are primarily, but not exclusively, referring to open source.
- Traditional standards organisations have had limited interactions with open source communities and the broader software/IT industry. To make matters more complicated, their governance models currently do not provide opportunities for open source communities to engage.
- Open source communities have a limited history of dealing with traditional standards organisations. To make matters more complicated, their resource constraints make it difficult for them to engage.
- Standards setting is typically a long process, and time is of the essence.
So while these new cybersecurity standards must be developed with the requirements of open source development processes and communities in mind, there is no clear path on how to do so in the time available. It is also important to note that it is similarly necessary that these standards be developed in a manner that also includes the requirements of proprietary software development, large enterprises, vertical industries, and small and medium enterprises.
Despite these challenges, a foundation for progress exists. The leading open source communities and foundations have for years developed and practised secure software development processes. These are processes that have often defined or set industry best practices around things such as coordinated disclosure, peer review, and release processes. These processes have been documented by each of these communities, albeit sometimes using different terminology and approaches. We hypothesise that the cybersecurity process technical documentation that already exists amongst the open source communities can provide a useful starting point for developing the cybersecurity processes required for regulatory compliance.
We hope that our specifications could inform the formal standardisation processes of at least one of the European Standards Organisations. Given the tight time horizon for implementation of the CRA, we believe that this immediate start will provide a constructive environment to host the technical discussions necessary for the stewards, contributors, and adopters of open source to meet the requirements set forth in these new regulations.
We invite you to join our collaborative effort to create specifications for secure open source development: Contribute your ideas and participate in the magic that unfolds when open source foundations, SMEs, industry leaders, and researchers combine forces to tackle big challenges. To stay updated on this initiative, sign up for our mailing list.
European Cyber Resilience Act: Potential Impact on the Eclipse Foundation
Europe has proposed new legislation intended to improve the state of cybersecurity for software and hardware products made available in Europe. The Cyber Resilience Act (“CRA”) will mandate that all manufacturers take security into account across both their development processes and the lifecycle of their products once in the hands of consumers.
This document discusses the legislation and the potential impact it may have on the Eclipse Foundation and its 400+ projects and community. Many of the issues noted could have a similar impact on other open source organizations and projects. It is written based on our reading of the current draft legislation and a number of assumptions stated below. Note that is consciously does not include a discussion of possible revisions to the legislation, although we may post a followup which does. It also does not include any discussion concerning the warranty and product liability provisions of the legislation as we have not yet analyzed the impact those may have on us.
We are sincerely looking for comments and feedback, as it is quite possible that we have misunderstood or misinterpreted the documents.
It is important to stress that the Eclipse Foundation is better positioned to deal with the fallout from the CRA than many other open source organizations. We have staff. We have some resources. We have common community processes and practices shared across our many projects. We have CI/CD infrastructure shared by most (but not all) of our projects. We have a security team, written security policies and procedures, and are a CVE numbering authority. Despite being in a better position than most, we fear that the obligations set forth by the legislation will cripple the Eclipse Foundation and its community.
There are a number of other excellent summaries of the worrisome impact of this legislation on the open source ecosystem. We highly recommend reading:
- Open-source software vs. the proposed Cyber Resilience Act by Maarten Aertsen.
- The EU’s Proposed Cyber Resilience Act Will Damage the Open Source Ecosystem by Olaf Kolkman.
Both of those articles primarily focus on the potential impact of the CRA on individual open source projects. Olaf’s document in particular suggests improvements to the draft. In this document we want to focus on the impact on an organization such as the Eclipse Foundation and its open source projects if the CRA was approved in its current form. How the CRA should or could be amended is being discussed elsewhere. The purpose of this document is to provide a resource explaining the impact of the legislation as it stands today.
It is important to note that the CRA does make a laudable attempt to carve out free and open source software but only “…outside the course of a commercial activity…”. Maarten Aertsen does an excellent job of summarizing the problems with this carve out. In particular he references a definition of commercial activity used in EU Blue guide to the implementation of EU product rules which states:
Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context.
Assumptions
- The CRA references the term “product” over 600 times but does not appear to define it. The act does define the term ‘product with digital elements’. For the purposes of this document we will assume that for the purposes of the CRA, any Eclipse Foundation project software made generally available to the public as a downloadable, installable, and executable binary would be considered a ‘product with digital elements’ under the regulation.
- In addition, there are at least some EF projects which may be considered ‘critical product with digital elements’ (e.g. Kura, Keyple, ioFog, fog05) or ‘highly critical product with digital elements’ (e.g. Oniro, Leda, 4diac) .
- The CRA defines ‘manufacturer’ as “any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge”. For the purposes of this document, we will assume that the Eclipse Foundation would be considered the manufacturer of the binaries produced by its projects. Among other reasons justifying this assumption, the Eclipse Foundation asserts that it owns the trademark rights for each of its projects and the binaries they release and (resources permitting) we market them as works of the Eclipse Foundation.
- As mentioned above there is an attempt to exclude free and open source software produced outside the course of a commercial activity from the scope of the legislation. For the purposes of this document we will assume that Eclipse Foundation project software would be considered as produced under the course of a commercial activity, and would therefore be subject to the legislation. This assumption is based on the following:
- The Eclipse Foundation is not a charity. It is a Belgian-incorporated international nonprofit association of hundreds of business members.
- Eclipse Foundation projects are not, generally speaking, developed by hobbyists. While some are, our projects are commonly developed by full-time employees of our member companies or by individuals who are making a living from consulting services related to their project work.
- Eclipse Foundation projects provide goods in a business related context. By that we mean that EF projects are largely intended to provide software which is immediately ready for adoption by businesses either as a component within a commercial product or by use by employees in their daily work.
- Eclipse Foundation projects provide a regularity of supply. As one extreme example, the Eclipse IDE takes great pride in having not missed a single release date in over 15 years.
- Eclipse Foundation projects deliver high quality software, equivalent to the quality found in commercial products. So the “characteristics of the product” are equivalent to commercial products.
Having said all of the above it is important to remind the reader that all Eclipse Foundation projects provide their software for free, on a non-profit basis, and under OSI-approved open source licenses which permit further use, study, modification, and distribution.
Impact Assessment
CE Markings for Software Products
Fundamentally, the core of the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe. Our assumption based on the current text is that this process will be applied to open source software made available under open source licenses and provided free of charge, ostensibly under licenses which disclaim any liability or warranty. We are deeply concerned that the CRA could fundamentally alter the social contract which underpins the entire open source ecosystem: open source software provided for free, for any purpose, which can be modified and further distributed for free, but without warranty or liability to the authors, contributors, or open source distributors. Legally altering this arrangement through legislation can reasonably be expected to cause unintended consequences to the innovation economy in Europe.
Without a clearer exemption for open source, in order to comply with the legislation the Eclipse Foundation will be required to:
- Develop, document, and implement policies and procedures for every project at the Eclipse Foundation to ensure they are conformant with the requirements of the CRA including:
- All of the development and post-release security requirements set forth in Annex I, including providing notification and update mechanisms.
- All of the user documentation requirements set forth in Annex II.
- All of the product technical documentation set forth in Annex V, including “…complete information on the design and development of the product…including, where applicable, drawings and schemes and/or a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing.”
- For each EF project release, prepare the project-specific documentation required by Annex V, including “…an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained…”.
- Determine for each project whether it meets the definition of ‘product with digital elements’, ‘critical product with digital elements’, or ‘highly critical product with digital elements’.
- For each project which is a ‘product with digital elements’, establish, complete, and document a CE mark self assessment process.
- For each ‘critical product with digital elements’ or ‘highly critical product with digital elements’ engage with an external CE auditing body and complete the additional processes required to get the CE mark approval. Note that it is not clear to us what the costs in time, resources, and money would be to implement these external audit processes. Our assumption is that they would be substantial.
It is also important to note that in most other domains regulated with CE markings they are done where there are well known standards, specifications, and/or certification processes in place. These are not in place for most Eclipse Foundation open source projects. This could significantly increase the costs and risks associated with conformance.
- For each single project release, document that the relevant CE mark process is followed (as described above), that an EU declaration of conformity is written and signed by an officer of the foundation, that the CE mark is affixed, and that the technical documentation and EU declaration of conformity is made available for at least 10 years after the release. Note that we estimate that in any given year the Eclipse Foundation’s projects make available several hundred releases.
Article 4(3)
Member States shall not prevent the making available of unfinished software which does not comply with this Regulation provided that the software is only made available for a limited period required for testing purposes and that a visible sign clearly indicates that it does not comply with this Regulation and will not be available on the market for purposes other than testing.
Many Eclipse Foundation projects make integration, nightly, weekly, and milestone builds available under their open source licenses available indefinitely. The intent is to provide for community testing and for traceability. These binaries are marked as such, but the terms under which they are provided do not require that they be used for testing purposes only.
It is not clear how this requirement could be implemented by any open source project using modern CI/CD infrastructure and operating under the principle of transparency. Even if the binaries were marked as “testing purposes only”, the open source licenses they are provided under do, in fact, permit uses other than testing. Further, it is common practice to provide intermediate builds for extended periods of time (often permanently) to provide testers with access to past builds for problem identification and remediation. Discontinuing that practice would be significantly disruptive. And any solution based on providing intermediate builds under non-open source licenses would be impossible for Eclipse Foundation projects, as the EF does not own the copyright and obtaining the approval of all contributors would be impractical. In summary, compliance with this CRA requirement would represent a significant blow to open source development best practices.
Article 5(1) and Section 1 of Annex I
(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks
At a minimum this would require the development and enforcement of written policies requiring every project to assess their level of cybersecurity risk and to implement processes to ensure that there is a determination of the risk level and a justification for the development processes adopted.
(2) Products with digital elements shall be delivered without any known exploitable vulnerabilities
(3) On the basis of the risk assessment referred to in Article 10(2) and where applicable, products with digital elements shall:
(a) …(j)
These would require a material change to our community’s release processes to require attestations that there are no known vulnerabilities and to comply with the many requirements listed.
(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users.
With a few exceptions, EF projects do not “call home”, require any sort of user registration, and do not provide a mechanism for notifying all users that an update is either available or required. Implementing these requirements would require a whole new infrastructure to be mandated across all projects.
Article 5(2) and Section 2 of Annex I “Vulnerability Handling Requirements”
In general, the Eclipse Foundation is in decent shape to deal with many of the stated requirements. As noted above we have a security team, written security policies and procedures, and are a CVE numbering authority. However, there are two notable elements in the requirements.
(1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product
This would impose a legal requirement to produce SBOMs for all EF projects. Although it is something we aspire to, this is a very significant effort. It would also require actively monitoring all project dependencies for known vulnerabilities in dependencies. This is generally considered an unsolved problem within the open source ecosystem with no known path to implementation.
(3) apply effective and regular tests and reviews of the security of the product with digital elements;
These would require a material change to our community’s development processes to mandate a whole class of testing which is not currently mandated for our projects. This is a very significant effort both to implement and to maintain.
Life at Eclipse 