The OpenSSF Best Practices badge program is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices.

https://www.bestpractices.dev/en

Projects that already follow ASF policies and conventions should generally have no problem achieving a 'passing' grade for the badge, and are encouraged to do so. This page provides some pointers that might be helpful, feel free to add additional information.

Start your project name with "Apache" so it shows up in the alphabetical listing at https://www.bestpractices.dev/en/projects?page=12&sort=name. It probably makes sense to manage your listing under a PMC or Security Team account, i.e. private@yourproject.apache.org or security@yourproject.apache.org.

Private vulnerability reporting

The "vulnerability_report_private" criterium is somewhat ambiguous, but for now we assume the ASF reporting mechanism is sufficient. In the future we might want to allow GitHub Private Vulnerability Reporting for projects that are using GitHub as well.

New functionality testing

The badge criteria require that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. While this is common for ASF projects, the Badge makes it a requirement.

Release notes

The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. According to ASF policy advisories are published 'at the same time as or after' a release. The Best Practices badge narrows this to 'at the same time as' the publication of release notes. For ASF projects this typically means the CVE will not be part of the release notes at the time of voting for the release, but are added when the release notes are published along with the release.

Vulnerability report initial response time

The vulnerability report initial response time has to be <= 14 days. This is the case for reports sent to security@apache.org (as for those the Apache Security Team provides an initial response within that timeframe). If your project has a public security list, it is up to you to send this initial response.


  • No labels