Security And Compliance

Security and Compliance

Overview

Read .forge/architecture.md and .forge/contracts/ to produce .forge/security.md — a comprehensive security and compliance assessment. The output must identify every data store, every trust boundary, and every regulatory requirement before any code is written.

When to Use

• .forge/architecture.md exists and the system handles user data
• Regulatory requirements apply (GDPR, CCPA, SOC 2, HIPAA, PCI-DSS)
• System has multi-tenant data or PII
• Pre-launch security gate or investor due diligence

When NOT to Use

• No architecture exists — run architecture-and-contracts first
• Looking for code-level vulnerabilities — use code-review-and-quality security axis
• Emergency security incident — that's incident response, not planning

Common Rationalizations

Red Flags

• No data classification scheme (what's sensitive vs. public)
• Multi-tenant system with no Row-Level Security or tenant isolation plan
• PII inventory is empty ("we don't store PII" without audit)
• Vendor list has no security assessment
• Threat model is missing or covers fewer than 5 attack vectors
• "We'll encrypt everything" without specifying what, how, and who manages keys

Core Process

Step 1: Authentication model

Define: identity provider, session management, token format, expiry policy, MFA requirements, credential storage. Map auth flow for every user type in the PRD.

Step 2: Data isolation

For multi-tenant systems: tenant isolation strategy (separate DBs, shared DB with RLS, schema-per-tenant). For single-tenant: user-level access controls. Document: how is tenant A prevented from seeing tenant B's data?

Step 3: PII inventory

Audit every data store. For each:

• What PII is stored (name, email, phone, address, payment, behavioral)
• Retention policy (how long, deletion trigger)
• Access controls (who can read, who can write)
• Encryption status (at rest, in transit)

Step 4: Regulatory scan

Based on the PII inventory and target market:

• Which regulations apply (GDPR, CCPA, HIPAA, PCI-DSS, SOC 2)?
• What consent mechanisms are required?
• What data subject rights must be supported (access, deletion, portability)?
• What breach notification requirements exist?

Step 5: Encryption audit

For each data flow and store:

• In transit: TLS version, certificate management
• At rest: encryption algorithm, key management (who holds keys, rotation policy)
• Application-level: field-level encryption for highly sensitive data

Step 6: Vendor assessment

Every third-party service or API:

• What data do they receive?
• What is their security posture (SOC 2, ISO 27001, BAA)?
• What happens to data if the vendor is breached?
• Is there a DPA (Data Processing Agreement)?

Step 7: Certification roadmap

Based on regulatory scan and sales requirements:

• Which certifications to pursue and in what order
• Timeline and estimated cost
• Gaps between current posture and certification requirements

Step 8: STRIDE threat model

For each trust boundary in the architecture:

• Spoofing: can an attacker impersonate a user or service?
• Tampering: can data be modified in transit or at rest?
• Repudiation: can actions be denied without audit trail?
• Information disclosure: can unauthorized parties access sensitive data?
• Denial of service: can the system be overwhelmed?
• Elevation of privilege: can a user gain unauthorized access?

Prioritize by likelihood × impact. Top 5 threats get specific mitigations.

Output

Write .forge/security.md with all sections above.

After writing: "Security assessment written to .forge/security.md."

Verification

• .forge/architecture.md read before starting
• Every data store has a retention policy
• PII inventory covers all user-facing data
• Every third-party vendor assessed
• STRIDE threat model covers at least 5 attack vectors with mitigations
• Certification roadmap has specific timelines
• Multi-tenant isolation strategy is explicit (if applicable)
• .forge/security.md written