The new practices would require project maintainers to be identifiable, accountable, and authenticated.
Image: Getty Images/iStockphoto
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.
SEE: Hiring Kit: Python developer (TechRepublic Premium)
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:
- Know about the vulnerabilities in your software
- Prevent the addition of new vulnerabilities, and
- Fix or remove vulnerabilities.
The recent supply chain attacks involving SolarWinds and others that led to the compromise of thousands of organizations involved closed source or proprietary software.
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.
Open-source software projects, particularly Java and JavaScript/Node.js, rely on thousands of direct and indirect dependencies, making them tough to explore for vulnerabilities.
The Google engineers note that it is “impractical to monitor them all” and, they add, many open-source packages are not well maintained.
“Open source likely makes more use of dependencies than closed source, and from a wider range of suppliers; the number of distinct entities that need to be trusted can be very high,” they write.
“This makes it extremely difficult to understand how open source is used in products and what vulnerabilities might be relevant. There is also no assurance that what is built matches the source code.”
SEE: Microsoft 365 vs Google Workspace: Which productivity suite is best for your business?
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.
