Your SECURITY.md should say how to report a vulnerability, which versions you support, and how you treat issues in dependencies: where to report, how you assess whether you are affected, and how fast you aim to raise the minimum version. A short section saves repeated questions.
What GitHub expects
GitHub's documentation says a security policy should include information about supported versions of your project and how to report a vulnerability. You create it from the repository's security area, and Scorecard checks that a security policy file exists. Most maintainers stop there, and then get a steady stream of "your dependency has a CVE" issues in the public tracker.
A dependencies section stops that.
A template you can adapt
## Vulnerabilities in dependencies
If a package we depend on has a published advisory:
- Open a public issue or discussion. These are already public, so
there is no need to report them privately.
- Tell us the advisory ID and the version of our library you use.
- We will assess whether our library is affected and reply with one
of: affected, not affected, or under investigation.
- If affected, we will publish our own advisory and release a patch.
- If not affected, we will say why, and we may still raise the
minimum version to quiet scanners.
If you believe our library exposes a dependency flaw in a way the
advisory does not describe, report it privately as described above.
Adjust the wording to your project. Keep it in plain words and keep it short.
Why public for known dependency advisories
An advisory that is already published is not a secret. Asking users to report it privately wastes your time. The exception is a new angle: if users think your library exposes a flaw in a way the advisory does not describe, that can be a new vulnerability and should go through private reporting.
Supported versions, honestly
State which release lines get fixes. If you only patch the latest minor version, say that. A vague table invites arguments after a vulnerability lands. A short table works:
| Version | Gets security fixes |
|---|---|
| Latest minor of the current major | Yes |
| Previous major | Only for critical issues, at your discretion |
| Older | No |
Write what is true for your project, even if the answer is "latest only".
Response expectations
Say what people can expect, without promising what you cannot deliver. "We try to reply within a week" is honest for a volunteer project. Do not publish a service level you will miss.
Link the related files
Point to your advisory list, release notes and, if you publish them, your VEX statements. That gives a user one place to look.
Keep it current
Review SECURITY.md when you change release lines, add maintainers or change how you receive reports. An out of date policy is worse than none, because people trust it.
Quick check
Should users report known dependency CVEs privately?
Not usually. If an advisory is already public, an open issue is fine. Keep private reporting for new problems.
Do I have to publish a response time?
No. If you do, choose one you can meet.
Safeguard can monitor your dependencies and policies continuously, which makes the assessment step in this template faster. Try the free scan.
Sources
- GitHub docs, adding a security policy to your repository: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
- OpenSSF Scorecard: https://github.com/ossf/scorecard
Last reviewed: 19 October 2026.
