Look for a SECURITY.md in the library's repository. A useful one says how to report a vulnerability privately, which versions get fixes, and what response to expect. A missing policy is not a stop sign, but it means you will not know how a flaw would be handled.
Why this matters before you adopt
A library you adopt will eventually have a vulnerability reported against it. What matters then is whether the reporter had a private channel, whether the maintainers answer, and whether fixes reach users. A security policy is the visible sign that someone thought about this.
GitHub's documentation describes adding a security policy as giving instructions for how to report a security vulnerability in a project, and says the SECURITY.md file should cover supported versions and how to report a vulnerability.
What a useful policy contains
| Element | Why you want it |
|---|---|
| A private reporting route | An email address or a web form, so reports are not posted publicly first |
| Supported versions | Tells you whether the version you plan to use gets fixes |
| Expected response | Even a rough timeline shows commitment |
| Disclosure approach | Whether and how fixes and advisories are published |
The OpenSSF Scorecard Security-Policy check looks for a SECURITY.md in well-known locations and awards points for policies that express vulnerability processes and disclosure timelines and that include links such as an email address or a web address. It rates the risk of a missing policy as medium, noting that vulnerabilities may be reported insecurely.
Steps to check in five minutes
- Open the repository and search for SECURITY.md, or look at the Security tab on GitHub.
- Read the supported versions section and compare it with the version you plan to use.
- Confirm the reporting route is private and looks monitored.
- Look at the repository's published security advisories, if any, and see whether each links to a fixed release.
- Record the result in your library checklist.
If there is no policy
A missing file has several explanations: a small project with one author, an older project, or no process. Do not assume the worst, but adjust.
- Ask in a polite issue or email how to report a vulnerability privately. A quick, clear answer is itself a good sign.
- Prefer a wrapper and an exit plan for anything on a sensitive path.
- Consider whether your own team could patch or fork if needed; see fork maintenance responsibilities.
If you publish a library yourself
Add a short SECURITY.md. It takes minutes and helps your users and researchers. The same file that you would want to find in someone else's repository is the one to provide in yours.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and continuous monitoring help you track advisories for libraries you already use, whatever their policy says. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a library without SECURITY.md unsafe?
Not necessarily. It means the reporting process is unknown. Ask, and weigh how critical the library is.
Where else might a policy live?
Often in the repository's community health files or the organization's shared settings, or on the project website. Search all three.
Sources
Last reviewed: 19 October 2026.
