Security Domains

Owner	Classification	Version	Effective	Next review	Status
Sekhar Prakash	Internal	1.4	2026-06-24	2026-11-27	Active

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.

Maturity summary

#	Domain	Maturity	Key gap	Findings
1	Governance & Risk Management	🔴	No program, owner, or risk register	—
2	Data Security & Privacy	🟠	Classification, retention, KMS, privacy ops	—
3	Edge & Network Security	🟠	Security headers; Temporal TLS off	F-05, F-10
4	Identity & Access Management	🔴	No MFA; tokens JS-readable (password hashing fixed)	F-07, F-23, F-28
5	Application Security — incl. AI/LLM	🔴	CORS, headers, v-html, LLM keys; raw-SQL class not closed	F-04, F-05, F-08, F-14, F-42
6	API Security	🔴	Wildcard CORS, filter BOLA, unbounded paging	F-04, F-06, F-09, F-26, F-27
7	Tenant Isolation	🟠	Binding landed; no RLS backstop, no CI cross-tenant test	F-19, F-38
8	Software Supply Chain Security	🟠	No signing, SBOM, scan-gate, pinning	F-20
9	Cloud & Infrastructure Security	🟠	KMS CMKs, IAM scoping, S3, rotation	F-12, F-18
10	Container & Runtime Security	🔴	No scanning, no hardening, :latest	F-20
11	Monitoring & Detection	🟠	CloudTrail and Security Hub still absent	F-11
12	Incident Response	🟠	No security/breach-notification IR plan	—
13	Business Continuity & DR	🟠	No RPO/RTO; no restore drills	—
14	Secure SDLC & DevSecOps	🟠	No SAST/DAST gate, pentest, VDP	F-22, F-24
15	Compliance & Audit Readiness	🔴	No framework; evidence not started	—
16	Financial Data Integrity	🔴	Falsifiable audit trail; no tamper-evidence	F-15, F-25
17	Business Logic Security	🟠	Server-side guards unverified	F-16
18	Third-party / Vendor & Sub-processor Risk	🟠	Register exists; DPAs / attestations not recorded	—
19	Endpoint & Workstation Security	🔴	No documented endpoint baseline	F-32
20	People & Security Awareness	🔴	No training, phishing sim, joiner/leaver	F-33

---

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 🔴 (re-verified 2026-09-10) — No MFA; tokens JS-readable. Password hashing fixed (F-40 ✅, 2026-09-09) — argon2id via Bun.password, with legacy SHA-256 rows upgraded in place on next successful login. RBAC now enforced server-side on finance endpoints (F-02 ✅ resolved — requirePermission 403s by default and the permission catalogue + role grants are seeded), so authorization is no longer the open gap here — MFA (F-23) and token handling (F-07) are. (Findings F-07, F-23; F-02 resolved.)

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 🔴 (re-verified 2026-09-10) — Both tracked SQL injections fixed (F-03, F-39 ✅, 2026-09-09), but the class is not closed: queryRawUnsafe/executeRawUnsafe remain in use across 25+ files, and verifying the F-03 fix immediately surfaced a third instance in the recon filter primitive added by the same pull (F-42). The durable fix is a lint/SAST rule banning the raw-SQL API outside an allowlist, not a fourth point-fix. Still open: permissive CORS, missing headers, unsanitized v-html, no prompt sanitization, shared LLM keys. (Findings F-04, F-05, F-08, F-14, F-42; F-03, F-39 resolved.)

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 🟠 (re-verified 2026-09-10) — Tenant binding landed (F-01 ✅, 2026-09-04). x-blitz-tenant-id is now bound to the caller's identity at two enforcement points (libs/tenancy/src/plugins/tenantbinding.ts): the resolver checks the unverified claim before a Prisma client is selected, and the authenticator re-checks the verified payload against the resolved tenant — covering the Host-resolved path too, and failing closed when no tenant resolves. Remaining gaps: no Postgres RLS backstop (D7-02), no automated cross-tenant test in CI (D7-06) — the code's own comment notes a regression here is silent, so the fix is currently unguarded — and the connection-cache key bug (F-19). Also here: Temporal workflow visibility is not tenant-scoped (F-38) — /wf read/manage routes span all tenants; latent today (no tenant-side role holds system:workflow:*), a cross-tenant read+terminate the moment one does. (Findings F-19, F-38; F-01 resolved.)

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 procedure exists in Run & Operate; 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 🔴 (re-verified 2026-08-06) — Audit tables exist for journal/reconciliation; invoices lighter; no cryptographic tamper-evidence. Audit/identity fields: partial fix (F-25). A runtime scan on 2026-09-23 (routes as served) found 39 Tier-1 routes where a caller can still set approval/certification actors or write audit and history tables directly, plus 2 approval writes with no trusted actor; 47 lower-risk Tier-2 routes are tracked as F-54. lint:security R1/R5 now ratchet on that scan, so the count can only go down. Tamper-evidence is moot until the source is fully trustworthy. (Findings F-15, F-25 partial.)

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 🟠 — A Subprocessor Register now exists and is authoritative (12 entries, with purpose, data category, location and DPA/assurance per vendor). What is still missing is the assurance half: DPAs and current attestations are not recorded for most entries, and data-flow mapping per vendor is not done.

This page deliberately does not restate the vendor list — it previously carried its own 12-item inventory that had drifted from the register (naming Syncfusion, Sentry and MindsDB, which the register does not list, while omitting Valkey and Cloudflare Pages). Per Vendor & Subprocessor Risk, the register is the single list.

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).

Revision history

Version	Date	Author	Change
1.0	2026-06-24	Sekhar Prakash	20 domains defined with objective, target-state controls, and maturity.
1.1	2026-07-10	Sekhar Prakash	Maturity re-scored against main.
1.2	2026-08-26	Sekhar Prakash	Maturity re-scored; new findings mapped to domains.
1.3	2026-08-28	Sekhar Prakash	Added row-per-domain Maturity summary table (maturity, key gap, linked findings) near the top; per-domain sections unchanged.
1.4	2026-09-10	Sekhar Prakash	Re-scored against verified fixes: D7 🔴→🟠 (tenant binding landed); D4/D5 narratives updated (argon2id, both SQLi closed); raw-SQL class gap and F-42 recorded.

Finaisse Internal — Confidential. Not for external distribution.