Open the repository's Security area and look for a security policy, usually a SECURITY.md file. Check four things: which versions get fixes, how to report a vulnerability, where announcements go, and whether the project has published advisories before. Missing answers are a finding in themselves.
Where to find it
GitHub's documentation says a security policy gives instructions on how to report a security vulnerability in a project. Maintainers add it from the repository's Security and quality tab, under Reporting, then Security policy, which creates a SECURITY.md file. The file should include supported versions and how to report.
If there is no SECURITY.md, look in the README, the project website and the documentation for a security page. Large projects often have one. The Kubernetes site, for example, has a page on security and disclosure that names its announce group and report route, and the Go project publishes a full security policy.
The four checks
| Check | What good looks like | Red flag |
|---|---|---|
| Supported versions | A clear list or table with end dates | No statement, or only "latest" with no history |
| Reporting route | A private contact or form, and a response expectation | A public issue tracker only |
| Announcement channel | A list, feed or advisory page | Silence after past fixes |
| Track record | Published advisories with fixed versions | Known bugs fixed without any notice |
Supported versions matter most. Django's policy shows why: its notices list only supported versions, and older ones may be affected but are not investigated. A project without a clear support statement leaves you guessing.
Ten minute process
- Find the policy and read it end to end.
- Look at the advisory list for the repository, if any. Count how many exist and how quickly fixes followed.
- Check the release history for security entries.
- Note the last release date and the number of active maintainers.
- Write a three line summary in your dependency approval ticket.
If you need to go deeper on health, see our guide to maintainer health signals before adopting a dependency.
What to do when a policy is missing
A missing policy does not make a project unsafe. Many small, well run projects never wrote one. It does mean the route for reporting and the support promise are unclear. You can ask in public on the issue tracker, as long as you are not disclosing a vulnerability, and you can plan to own more of the risk, for example by pinning versions and reviewing updates yourself.
Record the decision
Keep the summary with your approval record. When an advisory later appears, it tells you whether the project behaved as its policy said, and whether you should keep the dependency.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists the open source components you already use, so you can run this check on the ones that matter most. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is a missing SECURITY.md a reason to reject a dependency?
Not on its own. It means you should look for other signals and plan to carry more of the risk.
What should the policy include?
At minimum, the supported versions and how to report a vulnerability, according to GitHub's guidance.
Sources
- GitHub Docs: adding a security policy to your repository
- Go Security Policy
- Django security policies
- Kubernetes security and disclosure information
Last reviewed: 19 October 2026.
