A SECURITY.md file tells you the project has thought about how people should report vulnerabilities and where to send them. It is a process signal. It does not show the code is secure, but its absence means a researcher who finds a flaw may have nowhere private to report it.
What the file is for
GitHub documents the security policy as a way to give instructions for how to report a security vulnerability in your project. GitHub's setup steps ask you to add supported versions and how to report a vulnerability in a new SECURITY.md file, which then appears under the repository's security policy section.
OpenSSF Scorecard checks for it too. Its Security-Policy check looks for a file named SECURITY.md, case insensitive, in a few well known directories, and rates the risk of a missing one as Medium, described as possible insecure reporting of vulnerabilities. The check awards points for a valid email address or an http or https address for reporting, for free form text beyond a bare link, and for disclosure timelines and process.
How to read one in two minutes
| Look for | Why it matters |
|---|---|
| A private channel, such as an email address or advisory form | Reports do not have to be public issues |
| Which versions get fixes | Tells you whether older releases are patched |
| An expected response or disclosure timeline | Sets expectations for fix speed |
| A statement of scope | Clarifies what counts as a vulnerability |
| Recent edits | A stale policy may point to an address nobody reads |
The OpenSSF Concise Guide lists Vulnerability Reporting under usability and security: confirm there are instructions on how to report vulnerabilities. It also asks about security response, including whether fixes reach older releases and whether there is an LTS version.
What a missing file does and does not mean
It does not mean the project is insecure. Small projects may have never needed to think about it, and some maintainers handle reports by email without a file. It does mean you should plan for the case where you find a problem: look for an alternative contact, such as a maintainer email in the package metadata or on the project site.
It also changes your own risk. If a flaw is found and there is no clear private path, the fix may be slower or the disclosure messier. For a dependency in a sensitive role, that is worth a line in your review note.
Use it with other signals
Pair this with release recency and the Maintained check. A project with a thorough policy but no commits for years is a process on paper. A project with active maintenance but no policy may be one pull request away from a better setup. If you rely on the dependency, you can help by opening an issue or a pull request that adds one.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a finding moves from detection to an owner, which is the same handoff a good reporting policy supports on the project side.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and policies and gates, so findings in dependencies reach owners. A free scan is at gold.safeguard.sh/scan.
Quick check
Does having a SECURITY.md make a package safe?
No. It shows a reporting process exists. Code quality and review practice are separate questions.
What if there is no SECURITY.md?
Look for another private contact, treat reporting as unclear, and weigh that for dependencies that run in sensitive places.
Sources
- GitHub Docs: Adding a security policy to your repository
- OpenSSF Scorecard check documentation
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
