Publish security.txt per RFC 9116 (securitytxt.org)

[rado0x54]

Summary

Publish a security.txt file per RFC 9116 / securitytxt.org so security researchers have a standard, discoverable channel to report vulnerabilities in ShellWatch.

Where it should live

The spec requires the file at:

• https://<domain>/.well-known/security.txt (canonical)
• https://<domain>/security.txt (legacy fallback)

This needs to be served from each public-facing surface:

• shellwatch.ai (marketing site)
• app.shellwatch.ai (web app)
• Consider whether the GitHub repo also needs SECURITY.md (GitHub picks this up for the "Security" tab) — these are complementary, not redundant.

Suggested fields

```
Contact: mailto:security@shellwatch.ai
Expires: <ISO-8601 date, ~1 year out>
Preferred-Languages: en, de
Canonical: https://shellwatch.ai/.well-known/security.txt
Policy: https://shellwatch.ai/security-policy
```

Open questions:

• Do we want a dedicated security@ alias, or route to an existing inbox?
• Signing the file with PGP (Encryption: + detached signature) — defer to v2?
• Do we want a public PGP key for encrypted reports?

Acceptance criteria

• security.txt reachable at /.well-known/security.txt on all public domains
• Expires field set with a reminder/automation to rotate before expiry
• SECURITY.md in the repo points to the same contact
• Linked from the website footer (optional but conventional)

Context

Discussed as part of the public-launch readiness checklist. This is a low-cost, high-signal trust signal — especially for a tool that brokers SSH sessions, where responsible disclosure matters.

Refs: https://securitytxt.org/, RFC 9116