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

Google has launched an updated version of Scorecards^[1], 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^[2]
Thursday. “Scorecards helps reduce the toil and manual effort
required to continually evaluate changing packages when maintaining
a project’s supply chain.”

Scorecards^[3]
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^[4] 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^[5]
check. This check is helpful for mitigating against malicious
dependency attacks such as the recent CodeCov^[6]
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^[7]) to ensure the integrity
of software artifacts and prevent unauthorized modifications over
the course of the development and deployment pipeline.