“A CII Best Practices badge, especially a gold badge, shows that an OSS project has implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found.” – David A. Wheeler, Director of Open Source Supply Chain Security
Open source software (OSS) is now widely used by many organizations. But with that popularity, that means the security of OSS is now more important than ever. The CII Best Practices badge project — including its top-ranked “gold” badge — helps improve that security.
In June 2020, two different projects managed to earn a gold badge: the Linux kernel and curl. Both are widely depended on, and yet in many other ways, they are radically different. The Linux kernel has a large number of developers, and as a kernel, it must directly interact with a variety of hardware. Curl has a far smaller set of developers and is a user-level application. They join other projects with gold badges, including the Zephyr kernel and the CII Best Practices badge application itself. Such radically different projects managed to earn a gold badge and thus demonstrated their commitment to security. It also shows that these criteria can be applied even to such fundamentally different programs.
But what are these badges? A Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Open Source Software (OSS) projects to show that they follow best practices. The badges let others quickly assess which projects are following best practices and are more likely to produce higher-quality secure software. It also helps OSS projects find areas where they can improve. Over 3,000 projects participate in the badging project, a number that grows daily.
There are three badge levels: passing, silver, and gold. Each level requires that the OSS project meet a set of criteria; for silver and gold that includes meeting the previous level. Each level requires effort from an OSS project, but the result is reduced risks from vulnerabilities for both projects and the organizations that use that project’s software.
The “passing” level captures what well-run OSS projects typically already do, and has 66 criteria grouped into six categories. For example, the passing level requires that the project publicly state how to report vulnerabilities to the project, that tests are added as functionality is added, and that static analysis is used to analyze software for potential problems. Getting a “passing” badge is an achievement, because while any particular criterion is met by many projects, meeting all the requirements often requires some improvements to any specific project. As of June 14, 2020, there were 3195 participating projects, and 443 had earned a passing badge.
The silver and gold level badges are intentionally more demanding. The silver badge is designed to be harder but possible for one-person projects. Here are examples of silver badge requirements (in addition to the passing requirements):
- The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language.
- The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (a whitelist) and reject invalid inputs if there are any restrictions on the data.
The gold badge adds additional requirements. Here are examples of gold badge requirements (in addition to the silver requirements):
- The project MUST have a “bus factor” of 2 or more (a “bus factor” is the minimum number of project members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel).
- The project MUST have at least 50% of all proposed modifications reviewed before release by a person other than the author.
- The project MUST have a reproducible build.
- The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values.
Historically the LF has focused on getting projects to the passing level because projects not even at the passing level have a higher risk. But many projects are widely depended on or are especially important for security, and we love to see them earning higher-level badges.
Of course, a gold badge doesn’t mean that there are no vulnerabilities in the existing code, or that it’s impossible to improve their development processes. Perfection is rare in this life. But a CII Best Practices badge, especially a gold badge, shows that an OSS project has implemented a large number of good practices to keep the project sustainable, counter vulnerabilities from entering their software, and address vulnerabilities when found. Projects take many such steps to earn a gold badge, and it’s a good thing to see.
We hope other projects will be inspired to pursue — and earn — a gold badge. Of course, the real goal isn’t a badge — the real goal is to make our software much more secure. But good practices can help make our software more secure, and we want to praise and encourage projects to have good practices.
For more background information on the best practices badge, see the presentation “Core Infrastructure Initiative (CII) Best Practices Badge in 2019”.
OSS projects can go to the CII Best Practices badge website to begin the process of earning a badge. If you’re considering the use of some OSS, we encourage you to check that website to see which projects have earned a badge.
Those who wish to learn more are welcome to contact David A. Wheeler, Director of Open Source Supply Chain Security at The Linux Foundation, at dwheeler AT linuxfoundation DOT org.
- Dent Introduces Industry’s First End-to-End Networking Stack Designed for the Modern Distributed Enterprise Edge and Powered by Linux - 2020-12-17
- Open Mainframe Project Welcomes New Project Tessia, HCL Technologies and Red Hat to its Ecosystem - 2020-12-17
- New Open Source Contributor Report from Linux Foundation and Harvard Identifies Motivations and Opportunities for Improving Software Security - 2020-12-08