By Spencer Schrock and Raghav Kaul, Google Open Source Security Team
OpenSSF Scorecard is a way for maintainers and users of open source projects to better understand the security of a given project. Maintainers can get feedback on the security of their project, and suggestions on how to make it more secure. Users of open source software can use Scorecard results to make informed decisions about projects of interest.
We regularly scan 1.2 million repos, and make the results available on our website. For complete usage instructions, be sure to visit our README.
Highlights of the Past Few Months
In addition to routine bug fixes, our efforts have been centered around two major features.
Scorecard Result Diffing Tool (scdiff):
We have introduced a new tool called scdiff, which is designed to detect regressions by comparing Scorecard results. Scorecard maintainers can utilize this tool while assessing pull requests and it is also incorporated into our release process. By identifying potential issues early on, we aim to prevent mistakes from being carried over to releases, making Scorecard scores more deliberate over time.
Structured Results:
A significant portion of our efforts has been dedicated to Structured Results. A fundamental challenge with Scorecard is the subjective nature of scoring. However, as part of our evaluation, we collect objective data on a repository’s contents and practices. Structured Results is the name we have given to the process of exposing this information. Over the past few months, we have been restructuring our codebase to divide our 19 checks into distinct probes.
New and Upcoming Initiatives
We are getting ready to launch Structured Results, which will enable users to set their own policies regarding Scorecard checks.
Additionally, it’s difficult to have accurate heuristics on 1.2M+ repos. OpenSSF Scorecard struggles to accurately detect everything. So we’re introducing maintainer annotations, which will allow project maintainers to correct a score and provide a reason. We’re still working on how these annotations will factor into the results.
Finally, the OpenSSF Scorecard website, including documentation and API is changing from securityscorecards.dev to scorecard.dev. The new site is up and running. We’ll continue to host api.securityscorecards.dev for 12 months, afterwhich the API will redirect to api.scorecard.dev. Migrate your applications, or ensure you follow redirects.
Get Involved
We’re always looking for ways to improve the OpenSSF Scorecard project. If you are interested in helping us make OpenSSF Scorecard more usable, fixing bugs, adding new probes, or support for new ecosystems, please contribute!
We are creating a survey to gather insights on how OpenSSF Scorecard is used. If you are interested in participating, please keep an eye out for the survey on the website, GitHub, and other channels in the coming months.
Join our meetings:
The community meets biweekly on Thursdays at 1:00-2:00 PM Pacific (APAC-friendly) and every 4 Mondays at 7:00-8:00 AM Pacific (EMEA-friendly). Each meeting can be found on the OpenSSF Public Calendar.
Learn more:
Mark your calendar for an OpenSSF Scorecard Tech Talk on March 13 at 10 AM PT – a free virtual event discussing Scorecard’s significance, sharing organizations’ experiences, providing implementation insights, and exploring future prospects. Register today.
About the Authors
Spencer Schrock is a software engineer on the Google Open Source Security Team, where he works on Software Supply Chain Integrity for both open source and Google. He is a maintainer of the OpenSSF Scorecard project.
Â
Raghav Kaul is a Software Engineer on the Google Open Source Security Team working on Scorecard and Allstar.