workinggroups/content/en_eclipse-cyber-risk-concept.php - www.eclipse.org/org - Git at Google

 <?php
 /**
  * Copyright (c) 2023 Eclipse Foundation.
  *
  * This program and the accompanying materials are made
  * available under the terms of the Eclipse Public License 2.0
  * which is available at /legal/epl-2.0/
  *
  * Contributors:
  *  Olivier Goulet <olivier.goulet@eclipse-foundation.org>
  *
  * SPDX-License-Identifier: EPL-2.0
  */
 ?>
 <div id="maincontent">
   <div id="midcolumn">
     <h1><?php print $pageTitle; ?></h1>

     <p>
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       The Eclipse Foundation requires your support to make this happen. The
       scope of this working group will be to:
     </p>
     <ol>
       <li>Improve our policies and processes.</li>
       <li>Improve our infrastructure.</li>
       <li>Secure our projects.</li>
       <li>Help our committers and contributors improve their skills.</li>
     </ol>
     <p>Each of these points will be expanded upon below.</p>

     <h2>Policies and Processes</h2>
     <p>
       The Eclipse Foundation has long had a <a href="/security/policy.php">security policy</a>,
       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.
     </p>

     <h2>Improve Our Infrastructure</h2>
     <p>
       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:
     </p>
     <ul>
       <li>
         Hardening our infrastructure by applying the recommendations in our
         <a href="https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md">Open Source Software Supply Chain Best Practices</a>
         document such as using multi-factor authentication.
       </li>
       <li>
         Fund security audits and penetration tests performed by third parties
         to increase confidence in our processes and infrastructure.
       </li>
       <li>
         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.
       </li>
       <li>
         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.
       </li>
     </ul>

     <h2>Secure Our Projects</h2>
     <p>
       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 <a href="https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md">Open Source Software Supply Chain Best Practices</a>.
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       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.
     </p>
     <p>
       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 <a href="https://slsa.dev/">SLSA</a>)
       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.
     </p>

     <h2>Improve Skills and Culture</h2>
     <p>
       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 <a href="/projects/dev_process/">Eclipse Development Process</a>
       (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.
     </p>
   </div>
 </div>
	<?php
	/**
	* Copyright (c) 2023 Eclipse Foundation.
	*
	* This program and the accompanying materials are made
	* available under the terms of the Eclipse Public License 2.0
	* which is available at /legal/epl-2.0/
	*
	* Contributors:
	* Olivier Goulet <olivier.goulet@eclipse-foundation.org>
	*
	* SPDX-License-Identifier: EPL-2.0
	*/
	?>
	<div id="maincontent">
	<div id="midcolumn">
	<h1><?php print $pageTitle; ?></h1>

	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	The Eclipse Foundation requires your support to make this happen. The
	scope of this working group will be to:
	</p>
	<ol>
	<li>Improve our policies and processes.</li>
	<li>Improve our infrastructure.</li>
	<li>Secure our projects.</li>
	<li>Help our committers and contributors improve their skills.</li>
	</ol>
	<p>Each of these points will be expanded upon below.</p>

	<h2>Policies and Processes</h2>
	<p>
	The Eclipse Foundation has long had a <a href="/security/policy.php">security policy</a>,
	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.
	</p>

	<h2>Improve Our Infrastructure</h2>
	<p>
	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:
	</p>
	<ul>
	<li>
	Hardening our infrastructure by applying the recommendations in our
	<a href="https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md">Open Source Software Supply Chain Best Practices</a>
	document such as using multi-factor authentication.
	</li>
	<li>
	Fund security audits and penetration tests performed by third parties
	to increase confidence in our processes and infrastructure.
	</li>
	<li>
	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.
	</li>
	<li>
	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.
	</li>
	</ul>

	<h2>Secure Our Projects</h2>
	<p>
	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 <a href="https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md">Open Source Software Supply Chain Best Practices</a>.
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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.
	</p>
	<p>
	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 <a href="https://slsa.dev/">SLSA</a>)
	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.
	</p>

	<h2>Improve Skills and Culture</h2>
	<p>
	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 <a href="/projects/dev_process/">Eclipse Development Process</a>
	(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.
	</p>
	</div>
	</div>