Eclipse Foundation Cyber Risk Initiative Concept
This document is intended to motivate discussions around creating and funding a Cyber Risk Initiative Working Group at the Eclipse Foundation. It is our hope that it will be a call to action to bring Eclipse Foundation members and stakeholders together to discuss collective action to improve the cyber resilience of the Eclipse Foundation projects, community, and infrastructure.
Open source supply chain security is top of mind across the entire Information and Communication Technologies (ICT) industry today. The motivations are well documented and outside the scope of this document. However, it is clear that the Eclipse Foundation, its community, its projects, and its industry collaborations all have a strong motivation to be leaders in advocating and implementing security best practices. Our members, adopters, users, and stakeholders all seek to reduce their security risks to the fullest extent possible. As demonstrated by draft legislation from a number of jurisdictions, governments expect industry to act to improve software security.
One thing that is clear, however, is that simply putting the entire burden of added security work on the shoulders of our committers and project leaders is not an option. This topic needs to be addressed by services provided by the Eclipse Foundation to our project community or it will fail. Without strong support in terms of release and build engineering, tooling, and education, developers simply do not have the time, interest, or skills necessary to be responsible for implementing security best practices. It is equally true that security, and particularly supply chain security, requires a programmatic approach. Security is not an attribute that you simply add to existing software.
The Eclipse Foundation believes a strategic investment is needed to significantly enhance our security processes across all aspects of our operations, both internally and with our projects. Achieving this goal cannot be done by simply shifting current resources; rather, it will require additional resources from its membership and stakeholders. We have made progress in building staff capacity and initiating key security-related initiatives, and now our goal is to sustain and potentially accelerate these efforts, ensuring continued growth and improvement in our security processes and infrastructure. Even in the most optimistic of scenarios, assisting our 400+ projects to improve security will be a long and laborious process.
Based on the above, the Eclipse Foundation is proposing to establish a Cyber Risk Initiative to fund, collaborate on, and prioritize enhancements to our security-related processes and infrastructure. The goal is to raise €1.5M in funding for a minimum of each of the next three years in order to achieve these improvements. The establishment and prioritization of the initiatives using those funds will be the responsibility of the working group itself, although some thoughts are outlined below.
The Eclipse Foundation requires your support to make this happen. The scope of this working group will be to:
- Improve our policies and processes.
- Improve our infrastructure.
- Secure our projects.
- Help our committers and contributors improve their skills.
Each of these points will be expanded upon below.
Policies and Processes
The Eclipse Foundation has long had a security policy, and is a CVE numbering authority. However, seeking the input and guidance of security experts from the organizations in the Cyber Risk Initiative will help to ensure that we are implementing best practices and doing so in a manner that best suits Eclipse's existing project structure and infrastructure. As part of establishing this working group, re-constituting the Eclipse Security Team will ensure that we are drawing upon a group of world-class security experts. In addition, the proposed working group will fund the hiring of dedicated staff, including a lead security expert that will provide oversight and direction for the team.
Improve Our Infrastructure
Although the Eclipse Foundation has secure infrastructure in place today, there is additional work that could and should be done to improve the infrastructure that supports our open source projects. These enhancements are motivated by new threats, and associated new best practices in the industry. Items include:
- Hardening our infrastructure by applying the recommendations in our Open Source Software Supply Chain Best Practices document such as using multi-factor authentication.
- Fund security audits and penetration tests performed by third parties to increase confidence in our processes and infrastructure.
- Review and revise our infrastructure security policies and procedures to ensure that they reflect industry best practices. As part of this, evaluate whether adopting a zero trust architecture would be of benefit. Fund the efforts required to mitigate any identified deficiencies or develop enhancements.
- Adding new build-time services for our projects via our Common Build Infrastructure (CBI). For example, making available the compute resources required for every project to run code vulnerability scanning or dependencies lifecycle management tools. Fund the necessary server infrastructure and engineering services to our projects to include these tools in their build scripts plus automating detection and reporting.
Secure Our Projects
In addition to improving our processes and infrastructure we need to assist our projects in improving their own security. In particular we need to provide services to our projects to implement our Open Source Software Supply Chain Best Practices. We envisage this as a service provided to our projects by additional staff funded by the working group to protect the code repositories, secure third party artifacts, secure build pipelines, and protect build outputs. In addition, many of our projects implement various forms of deployment update mechanisms which should be reviewed and hardened to help ensure user deployment security.
In the short term, we will focus on three key actions. First, we will identify critical projects and provide them with assistance in adopting improved policies and processes. Secondly, we will allocate funds to conduct third party security audits and penetration tests to increase confidence in these critical projects. Finally, we will conduct thorough analyses of project dependencies to identify and address risks resulting from (for example) outdated third party packages, which may contain known vulnerabilities. As part of this effort, we will actively incentivize and support our projects in generating Software Bill of Materials (SBOMs) to facilitate the discovery of vulnerabilities in their third-party dependencies, enabling us to provide them with the necessary assistance. A specific example of this is the IDE Simultaneous Release, where we are aware that several dependencies have not been regularly updated and thus require remedial measures.
In the short to medium term, assisting as many of our projects as possible to move to reproducible builds is considered a key objective to mitigate supply chain security risks.
With more than 400 projects at the Eclipse Foundation, adoption of these new practices will not be universal. Certainly not immediately, and perhaps never. So rather than requiring every project to adhere to new policies or processes it is our intent to fund the development of a project badging program (perhaps based on security levels such as SLSA) to indicate which projects are implementing security best practices. The creation of such a project security badging program could create a tremendous value add for Eclipse projects and their adoption.
Improve Skills and Culture
It is our intent to provide advisory services to our projects to improve their security by enhancing the infrastructure and the build and release engineering practices they use. However that does not imply that our project committers will not be an integral part of addressing security. First off, some changes will be required to the project code and builds that only committers can perform. Secondly, there is a class of security practices which must be done in the project code and is therefore beyond the remit of the Foundation staff. For example, addressing CVEs in the project code itself. For these reasons, we feel it necessary to also fund training and education to help raise security awareness and skills amongst our committer and contributor population. It is our goal to promote a secure-engineering culture within our projects, some of which may find its way into our policies and procedures such as the Eclipse Development Process (EDP). Developing and deploying training materials, plus leveraging existing ones, along with a developer badging program, will help instill a more security-conscious culture amongst the Eclipse community.