Google proposes to establish new rules to improve open source security

The security of open source software has attracted the attention of the industry, but solutions require consensus on challenges and cooperation in implementation.

The problem is complex and there are many facets to cover, from the supply chain, dependency management, identity, among other things. To do this, Google recently released a framework ("Know, Prevent, Fix") that explains how the industry can think about vulnerabilities in open source and specific areas that must be addressed first.

Google explains its reasons:

“Due to recent events, the software world has gained a deeper understanding of the real risk of supply chain attacks. Open source software should be less risky from a security perspective, as all code and dependencies are open and available for inspection and verification. And while this is generally true, it is assumed that people are actually doing this inspection work. With so many dependencies, it is impossible to monitor all of them and many open source packages are not well maintained.

“It is common for a program to depend, directly or indirectly, on thousands of packages and libraries. For example, Kubernetes now depends on around 1000 packages. Open source probably uses dependencies rather than proprietary software and comes from a wider range of vendors; the number of independent entities that can be trusted can be very large. This makes it extremely difficult to understand how open source is used in products and what vulnerabilities may be relevant. There is also no guarantee that what is built will match the source code.

Within the framework proposed by Google, it is suggested to divide this difficulty into three largely independent problem areas, each with specific objectives:

Know the vulnerabilities of your software

Knowing your software vulnerabilities is more difficult than you might expect for many reasons. Yes OK mechanisms exist to report vulnerabilities, it is unclear if they really affect the specific versions of the software you are using:

  • Goal: Accurate Vulnerability Data: First, it is critical to capture accurate vulnerability metadata from all available data sources. For example, knowing which version introduced a vulnerability helps determine if the software is affected, and knowing when it has been patched results in accurate and timely fixes (and a narrow window for possible exploitation). Ideally, this classification workflow should be automated.
  • Second, most vulnerabilities lie in your dependencies, rather than in the code that you write or control directly. So even when your code doesn't change, the landscape of vulnerabilities affecting your software can constantly change - some are fixed and some are added.
  • Purpose: Standard schema for vulnerability databases Infrastructure and industry standards are required to track and maintain open source vulnerabilities, understand their consequences, and manage their mitigations. A standard vulnerability scheme would allow common tools to run on multiple vulnerability databases and simplify the task of tracking, especially when vulnerabilities cross multiple languages ​​or subsystems.

Avoid adding new vulnerabilities

It would be ideal to avoid the creation of vulnerabilities And while testing and analysis tools can help, prevention will always be a difficult subject.

Here, Google proposes to focus on two specific aspects:

  • Understand the risks when deciding on a new dependency
  • Improve critical software development processes

Repair or remove vulnerabilities

Google acknowledges that the general problem of repair is beyond its purview, but the publisher believes there is much more that actors can do to address the problem specific to manage vulnerabilities in dependencies.

It also mentions: 

“Today there is little help on this front, but as we improve accuracy, it is worth investing in new processes and tools.

“One option, of course, is to patch the vulnerability directly. If you can do this in a backward compatible way, the solution is available to everyone. But the challenge is that you are unlikely to have experience with the problem or the direct ability to make changes. Fixing a vulnerability also assumes that those responsible for maintaining the software are aware of the problem and have the knowledge and resources to disclose the vulnerability.


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

A comment, leave yours

Leave a Comment

Your email address will not be published. Required fields are marked with *



  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   José Antonio said

    The original in English says:

    Here we focus on two specific aspects:

    - Understanding risks when deciding on a new dependency

    - Improving development processes for critical software

    The version "LinuxAdictos" says:

    Here, Google proposes to focus on two specific aspects:

    - Understand the risks when choosing a new addiction.

    - Improvement of critical software development processes

    A new addiction !?