OpenSSF Best Practices Badge: criteria, self-certification, and vetting

BadgeApp turns FLOSS criteria into public self-certification

OpenSSF Best Practices Badge addresses a specific trust problem: users often cannot tell whether an open source project has basic information and security practices that make it easier to adopt, inspect, report problems to, and update. The project supplies a badging system for Free/Libre and Open Source Software, with two families of criteria. Its intended users are both maintainers, who want to document and display their practices, and downstream users, who want evidence that those practices exist.

The service is not a source-code scanner that makes the badge automatically. Its BadgeApp is described as a web application in which projects self-certify that they meet selected criteria and then display a resulting badge. This distinction matters. A submission can include factual claims and supporting evidence, but the existence of a badge should not be read as a claim that every release or every repository has been continuously inspected. The README points to separate passing-level criteria, criteria for all levels, and documentation about the vetting approach. Users who need the precise meaning of a particular level should consult those criteria rather than infer it from the badge graphic alone.

The project was formerly associated with the Core Infrastructure Initiative and is now part of the Open Source Security Foundation Best Practices Working Group. That history explains the continued reference to CII in discussion links while the current product and criteria use the OpenSSF Best Practices name. The public service is at bestpractices.dev, whereas the repository is the development site for the criteria and the application software.

Baseline and Metal series cover different assessment scopes

Choosing a series is the first practical decision a project must make. The OpenSSF Baseline series is described as a minimal checklist centered on MUST security requirements. It was derived partly from global cybersecurity regulations and frameworks. This makes it the smaller starting point for maintainers that want to address essential controls without completing the broader Metal series first.

The Metal series is larger. It includes security-related suggestions and quality issues, and the README says it was derived partly from experience with secure FLOSS projects. Its levels are named passing, silver, and gold. A maintainer therefore faces both an assessment-family choice and a level choice. The repository also contains criteria data under `criteria/`, while the README links a passing-level summary that covers items such as a stable project website, explicit FLOSS licensing, HTTPS, installation documentation, public version control, unique release versions, release notes, and documented ways to submit and track bugs.

The two families overlap in purpose but differ in assessment breadth. Baseline is the narrower route for mandatory security practices. Metal adds a larger body of security and quality criteria. The README encourages projects to complete both eventually, but it also says users can choose where to start. Treating the largest available badge as the only meaningful target would obscure that choice.

Rails repository structure separates criteria, API, and vetting

Based on the repository layout, BadgeApp is a Ruby application with the conventional separation suggested by directories such as `app/`, `config/`, `db/`, `lib/`, and `test/`. Rails-oriented files including `Gemfile`, `Gemfile.lock`, `config.ru`, and `Rakefile` are present. The README identifies `best_practices.openapi.yaml` as an API description and links `docs/api.md` for the application programming interface and data downloads. That layout points to a service with a web interface, persistent application data, and documented programmatic access, although the repository text does not expose endpoint definitions or request examples.

Criteria are not merely embedded in interface copy. The top-level `criteria/` directory suggests that they are maintained as project data, while `docs/criteria.md` is referenced for detailed requirements. Supporting concerns have their own documentation, including `docs/design.md`, `docs/implementation.md`, `docs/vetting.md`, and `docs/assurance-case.md`. This separation is useful for review because a change to a requirement, its implementation, and the assurance claimed for that requirement can be examined independently.

The repository also contains SBOM staging and production release records in its recent release history. Their names include October 2026 staging and production releases. The repository text does not explain their contents, generation method, or operational purpose, so they should not be treated as evidence of dependency scanning behavior. They do show that SBOM artifacts have a named release path within this repository.

Installation is documented in the repository guide

A prospective developer should start with the repository's installation guide rather than infer setup commands from the presence of a `Gemfile`. The README links `docs/INSTALL.md` as the Installation and quick start document. Its contents are not included in the README excerpt, so exact Ruby, database, package-manager, environment-variable, and startup commands cannot be reproduced without risking an inaccurate tutorial.

The available repository files do show the broad setup shape. Ruby version information appears in `.ruby-version` and `.tool-versions`. Dependencies are declared in `Gemfile` and `Gemfile.lock`. Deployment-related files include `Procfile`, `update-heroku-db`, and a `dockerfiles/` directory. Configuration is split between `.env`, Rails configuration under `config/`, and other environment-related files. None of those filenames is enough to produce a safe install command or identify a required database service.

For an end user who wants the first real use rather than local development, the README gives a different starting point: open the OpenSSF Best Practices website, review the criteria, and start the process to get a badge. The documented workflow is project self-certification followed by badge display. The README does not document rollback, submission rejection behavior, account recovery, or the exact evidence format without linking the website and vetting documentation.

Vetting and badge semantics are the main interpretation risk

The largest limitation is interpretive. This is a criteria and evidence system, not a guarantee that the resulting software is free from vulnerabilities. A project can document HTTPS, licensing, releases, contribution paths, and issue tracking while still shipping defects that those practices do not detect. Conversely, failing a criterion can expose a gap in the project's published development practices even when users can currently install and use the software.

The README maintains documentation about vetting and points to criteria for all levels. Users should inspect how a particular submission was assessed and what the selected level means. It does not say that every project receives the same depth of review, and the repository text does not specify review frequency, evidence retention, expiration behavior, or handling when a previously qualified project later stops meeting the criteria. Those omissions should prevent an adopter from interpreting the badge as a permanent security attestation.

The repository's own OpenSSF Scorecard badge link is another named security-oriented service, but the repository text does not describe Scorecard's assessment method. A factual method comparison with Scorecard is therefore not supportable from this repository text. The concrete alternative presented here is the project's Baseline versus Metal choice. Baseline uses a smaller MUST-focused checklist; Metal applies a broader set of security and quality requirements across passing, silver, and gold.

MIT licensing and deployment constraints require review

The repository is identified as MIT licensed, and the top-level `LICENSE` and `LICENSE.spdx` files support that attribution. The README itself carries the SPDX expression `MIT OR CC-BY-3.0+`, while also containing HTML badges and documentation text. Those file-level expressions should be reviewed when copying particular content, because the repository license statement and an individual file's declared terms are related but distinct facts. This article does not provide legal advice or determine which obligations apply to a particular reuse.

For operators, upgrade cost is tied to maintaining the accuracy of submitted project information and keeping the Rails deployment compatible with its dependencies. The repository is not archived, and the last push was on 2026-10-15. Recent releases include SBOM staging and production artifacts dated 2026-09-24 and 2026-10-02. The release names do not disclose migration notes, supported upgrade paths, or database migration requirements, so they cannot establish a particular upgrade procedure.

Node.js appears in `package.json`, but that file explicitly says the project is not a Node.js application and has no npm dependencies. The file pins Node.js for Heroku builds because the Ruby asset pipeline invokes Node.js through ExecJS and `terser`. It further states that the Heroku buildpack order must be configured or the pin has no effect. This is a deployment constraint, but it is secondary for users who only want to obtain a badge.

Editorial conclusion

Maintainers that can provide stable documentation, licensing, HTTPS, public version control, release records, and issue tracking should evaluate the service, while projects that need a narrowly automated dependency or vulnerability signal should first decide whether a criteria checklist is appropriate. Before adopting either series, verify the project's current evidence, the service's vetting terms, and the maintenance commitments required to keep its submission accurate.

Frequently asked questions

Official sources

1. License: MIT
2. ossf/best-practices-badge on GitHub
3. Project website
4. README
5. Releases