Google announced Scorecards v2 with new security checks, a scaled-up number of projects being scored, and easy accessibility for analysis. Scorecards v2, developed in collaboration with Open Source Security Foundation, reduces the effort needed to evaluating changing packages when maintaining a project’s supply chain.
Automatically assesses the risks
It allows users to automatically assess the risks and use the data to help them evaluate alternative solutions or work with maintainers to make improvements. Google also added several new checks following the Know, Prevent, Fix framework:
- Malicious contributors: Contributors with malicious intent or compromised accounts can introduce potential backdoors into code. Code reviews help mitigate against such attacks. With the new Branch-Protection check, developers can verify that the project enforces mandatory code review from another developer before code is committed. Currently, this check can only be run by a repository admin due to GitHub API limitations. For a third-party repository, use the less informative Code-Review check instead.
- Vulnerable code: Despite best efforts by developers and peer reviews, vulnerable code can enter source control and remain undetected. That’s why it’s important to enable continuous fuzzing and static code analysis to catch bugs early in the development lifecycle. We have added checks to detect if a project uses Fuzzing and SAST tools as part of their CI/CD system.
- Build system compromise: A common CI/CD solution used by GitHub projects is GitHub Actions. A danger with these action workflows is that they may handle untrusted user input. Meaning, an attacker can craft a malicious pull request to gain access to the privileged GitHub token, and with it the ability to push malicious code to the repo without review. To mitigate this risk, Scorecard’s Token-Permissions prevention check now verifies that the GitHub workflows follow the principle of least privilege by making GitHub tokens read-only by default.
- Bad dependencies: Any software is as secure as its weakest dependency. This may sound obvious, but the first step to knowing the dependencies is simply to declare them and have the dependencies declare them too. Once we have this provenance information, we can assess the risks of the software and mitigate those risks. Unfortunately, there are several widely-used anti-patterns that break this provenance principle. The first of these anti-patterns are checked-in binaries, as there’s no way to easily verify or check the contents of the binary in the project. Scorecards provides Binary-Artifacts check for testing this.