For IT practitioners, Marc Andreessen's idea of ​​"software eating the world" a decade ago is familiar.Whether in private life or the public sphere, software powers every aspect of modern society and is critical to modern economies and national security.

It is also a very popular view in recent years that open source has swallowed the software world.The Linux Foundation has predicted that Free Open Source Software (FOSS) accounts for 70% to 90% of modern software.Not only are modern software made up of a large number of open source components, but practitioners in the IT industry are also more willing to work with vendors who contribute to the open source community.

Open source software is widely used because of its flexibility, low cost, and the ability to drive innovation through community-based projects, and because of the collaborative participation of many people, the project can achieve better security, especially for large open source projects.Nonetheless, open source software has its own set of problems, including common vulnerabilities and exposures (CVEs) in the affected code.

CVE is a MITRE project dedicated to "identifying, defining, and classifying publicly disclosed cybersecurity vulnerabilities."However, the CNCF states in its Software Supply Chain Best Practices white paper that CVEs are "post-mortem indicators," meaning that the vulnerabilities they enumerate have all been publicly disclosed.They are also just one type of risk associated with software.

For this reason, organizations should use other methods to assess the security status of the open source projects they use.One of the most well-known projects is the Open Source Security Foundation (OpenSSF) Scorecards project.

Project address: https://github.com/ossf/scorecard

What are OpenSSF Scorecards?

Scorecards is designed to automatically generate security indices for open source projects to help project users and organizations make risk-informed decisions.Enterprises are making heavy use of open source dependencies, but identifying the risks of those dependencies is still a manual job.The Scorecards project aims to lighten the load with automated heuristics and safety checks, resulting in a safety index on a 0 to 10 scale.It aligns with best practices advocated by security leaders, such as signing or SAST, when evaluating security issues for open source software projects.

OpenSSF ScorecardsStratified scoring for risk severity

Scorecards can scan 1 million of the most critical open source projects based on direct dependencies and regularly publish the results on a public dataset.In addition to leveraging publicly available datasets, businesses can also use GitHub Actions to run Scorecards against their own GitHub projects, which run when the repo changes and provide alerts to the maintainers of those projects.

The Scorecards project uses a [Critical] [High] [Medium] [Low] scoring scale that is familiar to most security practitioners.It also uses a standard checklist to check against your target projects, whether public projects or private projects used natively.

You can also dive into some of these checks, including basic security practices such as using branch protection, cryptographically signed releases, and the presence of unfixed vulnerabilities.The Scorecards project uses the OSV vulnerability database (osv.dev) to detect the presence of unfixed vulnerabilities.This is a distributed vulnerability database designed for open source projects in OpenSSF OSV format.The core of OSV is to aggregate other vulnerability databases that use the OSV schema, such as GitHub Security Advisories and the Global Security Database.OSC also supports API and Command Line Interface (CLI) tools for scanning SBOMs in CycloneDX or SPDX format.

The Scorecards project has bi-weekly meetings and a Slack channel.Led by engineers from companies like Google, Datto, and Cisco, it has nearly 3,000 stars since its inception, and users have added it to their favorites.As enterprises continue to drive the maturity of their open source software adoption governance practices, the project will inevitably gain traction.

How does a business use OpenSSF Scorecards?

Currently, the governance and risk management capabilities of enterprises for open source software are still in their infancy.The frequent occurrence of software supply chain attacks in recent years will be a huge impetus for companies to strengthen their software supply chain security practices.We currently have the OpenSSF Security Mobilization Program, SLSA, the Secure Software Development Framework (SSDF), and other best practice guidelines.All of this involves managing the enterprise's use of open source software and ensuring that such use is consistent with the enterprise's tolerance for risk.

As simple as it sounds, doing this across a robust ecosystem of open source projects and components is challenging.OpenSSF's Scorecards project provides an automated way to gain security and risk insight into more than 1 million OSS projects and use that project directly for their own software and in-house projects.

Enterprises can use Scorecards via the CLI for projects they don't own, or use a package manager for projects like npm, Pypi, or RubyGems.Scorecards are also available as Docker containers.

Business and individual developers can participate in the program, including submitting requirements checks for scoring evaluation.Organizations can also customize their use of Scorecards, such as to run only specific checks, or to align with specific security requirements in their industry.