Were you unable to attend Transform 2022? Check out all of the summit sessions in our on-demand library now! Watch here.
Let the OSS Enterprise newsletter guide your open source journey! Sign up here.
The OpenSSF, a Linux Foundation project launched last August and spearheaded by organizations including Microsoft, GitHub, IBM, Red Hat, and Google, first announced Scorecards in November. Its core purpose is to automatically create a security rating for open source projects, which in turn helps potential users (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, Scorecards only works with GitHub repositories, though the plan is to extend it to others in the future.
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 the 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.
MetaBeat will bring together thought leaders to give guidance on how metaverse technology will transform the way all industries communicate and do business on October 4 in San Francisco, CA.
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. These include 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 become 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.
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.