Release readiness policy — security gate

Status: LOCKED 2026-04-24 by Kristerpher Henderson.

The rule

No Raxx surface goes live to real users without a completed security review. Major launches additionally require a penetration test. Release decisions are conditioned on pass + documented mitigation of any open findings.

"Going live" means any of: - Production deploy exposing a domain to public traffic (e.g. api.raxx.app, raxx.app, getraxx.com, raxx.io) - Founders Promo activation (first paying-cohort signup) - Any marketing campaign driving external traffic to an authenticated surface - Mobile-app store submission - Partner / API access by third parties

Required artifacts per launch

For every release that crosses a live-traffic boundary:

1. Security review document — a scoped audit, similar in shape to docs/security/2026-04-24-security-review.md, stored under docs/security/<date>-<launch-name>-review.md
2. Findings summary — severity-tiered (critical / high / medium / low / info) with evidence + fix
3. Mitigation log — for each critical / high finding, either a closed fix (PR link) or a documented accepted risk (with rationale + time-boxed review)
4. Re-review / verification — a Round-2 doc confirming the fixes landed and the originally-flagged vectors are closed
5. Pen test report (for major launches — first production GA, any payment-flow GA, any release introducing PII collection) — external test; findings triaged before release

When a pen test is required (not just a review)

• First production launch (GA) — required
• First launch accepting payments via Stripe (Founders Promo paid-conversion, standard Pro paid launch) — required
• First launch storing PII at scale (email list > 500, or any PHI / financial-account linking) — required
• Any launch introducing a new auth factor (passkey-only → TOTP fallback change, SSO, etc.) — required
• Minor feature releases behind existing auth perimeter — optional (review sufficient)

What a pen test covers that a review doesn't

• DAST — dynamic application security testing; active probing with Burp / similar
• Network / infra attacks — TLS config, DNS security, DDoS posture
• Auth bypass attempts — session fixation, CSRF, token replay, rate-limit bypass
• Authorization / privilege escalation — vertical (user → admin) and horizontal (user A → user B)
• Business logic abuse — specific to Raxx: trade-submit spam, rate-limit circumvention, referral farming, trial-extension abuse
• Compliance-adjacent — HTTPS-only, cookie flags, CSP, CORS, security headers

Vendor options for pen testing

Captured here so future-us doesn't repeat the search:

For Raxx's first production launch, budget ~$5–$10k for a scoped pen test (one-time) is realistic.

Policy integration with the existing backlog

• Every epic that includes a launch trigger inherits this policy as an implicit AC
• Release checklist must link to the relevant security review + mitigation log
• Security review itself is a card with its own prep (scoping, access-provisioning, sign-off)
• Pen test is an engagement (separate from the card tracker) — budget line + vendor contract + NDA

Acceptance of risk

Some findings from a review or pen test can be accepted rather than mitigated — e.g., "info-level finding, not worth fixing before launch." Acceptance must be:

• Documented in the mitigation log with rationale
• Time-boxed (with a follow-up review date)
• Ownership-assigned to a human for re-evaluation
• Never for critical or high findings without explicit attorney + Kristerpher sign-off

What this policy is NOT

• Not a substitute for ongoing security work (dep bumps, SAST, secret scanning run continuously in CI)
• Not a compliance framework in itself (HIPAA, PCI, SOC 2 are separate if they become relevant)
• Not a scheduled recurring event — it's launch-triggered, not calendar-triggered

Where to find current artifacts

Change log

• 2026-05-17 — Added DPIA and shadow-analytics runbook as required artifacts for shadow-analytics feature activation (#279).
• 2026-04-24 — Initial policy locked by Kristerpher Henderson.