BadgeApp

The only job assigned special permissions is the special deployment task. All others only have the privileges necessary to download the code, install tools locally in that container, and run the tools to determine and report analysis results.

None of the three CI/CD workflows (.github/workflows/main.yml, codespell.yml, scorecard.yml) define any workflow_dispatch inputs or other explicit collaborator-triggered input parameters. All workflows trigger only on automated events (push, pull_request, schedule, branch_protection_rule).

Since there are no manual workflow inputs to sanitize, the criterion is vacuously satisfied — there is no attack surface of this type to protect.

Supporting evidence:

• grep for workflow_dispatch across all workflow files returns zero matches.
• The existing input validation (OSPS-BR-01.02's script/validate_branch_name) handles environment-provided values like GITHUB_REF_NAME, which is a different concern (automated trigger context, not collaborator-supplied input).

Conclusion: The project meets OSPS-BR-01.04 because it has no pipelines that
accept trusted-collaborator input (no workflow_dispatch with inputs, no
manual triggers with parameters). If such inputs are added in the future,
they would need to be validated before use.

The primary single user uses git commit records to identify releases. [version_unique]

See docs/secrets-policy.md for the policy and processes for managing secret/credentials, including rotating them.

Releases are not intended for widespread use in many different sites, so this is N/A. [signed_releases]

Releases are not intended for widespread use in many different sites, so this is N/A. [signed_releases]

Our releases are intended for use in a single website that we maintain, and the support ends when we update the production branch.

As the intended use is a single website, we simply stop updating all previous versions, and only support the current version.

See docs/governance.md especially our "Escalated permissions policy". This updated policy was approved by the Best Practices Badge TSC in 2026.

See docs/sbom.md. Every time we push to the staging or production branch, as part of the build process we generate an SPDX SBOM and record it. We provide a script scripts/get-sbom to make it easy to acquire the SBOM information given a commit ID. Commits to production are the closest thing we have to a "release". We also document the REST API for retrieving a SPDX SBOM of the current main branch, though that isn't really a release.

We don't use multiple source code repositories for the project.

Yes, it includes a test suite based on minitest (the test framework that comes with Rails). [test]

Yes, this is a documented policy in CONTRIBUTING.md which says:

When adding or changing functionality, please include new tests for them as part of your contribution. [test_policy_mandated]

We have a policy in CONTRIBUTING.md that modifications other than low-risk modifications be reviewed by someone else, and a stated goal of having at least 50% of all proposed modifications to be reviewed. [two_person_review]

The security requirements and assurance case are documented in docs/security.md. [assurance_case]

We don't have any known vulnerabilities in components we use. When a dependency has a vulnerability, we generally simply update it to a not-vulnerable version, even if we believe it won't affect us, because that's a stronger defense than a possibly-flawed analysis.

External dependency checking is performed in two ways:

• bundle_audit. This checks all gems for known vulnerabilities. This is run on every execution of the "rake" local check task and on every run of the continuous integration task on CircleCI.
• Gemnasium. This also checks gems for known vulnerabilities, and puts the current status on a badge that is displayed on the front page of the project home page.

For the few external dependencies that aren't managed as gems (e.g., PostgreSQL) the system package managers and/or the deployment system's managers are used to maintain them & periodically check them. [dependency_monitoring]

External dependency checking is performed in two ways:

• bundle_audit. This checks all gems for known vulnerabilities. This is run on every execution of the "rake" local check task and on every run of the continuous integration task on CircleCI.
• Gemnasium. This also checks gems for known vulnerabilities, and puts the current status on a badge that is displayed on the front page of the project home page.

For the few external dependencies that aren't managed as gems (e.g., PostgreSQL) the system package managers and/or the deployment system's managers are used to maintain them & periodically check them. [dependency_monitoring]

External dependency checking is performed in two ways:

• bundle_audit. This checks all gems for known vulnerabilities. This is run on every execution of the "rake" local check task and on every run of the continuous integration task on CircleCI.
• Gemnasium. This also checks gems for known vulnerabilities, and puts the current status on a badge that is displayed on the front page of the project home page.

For the few external dependencies that aren't managed as gems (e.g., PostgreSQL) the system package managers and/or the deployment system's managers are used to maintain them & periodically check them. [dependency_monitoring]

This is vacuously true, since we've had no reports of vulnerabilities that apply to a deployed system. [static_analysis_fixed]

As noted in https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md, Brakeman, Rubocop, and rails_best_practices are used to analyze the Ruby code. Brakeman is specifically designed to analyze Ruby on Rails code. The Javascript client-side code is analyzed with ESLint, using over 100 rules.

These analysis tools are used as part of the default 'rake' process used in local development, as well as the "pronto" process run on the continuous integration server running on CircleCI. [static_analysis]