How OpenSSF Dashboards Can Help Assess Open Source Software Risk


Everyone knows the expression “software eats the worldby Marc Andreessen more than ten years ago. Software powers and touches nearly every aspect of modern society, both personally and professionally, and is essential to the modern economy and national security.

It can also be said that open source software (OSS) has eaten up the software industry. The Linux Foundation and other groups have valued that free and open source software (FOSS) constitutes 70% to 90% of any modern software product. Not only is modern software largely comprised of OSS components, but IT managers are more likely work with vendors who also contribute to the OSS community.

The use of OSS is rampant due to its flexibility, cost savings, innovation through community projects, and arguably better security through more eyeballs on code, especially for major OSS projects. That said, OSS has its own concerns, including common vulnerabilities and exposures (CVEs) for affected code.

CVE is a MITER project that strives to “identify, define and catalog publicly disclosed cybersecurity vulnerabilities”. However, as the Cloud Native Computing Foundation (CNCF) Software Supply Chain Best Practices white paper notes, CVEs are an “end metric,” meaning they list vulnerabilities that have summer publicly disclosed. This is also just one type of risk associated with software.

For this reason, organizations must use other methods to assess the security status of the OSS projects they consume. One of the most notable is that of the Open Source Security Foundation (OpenSSF) Dashboards project.

What are OpenSSF Scorecards for open-source projects?

Announced in late 2020, Scorecards aims to automatically generate a security score for OSS projects to help consumers and organizations make informed risk decisions regarding their OSS consumption. Organizations make heavy use of OSS dependencies, but determining the risk of consuming these dependencies remains a largely manual activity, especially at scale in the software ecosystem. The Scorecards project seeks to alleviate some of this burden by using automated heuristics and security checks on a rating scale of 0 to 10. It does this while evaluating OSS projects for security issues that align with best practices such as signature or SAST, already advocated by public and private security officials.

OpenSSF scorecards Chris Hughes

OpenSSF Scorecards uses tiered scoring for risk severity levels.

The Scorecards project isn’t aiming low either, it analyzes the one million most critical OSS projects based on direct dependencies and publishes the results to a public dataset on a weekly basis. In addition to leveraging this publicly available dataset, organizations can also run scorecards on their own GitHub projects using GitHub Actions. When there is a change in the repository, the GitHub action runs and provides alerts to the maintainers of those projects.

The Scorecards project uses a critical, high, medium, and low rating scale, which are levels of severity that most security practitioners are familiar with. It also uses a standard list of checks that it runs on all projects you target it for, whether they’re public projects or, if you’re using it natively, your own GitHub repositories.

You can dive into what some of these controls are. They include fundamental security practices such as using branch protection, cryptographically signing releases, and having unpatched vulnerabilities. To detect the presence of unpatched vulnerabilities, the Scorecards project uses the OSV Vulnerability Database. It is a distributed vulnerability database for OSS that uses the OpenSSF OSV format. OSV, at its core, is an aggregation of other vulnerability databases using the OSV schema, such as GitHub Security Advisories and the Global Security Database, among others. OSC also supports APIs and Command Line Interface (CLI) tools to analyze SBOMs in CycloneDX or SPDX formats.

The Scorecards project meets every two weeks and has an active Slack channel. It is led by facilitators from companies such as Google, Datto and Cisco. Since its inception, Scorecards has grown in popularity and is listed as having over 3,000 Stargazers, or users who have essentially bookmarked the project. As organizations continue their efforts to mature their free software consumption governance practices, the project will inevitably grow in popularity.

How can organizations use OpenSSF scorecards?

The ability of organizations to conduct due diligence, governance, and risk management of their free software consumption is still in its infancy. We are seeing a strong push to strengthen the software supply chain resilience and software supply chain security practices of mature organizations. We got NISTs Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations Rev.1, Secure Software Development Framework (SSDF)the OpenSSF OSS Security Mobilization Plan, Supply Chain Levels for Software Artifacts (SLSA), and other emerging best practices and sources of guidance. All touch on the need to govern an organization’s consumption of OSS and ensure that consumption aligns with the organization’s risk tolerance.

While this may seem simple, the idea of ​​doing this across the whole robust ecosystem of OSS projects and components that organizations consume is not so trivial. OpenSSF’s Scorecards project provides an automated way to get security and risk insights into over a million leading OSS projects, as well as use the project natively for their own software and projects. internal to the organization.

Organizations can use Scorecards through the CLI for projects they don’t own as well as use a package manager for projects such as npm, PyPi, or RubyGems. Scorecards is also available as a Docker container.

Organizations and individual contributors can participate in the project, including submitting needs checks to be considered for scoring assessment. Organizations can also customize their use of Scorecards and run only specific checks, potentially aligned with their organizational or industry-specific security requirements.

For more specific guidance, organizations can refer to NIST Recommended Practices for Open Source Software Controls, which were issued in response to Cybersecurity Executive Order (EO) 14028, Improving the Nation’s Cybersecurity. These include tiered capabilities based on the maturity of the organization at three levels: foundational, sustaining, and enhancing. Within these levels are capabilities such as using Software Composition Analysis (SCA) source code scans to identify vulnerable components, prioritizing the use of programming languages ​​with guardrails integrations and automating the process of collecting, storing and analyzing OSS components in hardened internal repositories. before introducing them into production environments.

Copyright © 2022 IDG Communications, Inc.


Comments are closed.