Security Contact

🔑 Key Takeaway: A security contact is useless unless someone skilled monitors it, acknowledges reports quickly, and keeps findings confidential until fixes ship.

A security contact is the designated path for external researchers (and users) to report vulnerabilities. Without it, findings route through public issues, social media, or nowhere—raising exploit risk and burning researcher trust.

SECURITY.md

Why it matters

A SECURITY.md file in a GitHub repository tells reporters how to submit vulnerabilities and what to expect next.

Example content

# Security Policy

We take the security of our project seriously. If you discover any security vulnerabilities, please report them
responsibly.

## Reporting a Vulnerability

Please email us at security@projectname.TLD with the details of the vulnerability. We will respond as soon as possible.

We appreciate your help in improving the security of our project.

Security email address

Why it matters

A dedicated address (for example security@projectname.TLD) routes reports to people who can act, instead of a shared inbox no one owns.

Setup

• Dedicated team: ensure the mailbox is monitored by people who can triage vulnerability reports.
• Prompt responses: acknowledge receipt quickly (teams often target within 24 hours).

.well-known/security.txt

Why it matters

The security.txt file is a standard web path for publishing security contact and policy metadata.

Example content

Contact: mailto:security@projectname.TLD
Encryption: https://projectname.TLD/pgp-key.txt
Acknowledgements: https://projectname.TLD/hall-of-fame.html
Policy: https://projectname.TLD/security-policy.html
Preferred-Languages: en

Implementation

• Standard location: serve the file at https://projectname.TLD/.well-known/security.txt.
• Regular updates: keep contact information and policy URLs current.

Managing security contacts

Responsibilities

• Triage: assess and prioritize reports by severity and impact.
• Communication: stay clear and respectful with reporters; give regular status updates.
• Resolution: remediate promptly and tell the reporter what changed.

Best practices

• Confidentiality: treat reports as confidential until a fix is in place (unless a coordinated public path or Safe Harbor scenario requires faster warning).
• Acknowledgement: consider public credit for researchers who want it, only with their permission.
• Transparency: publish disclosure process and expected timelines so reporters know the rules.

Further reading

• security.txt
• GitHub: Add a security policy
• RFC 9116 — security.txt