Open source: Google wants new rules for developers working on 'critical' projects
If your open-source software project is considered "critical", you could be facing a lot more work and responsibility in the future. But for now, it's just some ideas from a few of Google's top engineers.
Open-source software should be more secure than closed source, but only if people are inspecting it and that's not an easy job, Google argues.
But to ensure future software supply chain attacks don't involve key open-source software projects, some of Google's top engineers have proposed new 'norms' that might cause problems with open-source contributors – if their project is considered "critical".
If the industry as a whole can decide that a particular project is "critical", Google has suggested new practices that would require project owners and maintainers to be identifiable, accountable, and authenticated. That would mean no more changes to code at will, and subjecting changes to third-party review.
Google acknowledges its suggestions for critical open-source software are more "onerous" on project owners, and so it is expecting resistance to its recommendations.
Google admits "we are but one voice in a space where consensus and sustainable solutions matter most of all." But it's a powerful voice in tech. The company has outlined its suggestions for attaining these goals in the blogpost.
Rob Pike, a key designer of Google's Go programming language, and Eric Brewer, and VP Infrastructure & Google Fellow argue in a new blogpost that the industry should agree to "define collectively the set of "critical" software packages, and apply these higher standards only to this set."
The objectives for critical open-source software include:
No unilateral changes to code. Changes would require code review and approval by two independent parties
Authenticate participants. This means owners and maintainers cannot be anonymous; contributors are required to use strong authentication (eg 2FA)
There need to be notifications for changes in risk to the software
Enabling transparency for software artifacts
Create ways to trust the build process
"The [goals are] more onerous and therefore will meet some resistance, but we believe the extra constraints are fundamental for security," the engineers explain.
The first set of goals Google wants the industry to consider for all open-source software are less contentious, but would still require more work and address issues that even Google finds challenging.
The first three key objectives overall for all open-source software include:
While open source doesn't suffer from 'security through obscurity', it doesn't follow that open source is actually free of vulnerabilities.
"Open-source software should be less risky on the security front, as all of the code and dependencies are in the open and available for inspection and verification. And while that is generally true, it assumes people are actually looking," they write.
To address supply chain attacks, the industry needs to focus on addressing the "majority of vulnerabilities" because attackers frequently pursue known vulnerabilities rather than finding their own.
The problem for organizations using open source is that few verify all the packages they're using. Even Google finds this task difficult.
"Tracking these packages takes a non-trivial amount of infrastructure, and significant manual effort.
"At Google, we have those resources and go to extraordinary lengths to manage the open-source packages we use—including keeping a private repo of all open-source packages we use internally—and it is still challenging to track all of the updates. The sheer flow of updates is daunting."
Google sees automation as a way forward to address the torrent of updates to open-source packages.