security: schedule an independent third-party penetration test

[sathish-mg]

Summary

Schedule an independent third-party penetration test, ahead of when a prospective enterprise customer's deal will demand one. This wasn't part of the original four action items but came out of the same review, and it's a natural companion to the branch-protection and SBOM/provenance items — filing it so it doesn't get lost.

Current state

docs/procurement.md's procurement checklist currently has:

| Penetration testing | Operator's scope | Self-hosted software: the deployment's pen test covers it; SECURITY.md has the vulnerability-report channel; the threat model is security-model.md |

That's an honest and defensible position for self-hosted software in general — but a serious enterprise buyer's security team will typically ask "show me a recent report," not "whose responsibility is it." Having one on file (even a scoped one) converts a conversation that currently has no artifact into one that does.

Suggested scope

Given Areev is a library + self-hosted binaries (not a hosted service), the highest-value scope is probably the concrete attack surfaces docs/security-model.md already enumerates under "Threats in scope":

• The web console (areev ui) and sync hub (areev hub) HTTP surfaces — auth bypass, injection, the newly-added SSO trusted-header path, TLS handling.
• The CAL executor — injection/auth-bypass in the query language, the destructive-ops authorization gates.
• The .mg blob / bundle / segment import path — memory-safety and resource-exhaustion from untrusted input (this is the path security-model.md already calls out as most exposed to untrusted data).
• The MCP server's stdio JSON-RPC handling.

security-model.md's own "Threats in scope" and "Threats out of scope" sections are a solid starting brief for whoever runs the engagement — worth handing over directly rather than re-deriving scope from scratch.

Acceptance criteria

• A pen test engagement is scheduled (or a vendor selected) with the scope above (or a deliberately narrower/wider scope, decided explicitly).
• The resulting report (or a redacted/summary version) is available to hand to a prospect's security team, and linked from docs/procurement.md.
• Any findings get their own follow-up issues.

Context

Surfaced during a conversational security/enterprise-readiness review — flagged as a gap but not one of the four items originally actioned. Related: #83