Google-backed Scorecards bolsters open source security metrics with new checks

Let the OSS Enterprise newsletter guide your open source journey! Sign up here.

Google and its co-members at the Open Source Security Foundation (OpenSSF) have announced a major update to its open source security Scorecards project.

The OpenSSF, a Linux Foundation project launched last August and spearheaded by organizations such as Microsoft, GitHub, IBM, Red Hat, and Google, first announced Scorecards back in November. Its core purpose is to automatically create a security rating for open source projects, which in turn helps potential users (i.e. developers at major security-conscious enterprises) make a more informed decision about how to proceed with a specific open source component in their own software projects. For now, it only works with GitHub repositories, though the plan is to extend it to others in the future.

Vulnerabilities

For context, open source software adoption has accelerated in the enterprise and elsewhere, however vulnerabilities remain an ongoing threat – an estimated 84% of codebases contain at least one open source vulnerability. Moreover, supply chain attacks have hit the headlines in a major way these past six months following a spate of high-profile attacks such as SolarWinds, which highlights why it’s important for companies to properly evaluate external (open source) packages that they introduce to their applications.

With Scorecards version 2.0.0, which quietly rolled out two days ago, the OpenSSF has added a bunch of new security checks to the Scorecards mix. This includes a new branch-protection check, which developers can use to verify that the open source project they wish to use has a mandatory code review process in place from another developer — this is to ensure that bad actors with malicious intent don’t introduce backdoors to a codebase, for example. Additionally, Scorecards also now include checks to see whether a project uses fuzzing and SAST tools in their CI/CD process, which should go some way toward preventing vulnerabilities from entering a codebase.

Elsewhere, a new token-permissions prevention check will now verify that a project’s workflows “follow the principle of least privilege” by making GitHub tokens read-only by default, which Google said will help prevent malicious pull requests that attempt to gain access to a privileged GitHub token. And a new vulnerabilities check also helps to surface open source project vulnerabilities before they becomes a dependency in another project — this bypasses the need to subscribe to a separate vulnerability alert system.

It’s worth noting that Scorecards isn’t necessarily designed to steer companies away from specific open source projects. If a particular component generates a low rating, a company can decide to run their own tests on it to see how robust it really is, or they can decide to work with the project creators to improve it. After all, many open source project maintainers have inadequate resources to dedicate themselves to the job full-time, so a little extra support could go a long way.