Answering even basic questions about software supply chain security has been surprisingly hard. For instance, how widespread are the different practices associated with software supply chain security? And do software professionals view these practices as useful or not? Easy or hard? To help answer these and related questions, Chainguard, the Eclipse Foundation, the Rust Foundation, and the Open Source Security Foundation (OpenSSF) partnered to field a software supply chain security survey. The questions were primarily, but not exclusively, derived from the security requirements associated with the Supply-chain Levels for Software Artifacts (SLSA) supply chain integrity framework version 0.1 (the version when the survey was conducted), hence SLSA++.

Thanks to financial support from the OpenSSF’s Alpha-Omega project, the Eclipse Foundation is glad to have made significant improvements in the last couple of months.

Advanced shell prompts, such as those provided by theme engines like oh-my-zsh and oh-my-posh, have become increasingly popular among software developers due to their convenience, versatility, and customizability. However, the use of plugins that are executed outside of any sandbox and have full access to the developer shell environment, presents significant security risks, especially for Open Source Software developers.

Thanks to financial support from the OpenSSF’s Alpha-Omega project, the Eclipse Foundation is glad to have made significant improvements in the last couple of months. Our previous analysis helped us prioritize work area where improvements would be the most significant. Let’s see where we are today.

Open Source Software Supply Chain is at risk: threat actors are shifting target to amplify the blast radius of their attacks and as such increasing their return on investment. Over the past 3 years, we’ve witnessed an astonishing 742% average annual increase in Software Supply Chain attacks. To make it worse, the attack surface of the supply chain is wide. Covering it all requires a deep scrutinity of many factors. However, there is a simple thing, easy, and free, that every open source developer should do right now: activate multi factor authentication (also known as two factor authentication) on all development related accounts.

As stewards of the Eclipse Marketplace, the Eclispe Foundation is responsible for providing a safe place for the Eclipse IDE users to download their plugins. While the Eclipse Marketplace does not host or transmit the plugins bits, it provides links to (p2) repositories containing them. Until today, there was no restriction on those links.

Beginning December 15, 2022, the Eclipse Marketplace will no longer support links to repositories over plain HTTP. The goal is to protect users of the Eclipse Marketplace from the main risk of plain HTTP links: man-in-the-middle (MITM) attacks.

The Eclipse Foundation recently received financial support from the OpenSSF’s Alpha-Omega project. We are thrilled to be able to help our projects improve the security of their Software Supply Chain. We have a number of initiatives that are being started, but today we will focus on the 1026 git repositories of the 254 Eclipse Projects hosted at Github, spread among 50 different organizations.

A postmortem about the incident that could have affected artifacts on repo.eclipse.org

TL;DR

Infrastructure improvements and migration described in last year post is eventually happening, with some tweaks.

TL;DR

Projects hosted by the Eclipse Foundation will soon benefit from a brand new enterprise-grade continuous integration (CI) infrastructure. Expected improvements are: resiliency, scalability and nimbleness. We are doing this move with tremendous support from our friends at CloudBees and RedHat with their respective products Jenkins Enterprise and OpenShift Container Platform.