What is 'Know, Prevent, Fix' to increase the security of open source projects proposed by Google?
Many software development projects employ open source, which allows free use, modification, and distribution of source code, both commercial and non-commercial, but open source software carries certain security risks. I will. On its official security blog, Google advocates a framework called ' Know, Prevent, Fix ' about the vulnerabilities of open source software.
Google Online Security Blog: Know, Prevent, Fix: A framework for shifting the discussion around vulnerabilities in open source
Open source: Google wants new rules for developers working on'critical' projects | ZDNet
https://www.zdnet.com/article/open-source-google-wants-new-rules-for-developers-working-on-critical-projects/
Open source projects are freely developed by volunteers. As a result, quality is not always guaranteed and there is no solid support. Google has proposed the following three frameworks for dealing with the security risks of open source software.
◆ 1: 'Know' about software vulnerabilities
First, Google argues that it's important to capture vulnerability metadata from all available data sources. For example, knowing which version the vulnerability occurred in can help you determine if your software will be affected.
Google also argued that an industry-standard framework for information about vulnerabilities was needed to track vulnerabilities in open source software. If the format of information dealing with vulnerabilities is unified within the industry, it will be easier to track vulnerabilities because a common method can be used across multiple vulnerability databases.
In addition, Google points out that most vulnerabilities are dependent on libraries and packages rather than the software source code itself. Source code, especially in Java and JavaScript, often has thousands of dependencies on libraries and packages, making it very difficult to find vulnerabilities. That's why Google says it's important to accurately track software dependencies, but says that this process should be automated because it's unrealistic to actually monitor it manually. ..
◆ 2: 'Prevent' the addition of new vulnerabilities
It is desirable to use testing and analysis tools to prevent new vulnerabilities from being added, but as an earlier issue, preventive measures to prevent new vulnerabilities from being added are also important. To that end, Google cites two things: 'Understanding the risks of determining new dependencies' and 'Improvement of the development process.'
Building dependencies with libraries and packages carries certain risks, and once a dependency is built, it becomes more difficult to remove over time as the software version progresses. Therefore, Google explains that it is important to understand the risks of introduction in advance in order to use new libraries and packages.
In addition, Google points out that many vulnerabilities are caused by low security awareness in the development process. Security risks in the development process, such as 'whether all people involved in development adopt two-factor authentication', 'whether regular builds and tests employ
◆ 3: 'Fix' the vulnerability
In order to fix a vulnerability in a development project, Google says, 'How others modified the code,' 'Where is it stopped in the process,' and 'Who is responsible for fixing the vulnerability?' He argues that it is necessary to understand 'who is accountable', and that a mechanism for notifying the discovery and correction of vulnerabilities is also required.
And the most troublesome part of fixing a vulnerability is the version requirement. Google says it's important to fix vulnerabilities in older versions, especially the most commonly used versions, as well as newer ones, and ideally all widely used versions should be fixed. However, it's difficult to fix all versions manually, so if one version is fixed, a system that automatically fixes the other version would also help, Google said.
However, there are many cases where the above problems cannot be used to deal with ' supply chain attacks ' that are loaded with malware during open source development. When developing critical software in open source, Google 'doesn't make arbitrary changes to the software code and is always checked' 'requests a third party for independent code review' 'project owners and maintainers' Must never be anonymous, 'two-factor authentication by owners and maintainers,' and 'maintaining the transparency and reliability of the build process.'
Related Posts:
