Google announces Scorecard V4 in partnership with GitHub and OpenSSF | #linux | #linuxsecurity | #education | #technology | #infosec


The Open Source Security Foundation (OpenSSF), GitHub, and Google announced on Wednesday the launch of Scorecards V4, which includes larger scaling, a new security check, and a new Scorecards GitHub Action for easier security automation.

OpenSSF launched the Scorecards in November 2020, creating an automated security tool that produces a “risk score” for open source projects and helps reduce the toil and manual effort required to continually evaluate changing packages when maintaining a project’s supply chain.

Since Google and OpenSSF’s July 2021 announcement of Scorecards V2, the Scorecards project has grown steadily to over 40 unique contributors and 18 implemented security checks.

The Scorecards Action, released in partnership with GitHub, automates the process on how to judge whether changes to a project affected its security. Previously, tasks like this had to be done manually. 

The Action is available from GitHub’s Marketplace and is free to use. It can be installed on any public repository by following these directions.

“Since our July announcement of Scorecards V2, the Scorecards project—an automated security tool to flag risky supply chain practices in open source projects—has grown steadily to over 40 unique contributors and 18 implemented security checks. Today we are proud to announce the V4 release of Scorecards, with larger scaling, a new security check, and a new Scorecards GitHub Action for easier security automation,” said Google Open Source Security Team members Laurent Simon and Azeem Shaikh.

“The Scorecards Action is released in partnership with GitHub and is available from GitHub’s Marketplace. The Action makes using Scorecards easier than ever: it runs automatically on repository changes to alert developers about risky supply-chain practices. Maintainers can view the alerts on GitHub’s code scanning dashboard, which is available for free to public repositories on and via GitHub Advanced Security for private repositories.”

The two added that they have scaled their weekly Scorecards scans to over one million GitHub repositories and partnered with the Open Source Insights website for easy user access to the data.


The Open Source Security Foundation explained in a blog post that although the world runs on open-source software, many open source projects engage in at least one risky behavior — like not enabling branch protection, not pinning dependencies, or not enabling automatic dependency updates. 

“Scorecards makes it simple to evaluate a package before consuming it: a scan run with a single line of code returns individual scores from 0 to 10 rating each individual security practice (“checks”) for the project and an aggregate score for the project’s overall security. Today’s release of a Scorecards GitHub Action makes it easier than ever for developers to stay on top of their security posture,” the organization said. 

“The new Scorecards GitHub Action automates this process: once installed, the Action runs a Scorecards scan after any repository change. Maintainers can view security alerts in GitHub’s scanning dashboard and remediate any risky supply-chain practices introduced by the change.”

All of the alerts will now include the severity of the risk, the file and line where the problem occurs, and the remediation steps to fix the issue. The latest release also adds the License check, which detects the presence of a project license, and the Dangerous-Workflow check, which detects dangerous usage of the pull_request_target trigger and risks of script injections in GitHub workflows.

A number of open-source projects have already adopted the Scorecards Action, including Envoy, distroless, cosign, rekor, kaniko. 

“Scorecards provides us the ability to rapidly litmus test new dependencies in the Envoy project,” said Envoy’s Harvey Tuch. 

“We have found this a valuable step in vetting new dependencies for well-known attributes and we have integrated Scorecards into our dependency acceptance criteria. Machine checkable properties are an essential part of a sound security process.” 


Source link