# Application Security This runbook maps the application security controls tracked by `application_security_controls` and `key_rotation_runs`. ## Managed Secrets And KMS Production-like environments must not boot with local or environment-only secret storage. `BANKING_APP_ENV=preprod` or `production` requires: - `BANKING_SECRET_PROVIDER` set to a managed provider such as `aws_kms`, `gcp_kms`, `azure_key_vault`, `vault`, or a contracted platform equivalent. - `BANKING_KMS_KEY_REFERENCE` set to the KMS key, vault key, or envelope key reference. - Provider credentials stored outside the repository and outside container images. Raw secrets must never be written to audit events, appsec records, logs, screenshots, or reports. Store only key references and evidence references. ## Key Rotation Use `key_rotation_runs` to schedule and evidence rotations for JWT signing secrets, MFA encryption keys, card secrets, webhook secrets, provider credentials, database credentials, and emergency break-glass keys. Required record fields: - `secret_name` - `secret_category` - `new_key_reference` - `rotation_reason` - `scheduled_for` - `evidence_reference` when completed Completed rotations require `completed_at` and evidence. Failed or canceled rotations require a follow-up record or incident/case reference. ## WAF, Reverse Proxy, And TLS Preprod and production config validation requires: - `BANKING_PUBLIC_BASE_URL=https://...` - `BANKING_TLS_REQUIRED=true` - `BANKING_HSTS_ENABLED=true` - `BANKING_WAF_MODE=enforce` - `BANKING_CSRF_ENABLED=true` The API enforces allowed hostnames, HTTPS via direct TLS or trusted proxy headers, and HSTS when enabled. The reverse proxy or WAF must terminate TLS, forward `X-Forwarded-Proto: https`, preserve request IDs, enforce body limits, and block common injection/scanning payloads before they hit the API. ## DAST The `DAST` workflow runs OWASP ZAP baseline scans against the staging URL. The target must be HTTPS and reachable from GitHub Actions. Store the ZAP artifact URL or report reference in the AppSec dashboard under the `dast` control. DAST failures must be triaged before production release. A false positive needs a written justification and owner signoff. ## Penetration Test Before launch, attach external penetration test evidence to the `penetration_test` control. Minimum evidence: - scope and dates - tester or vendor - findings and severity - remediation plan - retest or compensating-control evidence Do not mark this control `approved` without an evidence reference. ## Secure Logging Application logs are emitted through the redacting slog handler. Sensitive keys and common secret/PII patterns are replaced before output. Redaction tests cover tokens, passwords, emails, and card-number-like values. Provider request/response logs must go through the same redaction path and should store payload references instead of raw payloads when possible. ## CSRF Cookie-based refresh sessions use a double-submit CSRF cookie. Unsafe HTTP methods require `X-CSRF-Token` to match `banking_csrf_token` when the refresh cookie is present. Bearer-only API calls are not forced through CSRF validation. If browser cookie auth expands beyond refresh/logout flows, add route-level CSRF tests for the new cookie-authenticated endpoints. ## Vulnerability Disclosure The vulnerability disclosure process lives in `SECURITY.md`. Track program status and disclosure evidence in the `vulnerability_disclosure` control. A public bug bounty can remain disabled until the team has on-call, triage, legal review, and bounty budget ready.