docs: add security policy

[snehasaisneha]

Summary

Adds a SECURITY.md covering private vulnerability reporting, scope, research guidelines, and Loculus's current unversioned support model. GitHub private vulnerability reporting is the primary channel, with contacting a team member as fallback.

Documentation-only; no runtime behavior changes.

Resolves #6997

🚀 Preview: Add preview label to enable

[claude]

Claude finished @snehasaisneha's task in 44s —— View job

---

Review complete

• Read SECURITY.md
• Checked for cross-references (README, CONTRIBUTING) — none exist and none are needed; GitHub surfaces SECURITY.md automatically in the repo's Security tab
• Posted inline feedback

Summary

This is a clear, well-structured SECURITY.md. It covers reporting channel, expected report contents, disclosure expectations, the unversioned support model, scope, out-of-scope items, and research guidelines — good coverage for a project at this stage. No runtime code is touched, so there's no functional risk.

Two non-blocking items left as inline comments, both about content accuracy rather than the doc's writing:

1. Line 9 — the private vulnerability reporting link only works if that GitHub feature is actually enabled for this repo; worth confirming in repo settings.
2. Line 11 — worth double-checking the loculus.org/#team anchor still resolves, since it's the fallback contact path if the form is unavailable.

Nothing else stood out — the out-of-scope and research-guidelines sections are sensible and match common industry practice (e.g. GitHub's own bug bounty scope language).

[anna-parker]

maybe lets add social engineering attacks

[anna-parker]

Im not sure about this - potentially we would still like to know if we are using a tool (software, services, infrastructure, ...) with a known vulnerability - like I would hope github would figure it out and let us know but maybe there could be an edge case here

[snehasaisneha]

Hmm but would that be a security vulnerability or a regular GH Issue?

[corneliusroemer]

Yeah maybe I would for jow remove the out of scope part as this is only useful if we get overwhelmed with useless reports. We can do that once that happens

[chaoran-chen]

Yes, I think for now, I'd also tend to leaving out the out of scope section and add it only if we get too many reports.

[anna-parker]

Looks good to me - but maybe others would also like to take a closer look before merging!

[corneliusroemer]

Good stuff, thank! I might cut the "out of scope part" for now and add an email address like our security channel slack email address so people don't have to hunt for one.

[corneliusroemer]

I would give an email address here - maybe the slack security channel email address 😀

[corneliusroemer]

Yeah maybe I would for jow remove the out of scope part as this is only useful if we get overwhelmed with useless reports. We can do that once that happens

[corneliusroemer]

No harm having it as security first we can always deescalate to regular issue. I wouldn't worry false positives, we can figure out when it becomes a regular occurrence.

…

On Thu, Jul 30, 2026, 15:39 Sneha ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In SECURITY.md <#7011 (comment)> : > +Loculus is self-hosted, and each deployment is operated independently. If your +report concerns the configuration, infrastructure, accounts, or data of a specific +Loculus instance, contact that instance's operator. A vulnerability in Loculus +itself should be reported to us using the private reporting form above, even if you +first observed it on a third-party instance. + +## Out of scope + +The following are generally out of scope: + +- Vulnerabilities that have already been reported or are already known to us +- Vulnerabilities in unsupported or outdated versions that have been fixed in a + maintained version +- Vulnerabilities in an upstream dependency that have already been reported to the + upstream maintainer and do not introduce a Loculus-specific vulnerability +- Issues in software, services, infrastructure, or protocols that are not under Hmm but would that be a security vulnerability or a regular GH Issue? — Reply to this email directly, view it on GitHub <#7011?email_source=notifications&email_token=AF77AQNGATHCBHYLXBLUAQT5HNF2XA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOBRHEZTKMJUGUZKM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#discussion_r3683143078>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF77AQJCQG7IR4EF7IOLK6T5HNF2XAVCNFSNUABFKJSXA33TNF2G64TZHM3DIMJQHE4DSMZWHNEXG43VMU5TKMBRHA4TOOBYHE22C5QC> . You are receiving this because your review was requested.Message ID: ***@***.***>

[chaoran-chen]

Do we have any mechanism for an operator to subscribe to security updates? If not, should we add a sentence about us welcoming Loculus admins to reach out to us if they are maintaining a Loculus instance? This way and for now, we can ensure that operators are informed about any issues.