Google adds new checks to Scorecards, an automated tool that scans open-source software for security risks

Google LLC today announced a big update to the Scorecards project, which is an automated security tool that generates a “risk score” for open-source software projects.

The Scorecards tool was launched in November 2020 by Google and the Open Source Security Foundation. The goal was to help companies decide if they should adopt a given open-source software project based on things such as its security posture and its level of trust.

Although some companies have systems and processes in place to assess open-source software dependencies, most organizations do not. As a result, they can unwitting adopt vulnerability-ridden software in some of their most critical projects.

Scorecards works by auto-generating a risk score for any open-source project based on metrics such as its security policy, a code review and continuous test coverage using fuzzing and static code analysis tools. Google is one of the main contributors to Scorecard and in a blog post, it announced a number of new features in the Scorecards v2 release today.

“With so much software today relying on open-source projects, consumers need an easy way to judge whether their dependencies are safe,” Google Open Source Securuty Team members Kim Lewandowski, Azeem Shaikh and Laurent Simon wrote. “Scorecards helps reduce the toil and manual effort required to continually evaluate changing packages when maintaining a project’s supply chain. Consumers can automatically assess the risks that dependencies introduce and use this data to make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.”

The updated Scorecards adds a number of new security checks. One of the most important ones helps guard against contributors to projects that have malicious intent. That’s important because one of the main ways vulnerabilities are introduced into code is though malicious contributors that appear to be helping to develop a project, only to slip a bug inside code that otherwise improves or adds new functions.

The new Branch-Protection check will ensure that when an update is made to an open-source project, a mandatory code review from another developer is enforced before it can be submitted.

A second new check helps ensure that a project uses continuous quality assurance tolls such as fuzzing and Static Application Security Testing to try to catch more innocent vulnerabilities that slip into its code on a regular basis.

The new Token-Permissions prevention check, meanwhile, helps to protect against attackers that try to create a malicious pull request in order to gain access to privileged GitHub tokens, and with that add some malicious code without its being reviewed first.

Other new checks are designed to ensure that all of a project’s software dependencies have been declared, so they can then be reviewed. They include the Binary-Artifacts check, the Frozen-Deps check and the Automated-Dependency-Update check.

Google’s Open Source Security Team also shed more light on the scope of the Scorecards project so far. It explained that the project has scaled up to evaluate criteria for more than 50,000 open-source projects. To do this, the team redesigned Scorecards’ architecture and used a PubSub model that achieved higher throughput and greater horizontal scalability.

“This fully automated tool periodically evaluates critical open-source projects and exposes the Scorecards check information through a public BigQuery dataset which is refreshed weekly,” the team explained.

The data from Scorecards’ checks is available publicly via the new Google Open Source Insights project and the OpenSSF Security Metrics project. Interestingly, the data shows that even some of the most widely used and critical open-source packages, such as the Kubernetes container orchestrator, still need improvement.

“As we can see, a lot needs to be done to improve the security of these critical projects. A large number of these projects are not continuously fuzzed, do not define a security policy for reporting vulnerabilities, and do not pin dependencies, to name just a few common problems,” Google’s team wrote. “We all need to come together as an industry to drive awareness of these widespread security risks, and to make improvements that will benefit everyone.”

Image: mohamed_hassan/pixabay