Add initial security documentation (attack tree & threat model)

[therealnb]

Summary

This PR adds foundational security documentation for ToolHive, including an attack tree and threat model. This is just a starting point and definitely needs review from the security team. It may not be useful at all in its current form, but figured it's better to have something than nothing as a baseline for discussion.

What's Included

📊 Attack Tree (docs/security/attack-tree.md)

• Visual attack vectors across Local, Kubernetes, and Remote MCP deployments
• Distinguishes between ToolHive-specific attacks vs generic infrastructure
• 8 separate diagrams (horizontal layout for readability)
• Cost estimates for ~50 ToolHive-specific attack paths
• 6 detailed attack chains with mitigations

🛡️ Threat Model (docs/security/threat-model.md)

• STRIDE analysis (Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Privilege Escalation)
• Coverage of 11 major components (CLI, Desktop UI, Operator, Proxy Runner, MCP Containers, etc.)
• Data flow diagrams for each deployment mode
• 80+ specific threats with existing/missing mitigations
• Top 10 critical threats (P0)
• Security control recommendations by category

📖 Supporting Docs

• docs/security/README.md - Index, quick reference, checklists
• docs/security/SUMMARY.md - Executive summary of what was created

⚠️ Important Caveats

This definitely has some superfluous guff in it. There's probably too much generic security advice that applies to any containerized system, and some of the threat scenarios might be unrealistic or over-stated.

However, there are also some good bits:

• ToolHive-specific attack vectors (RunConfig tampering, MCPRegistry poisoning, Cedar policy bypass, RFC 9728 discovery exploitation)
• Concrete attack chains showing how vulnerabilities chain together
• Actionable mitigations linked to actual ToolHive features
• Cross-references to existing documentation

What This Needs

• [ ] Security team review - Validate threats and priorities
• [ ] Architecture team review - Confirm technical accuracy
• [ ] Pruning - Remove generic content that doesn't add value
• [ ] Gap analysis - Identify what security controls are actually missing
• [ ] Integration - Link to actual implementation work (issues/epics)

Why This Might Be Useful

Even if 70% of this gets thrown away, having structured security documentation can:

• Help with architectural decisions (e.g., "what's the threat model for X feature?")
• Support security audits and compliance efforts
• Provide a framework for security discussions
• Identify gaps in existing security controls

---

Bottom line: This is a draft, not gospel. Use what's helpful, ignore or delete the rest. Looking for feedback on whether this approach is even worth pursuing.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 55.24%. Comparing base (5f1a532) to head (bd660f9).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2659   +/-   ##
=======================================
  Coverage   55.24%   55.24%           
=======================================
  Files         315      315           
  Lines       30294    30294           
=======================================
  Hits        16736    16736           
  Misses      12097    12097           
  Partials     1461     1461           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.