Add a SECURITY.md file to the repository that says which versions you support and how to report a vulnerability privately. Use a monitored role address, not a student's personal inbox. Keep promises small, such as acknowledging a report within a stated number of working days.
Why research code needs one
Research tools get downloaded, forked and run by people outside your lab. Some of those people will find problems. If there is no stated way to report one, they either say nothing or post it publicly in an issue.
The hosting documentation describes the steps: open the repository's security settings, choose Security policy under Reporting, and start the setup, which opens a new SECURITY.md file you commit. It says to add information about supported versions of your project and how to report a vulnerability, and does not require anything else.
What to include
- Supported versions. Which releases get security fixes, in a short table.
- How to report. An address or private reporting channel.
- What to include in a report. Version, steps to reproduce, impact.
- What happens next. Acknowledgment time and how you will keep the reporter informed.
- Scope. What is in scope, and a note that testing must not touch other people's data.
A template
# Security policy
## Supported versions
| Version | Supported |
| 2.x | yes |
| 1.x | no |
## Reporting a vulnerability
Email security@yourlab.example with the version, steps to
reproduce and what you think the impact is. Please do not open
a public issue for a suspected vulnerability.
We aim to acknowledge reports within 5 working days and to tell you
what we plan to do within 30 days.
Replace the address and the numbers with ones you can keep.
Choices that matter
| Choice | Advice |
|---|---|
| Contact | A role address the department keeps after people leave |
| Response time | Only what a part-time maintainer can honor |
| Private channel | Use the platform's private reporting if available, so details are not public |
| Unsupported versions | Say clearly that they receive no fixes |
What to avoid
Do not promise a fixed repair time you cannot meet. Do not offer rewards unless your institution approves it. Do not leave the file pointing at someone who has graduated.
Tie it to the status of the project
If the project is archived or unmaintained, say so at the top of the file. A reporter then knows not to wait for a fix, and users know to look elsewhere.
Keeping it alive
A policy file is only useful if someone reads the mailbox. Put a recurring check in the lab calendar, for example the first Monday of each month, to look for reports and to confirm the address still works. Send a test message once a term.
When a report arrives, acknowledge it, reproduce it, and decide on a fix or a documented decision. If you publish a fix, say in the release notes which versions are affected and which are fixed, so users can act. Credit the reporter if they want that, and ask first.
If you change maintainers, update the file the same day. Add the check to your offboarding list so it does not depend on memory.
Checking that it works
After you commit the file, open the repository as a visitor and confirm the policy is visible and the reporting address or private channel works. Ask a colleague to send a test report and time how long it takes to reach a person. Fix any gap now, because the first real report is a poor time to find that the mailbox is unmonitored.
Where Safeguard fits
When a report arrives, Safeguard's dependency scanning can show quickly whether the affected package appears elsewhere in your projects. A free scan is a quick check on a single repository.
Quick check
Where does the file go?
The hosting documentation creates it through the repository's security settings and commits it to the repository. Many projects keep it at the repository root.
Do we need a response time?
It helps reporters, but only state one you can honor.
Sources
Last reviewed: 19 October 2026.
