A release that fixes a publicly known run-time vulnerability names it in the changelog
A reader deciding whether an upgrade is urgent is asking one question, and a fixed vulnerability they can look up is the fact that answers it. Scoping this to what reached users is what keeps the Security group worth reading: a vulnerability in a development-only dependency never reached one, and a Security heading that cries wolf over those is one readers stop opening. A build toolchain is on the other side of that line whenever the project ships what the toolchain produced.
Observable check
the changelog entry for each release that resolved a publicly known vulnerability in the shipped code or in a run-time dependency names every such vulnerability under Security, each by an identifier from a published advisory. A development-only dependency is not a run-time vulnerability. Where the project ships a built artifact, its build toolchain is one, because a compromised bundler or code generator injects into the thing users install; where the project ships only source, a build-only dependency stays outside. On GitHub, gh api repos/{owner}/{repo}/dependabot/alerts?state=fixed reports which advisories were resolved and when, which is what locates them in a release; on GitLab, the project's vulnerability report carries the same and requires Ultimate, so a Free project resolves it from the advisory identifiers its scanner job recorded. A project that has fixed no publicly known run-time vulnerability falls outside this rule rather than satisfying it with nothing to check.
Where this comes from
Last read against these sources on 2026-07-30.
OpenSSF Best Practices badge Passing, criterion 'release_notes_vulns', MUST with N/A allowed and a justification required: '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. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A.' Keep a Changelog 2.0.0 names the group the entry lives in, Security, 'in case of vulnerabilities'. Two parts of this rule go past the badge and are this project's own position. The badge scopes to project results and excludes dependencies; this rule covers a run-time dependency too, because a user deciding whether to upgrade is asking one question and cannot tell whose code the vulnerability was in. The badge also says run-time and stops there, so counting a build toolchain as run-time where the project ships a built artifact is this project's carve-back; it keys on whether a release carries a built asset, the applicability shape R-PUB-05 already uses, and retires if build output stops reaching users. On identifiers the divergence is smaller than it looks: the badge says 'a CVE assignment or similar' while its checker hint examines the release notes for CVE identifiers, and this rule makes 'or similar' explicit by accepting an identifier from any published advisory, because enumerating CVE and GHSA would write GitLab advisory and ecosystem-database identifiers out of a rule scoped to both forges.