Security has been a concern in the software industry for a long time. But the landscape and interplay between those trying to secure software and those trying to steal or compromise it has changed. For one thing, it has grown immensely in scope: if cybercrime were a country, it would have the third largest economy in the world, right after the U.S. and China. Forecasts suggest that by 2025, annual costs from cybercrime will hit $10.5 trillion.
But it’s not just that cybercrime is a growth industry; it’s also changing targets. Ten-plus years ago, cybercrime was largely targeted at apps in production. These days, it’s increasingly attacking the software supply chain, from source code to dependencies.
This is an industry-wide issue. But because open source has become so prevalent in the software industry — 85-90% of all software developed today has open source code in it — it’s also the main vector of attack. That makes software supply chain security a priority for the Eclipse Foundation, and we want to be the leading open source foundation implementing supply chain security best practices. Thanks to funding from the Open Source Security Foundation (OpenSSF), we’ve started to make this happen.
Extending SLSA Framework Compliance for Projects
One of the main ways we’re tackling this is by enhancing compliance with higher levels of the Supply-chain Levels for Software Artifacts (SLSA) framework. Our existing governance practices ensure that projects across the Foundation are generally compliant with at least level one or two. But getting to level three and four requires more work and involvement, which is where we want to provide services and help.
Take, for instance, the generation of provenance data. This is something that’s not a commonly adopted practice in the open source community. But it is a prerequisite for higher levels of SLSA compliance. There are some tools on GitHub that allow for it. But at the Foundation, most of our projects are built in Jenkins. So, we will be providing some limited support for generating provenance in Jenkins.
Some projects already have the SLSA compliance process well underway. Eclipse Temurin, for example, just recently completed the work necessary to reach level 2 SLSA compliance and is working on achieving level 3. Once that’s completed, the other projects in Eclipse Adoptium will start working towards it as well.
It’s worth noting that this is going to be a gradual process: we’ve been working with some early adopters to figure out the best ways to bring projects to higher levels of SLSA compliance. When we’re a bit more confident in the process we’ll be onboarding more people to start rolling things out more incrementally.
Other Security Enhancements Will Ease Regulatory Compliance
As part of this process, we ran an analysis of the GitHub project repositories using scorecard from the OpenSSF. Two main security issues were identified.
The first is that many projects use GitHub actions to build products, but they don’t apply the Principle of Least Privilege on their CI tokens. We want to help them get better at that.
It also identified that many projects don’t use branch protection, which can make their supply chain very vulnerable. For example, they don’t require multiple reviews before something is pushed on the production branch and they allow force push, which can compromise the history of the GitHub repository.
Apart from the obvious advantages of protecting the code, we hope that these changes will be a net positive for the community. Many state-level agencies in both Europe and the U.S. are creating regulations that require many of the security capabilities that we’re working on. Once we’ve implemented these capabilities at the Foundation level, that should lessen the burden for users of those projects to try to meet those regulatory requirements.
Updates Will Minimize Disruptions to Community
From the Foundation’s perspective, we think that putting the burden of added security work on the shoulders of open source project maintainers is not desirable. We really want to make this new pillar for the Eclipse Foundation a core service, so that it’s as easy as possible for project contributors and maintainers to do, and not be a barrier to entry.
That’s also part of why this process is going to be happening incrementally. Obviously, security isn’t a one-and-done issue, so that’s a factor. But we also want to make sure we’re confident in our processes and that the security team at the Foundation is ready.
Sustainable Security Will Require a Working Group
Our funding from OpenSSF covers 2022 and 2023, but security is a journey, not a destination. We want to make this initiative sustainable, and the best way to do that is with a working group. So, we’re setting up a security working group, and we’re looking for members.
If you also think that software supply chain security is important and you want to help make it sustainable, come talk to us and find out how you can help build this working group.
About the Author
Mikaël Barbero
Mikaël Barbero is the head of security at Eclipse Foundation and the project lead for the Common Build Infrastructure project.