Security Domains ​
Target-state standards for each of the 20 posture domains. Each domain states its objective, the target-state controls (what "done" looks like), and current maturity with the key gap. Concrete findings link to their tracking issue via the findings register.
Maturity: 🔴 critical gaps · 🟠partial · 🟢 healthy.
1. Governance & Risk Management ​
Objective: A named owner, a maintained risk register, and policies that turn this posture into accountable, scheduled work.
Target-state controls: security owner/RACI · risk register tied to the rubric · security policy set (acceptable use, access, data handling, IR) · quarterly posture review · exceptions process with expiry.
Maturity 🔴 — No formal program, owner, or risk register yet. This posture is the starting artifact.
2. Data Security & Privacy ​
Objective: Protect Restricted (financial/PII) data across its full lifecycle and meet India DPDP (and contractual) obligations.
Target-state controls: enforce the data-classification tiers · encryption at rest and in transit for all Restricted data · key rotation · backup encryption · secure deletion · retention policy per class · DPDP data-subject-rights handling (access/erasure/grievance) · data residency in-region.
Maturity 🟠— AWS design encrypts RDS/S3 at rest; missing classification enforcement, retention/deletion, KMS CMKs (see #9), and privacy operations.
3. Edge & Network Security ​
Objective: Filter, encrypt, and rate-limit all traffic before it reaches application code.
Target-state controls: Cloudflare + AWS WAF (managed + rate rules) · TLS termination at the edge (ALB/ACM), HTTPS-only with HTTP→HTTPS redirect · DDoS protection (Shield) · network segmentation (public/private/isolated subnets) · TLS for internal service-to-service and Temporal.
Current Railway protections (staging/today): backends are private (.railway.internal, no public domain); Railway's private network is encrypted at the network layer (so internal service-to-service traffic is protected even where app-level TLS isn't set — see F-10 nuance); Railway fronts public traffic with Fastly, which provides edge DDoS protection and a WAF layer (enabled following the Feb 2026 incident — see #12).
Maturity 🟠(re-verified 2026-07-10) — Railway side reasonable (private backends, network-layer encryption, Fastly WAF/DDoS). AWS production has advanced: ALB + ACM TLS (HTTPS-only, 80→443 redirect) and WAF are now provisioned (F-13 ✅ resolved). Remaining edge gaps: no security headers (F-05), and the Temporal client still sets tls:false (F-10 — acceptable on Railway's encrypted net, must be enabled for AWS). (Findings F-05, F-10; F-13 resolved.)
4. Identity & Access Management — incl. RBAC ​
Objective: Strong authentication and deny-by-default authorization for humans and services.
Target-state controls: MFA for users (mandatory for admin/approver roles) + SSO for enterprise tenants · short-lived tokens stored in httpOnly+Secure+SameSite cookies with refresh rotation · RBAC enforced server-side on every sensitive route (frontend guards are UX only) · tenant-scoped roles (tenant-admin, <module>-admin, <module>-analyst) with route↔role mapping and 403 handling · least-privilege for machine identities · periodic access reviews and joiner/mover/leaver.
Maturity 🔴 — No MFA; RBAC mechanism exists but isn't applied to finance endpoints; tokens JS-readable. (Findings F-02, F-07, F-23.)
Implementation decisions (from fin-infra#14): auth/authz to be built on BetterAuth (ref Bun guard); SAML/SSO provider tooling is an open decision for enterprise tenants; "navigate back to last active page after re-login" is a post-token-expiry UX requirement to fold into the refresh-rotation work (F-07).
Also: the authenticator accepts the JWT from a query parameter (?token=), which leaks tokens into logs — distinct, confirmed in current code. (Finding F-28.)
5. Application Security — incl. AI/LLM ​
Objective: Eliminate injection, XSS, and unsafe LLM data flows in application code.
Target-state controls: parameterized queries only (no string-interpolated SQL) · input validation on every route (TypeBox schemas) · output encoding / sanitized v-html (DOMPurify or sandboxed iframes) · security headers incl. CSP · safe file handling. AI/LLM: prompt templating with strict instruction/user separation · PII redaction before LLM calls · per-tool agent RBAC · provider data-processing posture (ties to #18).
Maturity 🔴 — SQLi, permissive CORS, missing headers, unsanitized v-html, no prompt sanitization, shared LLM keys. (Findings F-03, F-04, F-05, F-08, F-14.)
6. API Security ​
Objective: APIs accept only well-formed, authorized, rate-limited requests from known origins.
Target-state controls: explicit per-environment CORS allow-list (no wildcard with credentials) · CSRF defenses for cookie auth · rate limiting on all services incl. auth · API docs gated/disabled in prod · schema validation everywhere.
Maturity 🔴 — Wildcard CORS+credentials, rate limiting only on agents, open Swagger. Plus two shared-library issues inherited by ~1,936 endpoints: /filter accepts arbitrary WHERE-clause fields (no allowlist → BOLA / data enumeration) and unbounded pagination (take has no max → DoS). (Findings F-04, F-06, F-09, F-26, F-27.)
7. Tenant Isolation ​
Objective: A tenant can never read or write another tenant's data — verified, not assumed.
Target-state controls: bind the request tenant to the JWT tenant claim (reject mismatched headers) · Postgres RLS as a defense-in-depth backstop · tenant-namespaced cache keys (✓ today) · tenant-scoped object-storage prefixes (✓ today) · correct per-tenant connection routing with bounded caches · automated cross-tenant access tests in CI.
Maturity 🔴 — Tenant header not bound to JWT; connection-cache key bug; no RLS. The platform's highest-rated risk. (Findings F-01, F-19.)
8. Software Supply Chain Security ​
Objective: Only verified, scanned, signed artifacts reach production.
Target-state controls: signed commits · branch protection + CODEOWNERS · dependency scanning (Snyk/Grype) gating CI · SBOM generation (Syft) · container signing (cosign) + provenance · verified-images-only at deploy · digest pinning.
Maturity 🟠— Snyk configured; no signing, SBOM, scan-gate, or digest pinning. (Finding F-20.)
9. Cloud & Infrastructure Security ​
Objective: A hardened, least-privilege AWS foundation defined entirely in IaC.
Target-state controls: VPC segmentation (✓ designed) · least-privilege IAM (no wildcard resources) · customer-managed KMS CMKs + rotation for Restricted data · RDS private + encrypted + PITR + Multi-AZ (✓ designed) · S3 block-public + versioning + TLS-only policy + access logs · Secrets Manager + rotation · no secrets in state or images.
Maturity 🟠— Strong Phase-1 scaffold; gaps in KMS CMKs, IAM scoping, S3 policy, secret rotation. (Findings F-12, F-18.)
10. Container & Runtime Security ​
Objective: Minimal, scanned, non-privileged containers with runtime threat detection.
Target-state controls: image scanning in CI (Trivy/Grype/ECR) failing on critical/high · non-root user · read-only root filesystem · dropped Linux capabilities · pinned base images · GuardDuty + CloudWatch runtime monitoring.
Maturity 🔴 — No scanning, no task hardening, :latest tags. (Finding F-20.)
11. Monitoring & Detection ​
Objective: Security-relevant events are logged, retained, and alerted on.
Target-state controls: security logging of authentication, authorization, data access, admin actions, config changes · CloudTrail (multi-region + log-file validation) · GuardDuty · Security Hub · VPC Flow Logs · centralized log aggregation/SIEM with tamper-resistant retention · alerting on impossible travel, brute force, privilege escalation, cross-tenant access attempts, large exports · no secrets/PII in logs.
Maturity 🟠(re-verified 2026-07-10) — GuardDuty, VPC Flow Logs, and WAF now provisioned in AWS; CloudTrail and Security Hub still absent (CloudTrail has only a deletion-protection SCP, no trail). No SIEM/log aggregation yet; some debug console.log. (Finding F-11, now partial.)
12. Incident Response ​
Objective: A rehearsed plan to detect, contain, eradicate, recover, and report security incidents.
Target-state controls: security IR plan (severity classification, roles, escalation, comms) · breach-notification process (DPDP timelines, customer DPAs) · forensics/log-retention readiness · post-incident reviews · secret-rotation and rollback runbooks.
Maturity 🟠— Operational incident-response runbook exists in Runbooks; a security/breach-notification IR plan does not. Incident history: a Feb 2026 incident prompted enabling the Fastly WAF layer on Railway (see #3) — capture this and any future incidents in a security incident log with post-incident reviews.
13. Business Continuity & Disaster Recovery ​
Objective: Defined, tested recovery for a financial system of record.
Target-state controls: documented RPO/RTO · Multi-AZ · automated backups + PITR · periodic restore drills · failover runbooks · chaos testing.
Maturity 🟠— RDS backups + Multi-AZ designed; no stated RPO/RTO and no evidence of restore drills.
14. Secure SDLC & DevSecOps — incl. assurance ​
Objective: Security built into design, code, test, and release — plus external validation.
Target-state controls: threat modeling + architecture review at design · secure-coding standards + code review · SAST, DAST, dependency + secret scanning in CI · signed artifacts + approval workflow (incl. Terraform plan approval gate) · annual penetration test · vulnerability disclosure / responsible-disclosure policy.
Maturity 🟠— Snyk + GitHub OIDC in place; no SAST/DAST gate, no Terraform plan-approval gate, no pentest cadence or VDP. (Findings F-22, F-24 — penetration test + VDP program, fin-infra#39.)
15. Compliance & Audit Readiness ​
Objective: Map controls to a recognized framework and keep audit evidence.
Target-state controls: adopt target framework (SOC 2 / ISO 27001; DPDP baseline) · control↔domain mapping · evidence collection · sub-processor register (see #18) · ability to answer customer security questionnaires.
Maturity 🔴 — No framework adopted; evidence collection not started. Target framework is a TBD scoping input.
16. Financial Data Integrity ​
Objective: Financial records are accurate, attributable, and tamper-evident.
Target-state controls: uniform append-only audit trail across all financial entities · change history with attribution · tamper-evidence (hash-chaining/signing) · segregation of duties.
Maturity 🔴 — Audit tables exist for journal/reconciliation; invoices lighter; no cryptographic tamper-evidence. Critically, audit/identity fields (createdby, approvedby, assigneduseremail, ownerid…) are accepted from the client across modules — so the audit trail can be falsified at the source and work attributed to anyone (e.g. "CFO approved it"). Tamper-evidence is moot until the source is trustworthy. (Findings F-15, F-25.)
17. Business Logic Security ​
Objective: Workflow and approval rules cannot be bypassed via the API.
Target-state controls: server-side state-transition validation · approval enforcement (poster ≠approver) · no double-close · authorized-reversal-only · all enforced server-side regardless of UI state.
Maturity 🟠— Approval/state fields and Temporal orchestration exist; explicit server-side guards unverified. (Finding F-16, needs runtime confirmation.)
18. Third-party / Vendor & Sub-processor Risk ​
Objective: Know, vet, and contractually cover every external service touching our data.
Target-state controls: maintained sub-processor register · vendor due diligence · DPAs on file · periodic review · data-flow mapping per vendor.
Maturity 🔴 — No register or DPA tracking yet. Inventory seeded (handle customer data unless noted): Railway · AWS · Cloudflare · Zoho (email/identity) · Google Gemini · OpenAI · GHCR · Syncfusion (UI-only, low) · Sentry (if enabled) · Temporal · RustFS · MindsDB. LLM providers receive Restricted data — see #5 and #14.
19. Endpoint & Workstation Security ​
Objective: Devices with access to source code, credentials, or production are hardened and accountable — they are the real perimeter for a small team.
Target-state controls: enforced disk encryption (FileVault) · screen-lock + strong device auth · MDM (inventory, policy, remote wipe) or a documented lightweight equivalent · anti-malware / EDR · OS-patch currency · device posture as a Zero-Trust access condition (WARP) · joiner/mover/leaver device provisioning + deprovisioning tied to access revocation.
Maturity 🔴 — No documented endpoint baseline. WARP/Zero-Trust enrollment exists for access, but disk-encryption/EDR/MDM posture is unmanaged. (Finding F-32.) Added in the iteration-1 completeness review (ISO 27001 A.8 / CIS v8 #1,4,10).
20. People & Security Awareness ​
Objective: Staff recognize and resist social-engineering, and security responsibilities are trained, acknowledged, and offboarded — humans are the most common breach vector.
Target-state controls: security-awareness training at onboarding + annually · phishing simulation (BEC-focused, given the finance domain + email ingestion) · acceptable-use & data-handling policy acknowledgement + NDAs · onboarding/offboarding security checklists (access + device + secret rotation on leaver) · background checks where appropriate · a clear "report a security concern" channel.
Maturity 🔴 — No training, phishing simulation, or documented joiner/leaver security process. (Finding F-33.) Added in the iteration-1 completeness review (ISO 27001 A.6 / CIS v8 #14 / SOC 2 CC1–CC2).