The Google Open Source Security Team (GOSST) was created in 2020 as a response to the increase of software supply chain attacks—those targeting software through vulnerabilities in other projects or infrastructure they depend on. In May 2022, GOSST announced the creation of the Google Open Source Maintenance Crew (now simply "GOSST Upstream Team"), a dedicated staff of GOSST engineers who spend 100% of their time working closely with upstream maintainers on improving the security of critical open source projects. This post takes a look back at the first year of the team’s activities, including goals, successes, and lessons learned along the way.
Why GOSST Upstream?
Every year, open source software becomes an even greater part of the software landscape—in fact, 2022 saw the most downloads of open source software ever. However, this popularity means open source software becomes an ever more appealing target for malicious actors.
Often, open source maintainers cite lack of time or resources to make security improvements to their projects or maintain them long-term. As a response, GOSST started working hands-on with some of the projects most critical to the open source ecosystem to help reduce the burden of implementing security enhancements, and assist with any additional maintenance incurred. Our goal with our contributions is to convey our respect, gratitude, and support for their valuable work.
What we do
We based our approach on examples from open source communities and recommendations from experienced maintainers and contributors:
- A GOSST engineer manually analyzes each project to understand their context and security needs.
- We follow the project's contribution guidelines to suggest the most impactful improvement selected specifically for the project's situation.
- We file issues before creating any PRs to initiate a discussion and address any maintainer questions or concerns.
- We focus on improvements that can be solved via pull request. Maintainers are busy, and we want to do as much of the work as possible for them to reduce their workload.
- We treat our contributions as conversations. Maintainers know their project better than we do, and their input helps us ensure our security improvements satisfy their unique requirements.
- We welcome all feedback on our work and related technologies, and if necessary, we work with the relevant teams to make improvements.
- Depending on the need, we follow up with additional improvements and check in to address any ongoing maintenance needs for changes we’ve made.
This approach allows us to suggest and support improvements while still respecting maintainers’ time and effort.
Achievements since last year's announcement
Following this working model, we have proposed security improvements and made ourselves available to more than 181 critical open source projects since mid-2022 including widely-used projects such as numpy, etcd, xgboost, ruby, typescript, llvm, curl, docker, and more. We contacted them using whichever method was requested in the project’s guidelines: most interactions were via GitHub issues/PRs, but some were via email mailing lists, Jira boards, or internal forums.
To analyze each project we used OpenSSF Scorecard, which evaluates how well a project follows a set of security best practices. The result of the analysis is used to gather insight on possible future enhancements for the team to implement for the project, usually aiming to fix known vulnerabilities or any opportunities for security improvements. The contributions from this approach often include many common best practices, such as:
- Adding a Security Policy (example)
- Limiting unnecessary permissions on workflows (example)
- Rewriting workflows that include dangerous patterns, such as allowing remote code execution in the repository context (example)
- Adding the OpenSSF Scorecard action, to automatically check security status and report results (example)
- Pinning dependencies (example)
- Adopting a dependency-updating tool, and more
The team also looked for ways that projects could adopt the OpenSSF's Supply-chain Levels for Software Artifacts (SLSA) framework to harden their build and release processes. These contributions help secure projects against tampering and guarantee the integrity of their released packages.
A significant part of our contributions also helped projects adopt the OpenSSF Scorecard GitHub Action. When it's added to a project, each change to the code base triggers a review of security best practices and alerts projects to changes that could regress or harm their security posture. It also suggests actionable and specific changes that could enhance this posture. Additionally, the tool integrates with the OSV Scanner, which evaluates a project's transitive dependencies looking for known vulnerabilities.
As a result of these interactions with open source maintainers, the team received and conveyed valuable feedback for the tools we suggested. For example, we were able to address potential friction points for maintainers who adopt Scorecard, such as improving scoring criteria to better reflect their efforts to secure their projects. We’ve also gathered frequently asked questions we received from maintainers and created an FAQ to answer them. Additionally, the team added to documentation for the SLSA framework by clarifying the decoding process to access SLSA provenance created with the OpenSSF SLSA GitHub generator tool.
Still to come in 2023
In the year ahead, we’re going to expand our support to even more repositories, while still focusing on the projects most critical to the open source ecosystems. We'll also revisit projects we've already contributed to and see if there's more support we can offer. At the same time, we’re going to double down on our efforts to improve usability and documentation for security tools to make it even easier for maintainers to adopt security improvements with as little effort as possible.
Moving forward, we’ll also further encourage maintainers to take advantage of the OpenSSF's Secure Open Source Rewards program. This Linux Foundation program financially rewards developers for improving the security of important open source projects, and has already given $274,014 to open source maintainers to date. Maintainers can then choose to either have us raise PRs and implement the changes for them, or be financially rewarded for making the changes themselves – we'd still be available to answer questions that come up along the way.
Takeaways and how to get in touch
Based on the positive responses from open source maintainers this past year, we’re happy to count our efforts as time well spent. It’s clear that many open source maintainers welcome help from the companies that rely on their projects.
We’re constantly getting in touch with open source communities and love talking to folks about how we can help address security issues. The door is always open for community members to contact us too! Please reach out about anything related to our upstream work at [email protected].
We’re just getting started and look forward to giving back to even more projects. We hope other companies will join us and also invest in full-time developer teams dedicated to supporting the open source communities we all rely on.
By Diogo Sant'Anna and Joyce Brum, Google Open Source Security Team
