A scanner's security policy should say which versions get fixes, how to report a flaw privately and what response to expect. If it is missing or vague, you cannot be sure the maintainers can handle a vulnerability in the tool you are about to give access to your code.
Why a scanner needs one more than most
You are about to give this tool read access to source code, build output and possibly tokens. A flaw in it is a flaw in your pipeline. How the maintainers treat reports tells you how they would treat yours.
Where to find it
GitHub's documentation says a security policy lives in a SECURITY.md file and should describe supported versions and how to report a vulnerability. In the repository it appears under the Security and quality tab, in a section called Security policy.
Also check whether private vulnerability reporting is on. GitHub documents that when it is enabled, researchers see a Report a vulnerability button on the repository's Advisories page, which lets them disclose without making the report public.
What to look for
The OpenSSF Scorecard Security-Policy check gives a useful rubric. It awards points for a valid email address or web address for reporting, for free text beyond bare links, and for specific text about disclosure expectations and timelines such as 30 or 90 days.
Turn that into a buyer checklist:
| Item | Good sign | Red flag |
|---|---|---|
| Reporting channel | Private form or monitored email | Public issues only |
| Supported versions | Table of versions with fixes | Silent |
| Response expectation | A stated time to acknowledge | No timeline |
| Disclosure approach | Coordinated disclosure described | Not mentioned |
| Past advisories | Published advisories for fixed flaws | None, or none ever fixed |
A project with no past advisories is not necessarily perfect. It may simply be small or may not publish them. Ask which it is.
Test the channel
You can learn a lot cheaply. Send a non-sensitive question to the stated reporting address, such as asking which versions are currently supported. Note how long a reply takes and whether it is from a person.
Do not send a real vulnerability report as a test, and do not probe the project's infrastructure.
How to record the result
Write one line in your adoption notes: policy present or absent, private reporting on or off, response seen or not. If the gaps are large, either choose a different tool or accept the risk in writing with a review date.
What a missing policy means for graduation
A project that lacks a clear route for security reports is a signal to plan an exit, not an emergency. Safeguard's policies and guardrails can add controls around what runs in your pipeline, and its asset discovery helps you see which scanners are in use across teams.
Quick check
Is SECURITY.md required for a project to be trustworthy?
It is not a guarantee either way, but without one you do not know how reports are handled.
Does private vulnerability reporting replace a policy file?
No. The form is the channel, the policy explains expectations and supported versions. Good projects have both.
Sources
- GitHub Docs, Adding a security policy to your repository
- GitHub Docs, Configuring private vulnerability reporting
- OpenSSF Scorecard, Checks documentation
Last reviewed: 19 October 2026.
