SECURITY.md states a private reporting channel and a response window
Without a stated channel, a finder either opens a public issue that discloses the bug to everyone at once, or gives up. A stated response window tells them when to escalate. A window with no ceiling promises nothing, because a policy answering within a year satisfies the words and defeats the point.
Observable check
SECURITY.md exists at the repository root, in .github/, or in docs/ on GitHub, or at the repository root on GitLab, and names a private channel that an unaffiliated reporter can use, together with the time you commit to responding in, which is no longer than 14 days. Accept GitHub private vulnerability reporting only when the repository is public and the feature is enabled. Accept a GitLab confidential issue only when the intended reporter role can create it as confidential; GitLab Service Desk and a monitored security email are valid alternatives.
Where this comes from
- https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability
- https://www.bestpractices.dev/en/criteria/0
Last read against these sources on 2026-07-30.
GitHub's page confirms private reporting is public-repository only and is separate from SECURITY.md, which is why the check accepts it only when enabled. GitLab confidential issues and Service Desk have no source named. The 14-day ceiling comes from the OpenSSF Best Practices badge Passing criterion 'vulnerability_report_response', MUST with N/A allowed: 'The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days.' The badge measures reports actually received and marks a project with none N/A; this rule reads the number the policy states instead, because a stated window is what a finder decides when to escalate from and is observable in the file. The ceiling retires if the badge revises it.