By Zach Steindler, Principal Engineer, GitHub
Open source package repositories (like npm, PyPI, RubyGems, and others) serve out billions of packages per day. Most of the software we all use includes packages from these repositories, making them a critical part of securing software.
So how do we all make these package repositories more secure?
It’s not an easy question to answer, because these repositories are quite diverse. Some, like npm and Maven Central, are operated by for-profit companies while others, like PyPI and RubyGems, are operated by non-profits. Some, like NuGet and Packagist, manage user accounts, while others, like the golang index and Homebrew, do not. One way to help is to catalog the differences between package repositories, look at high impact security capabilities in those different areas, and organize those capabilities based on how difficult it is to deliver them, which is what the OpenSSF Securing Repositories Working Group covers in the Principles for Package Repository Security.
But it takes a lot more to actually deliver these security capabilities in an ecosystem. Many communities have a change proposal process, where implementation details specific to that ecosystem can be worked out, and to ensure that the change aligns with the goals of that community. Since these repositories operate for decades, this is an important step to ensure their stability and compatibility. You can’t just copy an implementation from one ecosystem into another, but you can share lessons learned, tradeoffs considered, and high-level architecture to make it easier for ecosystems to learn from each other, which is what the Securing Repos Working Group helps with by publishing things like Trusted Publishers for All Package Repositories or Build Provenance for All Package Registries.
Writing guidance per-capability certainly helps, but it’s a fair amount of work. In the meantime, we thought it’d be helpful to inventory recent package repository security capabilities to make it easier for ecosystems to be aware of what each other are working on, and enable informal conversations between repositories that are interested in a security capability with ones who have already implemented it.
You may have noticed the last column of that spreadsheet, and it’s our last ingredient for more secure package repositories – funding! Just like sharing implementation experiences, we hope this helps ecosystems navigate the funding process, making it easier to obtain funding in the future. For example, several years ago PyPI got funding from Open Technology Fund to build 2FA and API token support. That project and funding support were fantastic, but it’s a lot of work applying for funding for each security capability, so more recent requests have been oriented around a role to focus on a number of security projects, like the Python Software Foundation Security Developer in Residence role funded by OpenSSF Alpha Omega.
For both implementations and funding, there isn’t one way of doing things that will work for everyone. But by gathering this information and making it widely available, we think this makes it easier for package repositories to deliver security capabilities to their respective ecosystems.
If you maintain a package repository and haven’t yet participated in the Securing Repositories Working Group, we’d love to hear from you!
Even if you don’t maintain a package repository, we think there’s a lot to learn from this space. For starters, make sure you’re protecting your accounts with 2FA, look at things like trusted publishers from PyPI and RubyGems to get long-lived secrets out of your build pipelines, and make your npm package source code and build instructions more transparent by generating provenance statements.
And if you’re trying to land security capabilities in another space, remember that there’s a lot more to it than writing code. Security is a team sport, and it’s just as important to spend time talking to folks to ensure your approach aligns with your community’s values, investing in usability and documentation, and sharing lessons learned to make it easier for other folks to follow you. Don’t get me wrong – things are far from perfect and we have a lot of work ahead of us. But contrary to what some say, humans can be the strongest element of securing software systems.
About the Author
Zach is a member of the OpenSSF’s Technical Advisory Council and co-chair of the Securing Repositories Working Group which helps coordinate security improvements in programming language package repositories like PyPI and Ruby Gems. He works at GitHub on securing software development for open source and enterprises. Away from computers he enjoys gardening and welding.