At Alpha-Omega, our mission is to secure the open source ecosystem by investing in foundational technologies and the communities that support them. AWS is a premier member of the Alpha-Omega project, one of the providers of the funds that become our open source security grants. Hear from Henri Yandell, AWS Senior Principal and a member of our core team here at Alpha-Omega, on why AWS invests in open source security and what’s in it for AWS.
By Henri Yandell
Virtually everything of importance in the modern IT world is built atop open source. Whether it is our own code at AWS, our customer’s code, or anything else in that modern IT world, we all need open source software to be well maintained and secure. We’ve come a long way from the early days when open source servers were hiding under a developer’s desk, quietly powering a newfangled internal wiki, or being the team’s source control and build server. For example, I still remember getting my first laptop (the 2001 Titanium G4!), and how that injected new energies into the open source Java code I was releasing, how I could now sit in front of the TV, releasing Apache Commons jar files to the world.
That’s not typically how it works nowadays. Right? We’re not still relying on a build that someone did on their laptop while watching their latest favorite show? And the answer is…generally not. Probably not. Most of the time not. There are far more options available, more lessons learned, more features and capabilities to take advantage of, but scratch the surface and you’re reminded that the open source community is people making do with what they’ve got. And Alpha-Omega (colloquially A-O) is about helping them do more.
Part of my role at AWS involves guiding product teams who are directly contributing to, and sponsoring, the open source projects that are so important to their products. For example, product teams like Amazon RDS for PostgreSQL and the Amazon Corretto OpenJDK distribution; developers whose contributions have earned them roles at groups like the Rust Foundation and the Apache Software Foundation; and businesses who are contributing to projects at associations like the Cloud Native Computing Foundation and the OpenSearch Software Foundation. That’s very tangible – there are individuals I work with who are directly involved and customers directly impacted by the contributions being made. But there’s a deeper foundation to open source, projects that are everywhere, often quietly and without those tangible connections to the business side of things. Apache Log4j became the poster-child for these projects back in 2021, but this ‘critical open source infrastructure’ is broad and hard to see.
Alpha-Omega provides us, at AWS, a way to focus on this broader core critical open source infrastructure that supports open source development around the globe. And rather than tackling that alone, we are able to partner with a community of like-minded companies looking for the same focus on:
(i) make it someone’s job – supporting the experts who are managing the security of the world’s most widely-used open source
(ii) improve it for all – fund projects that enhance the security features of the package indexes, and
(iii) dive deep when critical – tactically improve those projects that are most relied on across the various open source ecosystems.
Making It Someone’s Job.
So often, open source projects rely on the passionate work of their security volunteers. For so many of the open source related CVEs you receive, there was a volunteer security expert advising the project on their release. It makes us very happy at AWS that we’re able, through Alpha-Omega, to fund a cadre of those security experts so that it’s no longer a volunteer role. A-O funds security experts at some of the biggest open source project groups – at the Python Software Foundation, the Eclipse Foundation, the Rust Foundation, RubyCentral, the OpenJS Foundation, as well as experts who focus on improving the Linux Kernel. Funding these individuals not only gives them much more time to focus on improving hundreds if not thousands of projects, but has also given them the time to become a community of their own. No longer distant islands of expertise, now they are guiding and encouraging each other. In the classic community way, the sum has become more than the parts.
That’s what I’m most looking forward to here. The individuals we are funding at Alpha-Omega are leaders who are having an effect on each other and the communities around them. I’ve never really felt we’ve had much of an ‘open source security’ community. We’ve got open source communities, and security communities, but the ‘open source security’ community that has its feet firmly in both of those worlds is tenuous, small, and disconnected. I am very proud of the way the folk we’re funding are connecting to each other and building that bigger open source security community.
Improve It For All.
Communities at locations like the Open Source Security Foundation (OpenSSF) have been, and are, defining new higher bars for how open source may be developed, released, and packaged for its users. For example – defining what it means to prove that the artifact you install is the artifact the original project intended you to install, and how that project’s authors can demonstrate the professional way they approach their software development. A-O funds package indexes like PyPI, Rust Crates, and RubyGems to add features that support these higher bars, and to fund groups like the Apache Software Foundation (ASF) and Eclipse Foundation to implement changes to their release tooling.
As a former release manager at the ASF, I can’t help but to be looking forward to the work they’ve started this year to enhance the security capabilities of their release processes. The ASF self-funds their security management and hasn’t needed A-O funding, so it’s been good to find a way to support them.
Dive Deep When Critical.
I mentioned CVEs a few paragraphs back. Identifying security issues within open source projects is often a very low-contact conversation. Projects receive a surprise report about a specific issue from a researcher, emails go back and forth, and, if there is a concern, a release announcement is made. There’s no further relationship between the project and the researcher, the research isn’t going on where the project is most concerned and the project wasn’t expecting that issue in their release planning. As I’ve found from discussions with folk like the Open Source Technology Improvement Fund (OSTIF), there is a better way to do this, and both ourselves at AWS, and other Alpha-Omega stakeholders were already active here. Funding audits of projects that begin with someone well versed in open source communities working out a plan with the project for where best to investigate and how they will report. We’ve continued that at Alpha-Omega, for example working with OSTIF on multiple OpenSSL audits.
This is one of those ‘clearly doesn’t scale’ areas, but I’ve always felt it’s critical to keep practicing walking even when you’re an expert at running at scale. Problems change and if you think you solved the problem at scale yesterday, a surprise will eventually come your way. At Alpha-Omega we don’t say which audits we have in progress, but I’m happy to confirm that identifying core projects and funding audits remains an active area of funding for us.
Of course, while it’s a core-pillar of how AWS is supporting open source security, Alpha-Omega isn’t the only way in which AWS supports securing open source. At AWS we partner with many other corporations and individuals at the Open Source Security Foundation; we’re proud to work with GitHub’s sponsorship program, providing funds directly to open source developers; and we know we’re not the only organization out there providing resourcing credits directly to open source infrastructure. It’s also not the only fund for supporting improvements – I know I speak for my peers at Alpha-Omega when I say that we are big admirers of the Sovereign Tech Agency and the funding they provide to open source.
None of this can be done alone.
It will take all of us working together – whether that be more companies funding similar open source security improvements, having more folk being funded to enact changes and lead best practices, or more projects following that lead to better secure their processes. Please join us at the OpenSSF’s Slack channel for Alpha-Omega (#alpha_omega) to stay in touch. If you don’t know where to get started, come discuss.
Author Bio
Henri specializes in large-scale organization of Open Source. Starting as a committer with Jakarta and Apache Commons projects in 2001, he has served on Apache Software Foundation legal and security committees, and as a board member. From 2007 he has led Open Source at Amazon, tackling licensing, upstreaming, company projects, and now the growing field of open source security.
