Google considers that the attention that open source security receives is justified and ensuring the trust of users requires a consensus on possible solutions such as the one they propose: in short, that developers take responsibility for their developments.
Mountain View engineers propose a framework based on three aspects: know, prevent, correct. The basic idea is that project managers open source considered critical by the industry must be identifiable, accountable and authenticated. They could not act on their own.
Those responsible for "critical" open source projects should be identifiable, accountable and authenticated, according to Google's proposal.
Google's Rules for the Industry's Most "Critical" Open Source
From Google they consider two aspects fundamental: reach consensus on metadata and identity standards and achieve greater transparency and review of said critical software. This is the fundamental framework from which they propose to develop the rest of the solutions.
The first aspect is considered key when it comes to allowing automation, reducing the effort required for updates and minimizing the impact of vulnerability. The second, they explain, is necessary to ensure sufficient review of critical projects, avoid unilateral changes and get transparently verifiable and well-defined official versions.
From Google they believe that the additional limitations in open source software are fundamental for security
Eric Brewer, Rob Pike, Abhishek Arya, Anne Bertucio and Kim Lewandowski, the authors of the Google post, argue that the intent is to collectively define the set of "critical" software packages and apply the stricter standards of your open source rules proposal to only that set of applications. It would be, up to a point, more closed source.
Specifically, the general objectives for managing vulnerabilities in open source are the following:
- Know- Accurate vulnerability data, standard schema for vulnerability databases, and accurate dependency tracking.
- To prevent: understand the risks of new dependencies.
- To correct: understand your options to eliminate vulnerabilities, notifications to speed up repairs and fixes of the most used versions.
"However, these objectives are not sufficient in the presence of adversaries or to prevent attacks on the supply chain"they say from Google. For this reason, they have raised a second set of specific objectives for critical software, as we said. "The second set is more onerous and therefore will meet some resistance, but we believe that the additional restrictions are critical to safety."
The specific objectives of critical open source would be the following:
- No unilateral changes: modifications would be subject to prior approval by two independent parties and such changes would require revision of the code
- Authenticated participants: Owners and / or maintainers could not be anonymous, there should be strong authentication of contributors, and a federated model of identities should be developed.
- Notification of changes in risk.
- Enable transparency for software artifacts.
- Create ways to trust the development process.
"Open source software should be more secure than closed source software," Google explains, but in their opinion it requires additional involvement such as the one they want to make clear through the proposed rules.
"Open source software should be more secure than closed source"
The ultimate and fundamental objective, they say, is to reinforce that security that has always been defended by the community that embraces the model. They want to ensure its reliability because the open source, despite everything, is not safe from vulnerabilities. And that, they consider, can only be achieved by focusing on this kind of discipline that they enact. The software probably makes superior use of dependencies compared to closed source, they argue, and should therefore try to address most vulnerabilities.
"We are but one voice in a space where consensus and sustainable solutions are the most important"they say from Google. Although they are still one of the great technology companies. "We hope this discussion will promote the best ideas and, ultimately, solutions that strengthen and streamline the open source security that we all depend on."
Via | ZDNet