New Google Scorecards Tool Scans Open-Source Software for More Security Risks

Google has launched an updated version of Scorecards, its automated security tool that produces a "risk score" for open source initiatives, with improved checks and capabilities to make the data generated by the utility accessible for analysis.

"With so much software today relying on open-source projects, consumers need an easy way to judge whether their dependencies are safe," Google's Open Source Security Team said Thursday. "Scorecards helps reduce the toil and manual effort required to continually evaluate changing packages when maintaining a project's supply chain."

Scorecards aims to automate analysis of the security posture of open source projects as well as use the security health metrics to proactively improve the security posture of other critical projects. To date, the tool has been scaled up to evaluate security criteria for over 50,000 open source projects.

Some of the new additions include checks for contributions from malicious authors or compromised accounts that can introduce potential backdoors into code, use of fuzzing (e.g., OSS-Fuzz), and static code analysis tools (e.g., CodeQL), signs of CI/CD compromise, and bad dependencies.

"Pinning dependencies is useful everywhere we have dependencies: not just during compilation, but also in Dockerfiles, CI/CD workflows, etc," the team said. "Scorecards checks for these anti-patterns with the Frozen-Deps check. This check is helpful for mitigating against malicious dependency attacks such as the recent CodeCov attack."

Google also noted that a large number of analyzed projects are not continuously fuzzed, and that neither do they define a security policy for reporting vulnerabilities nor do they pin dependencies, while also underscoring the need to improve the security of these critical projects and drive awareness of the widespread security risks.

The release of Scorecards v2 comes weeks after the company previewed an end-to-end framework called "Supply chain Levels for Software Artifacts" (or SLSA) to ensure the integrity of software artifacts and prevent unauthorized modifications over the course of the development and deployment pipeline.

Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post.