Google joins the Open Source Security Foundation

In modern software development, much of the code developers use originates outside their organization and is open source. While the cloud and internet ecosystem depends on an open source foundation, the sheer scale and dependency chain of the libraries and packages we all use makes it difficult to validate and verify the origin of the code you’re ingesting; that it’s up to date on recent patches, and coming from projects following security best practices. To continue deriving benefits from open source, we need to ensure that as a community we are building on the strongest possible foundation. 

At Google, security is always top of mind, and we have developed robust systems and security tools—including open source ones—to protect our internal systems and our customers. We believe the more we share what we’ve learned about open source security, and the more we work with those who face similar challenges, the more we can improve the state of open source security for everyone.

We’re happy to announce that Google is joining the Open Source Security Foundation (OpenSSF) to work alongside the broader industry on this journey of improving the state of security of open source projects we all depend on. Google has key areas in open source security we want to work on, and we’re excited to share our ideas with the OpenSSF community and work together. Some of our key areas are:

1. Shared schemas and metadata that enable automation for enforcing security best practices along the entire software supply chain.
2. Dependency management and risk assessments through tooling and data. We want to make it easy to map vulnerabilities back to specific versions of code that are affected and take action.
3. Verifiable builds through trusted build systems so that we know artifacts haven’t been tampered with. The Tekton project has been exploring this idea, and we’re excited to share some of these ideas with OpenSSF.
4. A developer identity system to help associate code changes back to their original author and help code reviewers have developer authentication as part of their commit and PR review process.
5. Securing critical OSS projects and helping projects respond to vulnerabilities. If you’re a maintainer who’s interested in getting help with vulnerability response or security engineering efforts, watch this space!

Security challenges are never going to disappear, and we must work together to maintain the security of the open source software we collectively depend on. If you're interested in getting involved in the OpenSSF initiatives, visit openssf.org or OpenSSF on GitHub.You can be a part of how the OpenSSF serves the open source community and the world!

By Kim Lewandowski, Product Security Team, and Dan Lorenc, Infrastructure Security Team, Google

Announcing a new kind of open source organization

Google has deep roots in open source. We're proud of our 20 years of contributions and community collaboration. The scale and tenure of Google’s open source participation has taught us what works well, what doesn’t, and where the corner cases are that challenge projects.

One of the places we’ve historically seen projects stumble is in managing their trademarks—their project’s name and logo. How project trademarks are used is different from how their code is used, as trademarks are a method of quality assurance. This includes the assurance that the code in question has an open source license. When trademarks are properly managed, project maintainers can define their identity, provide assurances to downstream users of the quality of their offering, and give others in the community certainty about the free and fair use of the brand.

In collaboration with academic leaders, independent contributors, and SADA Systems, today we are announcing the Open Usage Commons, an organization focused on extending the philosophy and definition of open source to project trademarks. The mission of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing. Creating a neutral, independent ownership for these trademarks gives contributors and consumers peace of mind regarding their use of project names in a fair and transparent way.

Understanding and managing trademarks is critical for the long-term sustainability of projects, particularly with the increasing number of enterprise products based on open source. Trademarks sit at the juncture of the rule of law and the philosophy of open source, a complicated space; for this reason, we consider it to be the next challenge for open source, one we want to help with.

To get the Open Usage Commons started, Google has contributed initial funding, and the trademarks of Angular, a web application framework for mobile and desktop; Gerrit, web-based team code-collaboration tool; and Istio, an open platform to connect, manage, and secure microservices, will be joining the Open Usage Commons. If you use a trademark of one of the projects currently, you can continue to use those marks, following any current guidance from the project. As the Open Usage Commons is focused on trademark management, the contributor communities and technical roadmaps of these projects are not changed by joining the Commons, although we hope this new model encourages anyone who has stood on the sidelines until now to participate in these projects.

As the Open Usage Commons board wrote in their announcement, this is uncharted territory, and the Commons intends to “walk before they run,” so you can expect more information and activity from the organization in the coming months.

Learn more about the role of trademarks in open source and the Open Usage Commons at openusage.org.

By Chris DiBona, Director, Open Source at Google

Expanding our Differential Privacy Library

All developers have a responsibility to treat data with care and respect. Differential privacy helps organizations derive insights from data while simultaneously ensuring that those results do not allow any individual's data to be distinguished or re-identified. This principled approach supports data computation and analysis across many of Google’s core products and features.

Last summer, Google open sourced our foundational differential privacy library so developers and organizations around the world can benefit from this technology. Today, we’re announcing the addition of Go and Java to our library, an end-to-end solution for differential privacy: Privacy on Beam, and new tools to help developers implement this technology effectively.

We’ve listened to feedback from our developer community and, as of today, developers can now perform differentially private analysis in Java and Go. We’re working to bring these two libraries to full feature parity with C++.

We want all developers to have access to differential privacy, regardless of their level of expertise. Our new Privacy on Beam framework captures years of Googler developer experience and efficiency improvements in a comprehensive and easy-to-use solution that handles computation end-to-end. Built on Apache Beam, Privacy on Beam can reduce implementation mistakes, and take care of all the steps that are essential to differential privacy, including noise addition, partition selection, and contribution bounding. If you’re new to Apache Beam or differential privacy, our codelab can get you started.

Tracking privacy budgets is another challenge developers face when implementing differential privacy. So, we’re also releasing a new Privacy Loss Distribution tool for tracking privacy budgets. With this tool, developers can maintain an accurate estimate of the total cost to user privacy for collections of differentially private queries, and better evaluate the overall impact of their pipelines. Privacy Loss Distribution supports widely used mechanisms (such as Laplace, Gaussian, and Randomized response) and can scale to hundreds of compositions.

We hope these new languages, tools, and features unlock differential privacy for even more developers. Continue to share your stories and suggestions with us at [email protected]—your feedback will help inform our future differential privacy launches and updates.

Acknowledgements

Software Engineers: Yurii Sushko, Daniel Simmons-Marengo, Christoph Dibak, Damien Desfontaines, Maria Telyatnikova, Dennis Kraft, Jimmy Ross, Vadym Doroshenko
Research Scientists: Pasin Manurangsi, Ravi Kumar, Sergei Vassilvitskii, Alex Kulesza, Jenny Gillenwater, Kareem Amin

By: Miguel Guevara, Mirac Vuslat Basaran, Sasha Kulankhina, and Badih Ghazi – Google Privacy Team and Google Research