sinapse-ai 9.3.0 → 9.4.0

package/squads/squad-cybersecurity/knowledge-base/compliance-frameworks.md

@@ -0,0 +1,273 @@
+# Compliance Frameworks Reference
+
+## Purpose
+
+Deep reference for LGPD, ISO 27001, SOC 2, and PCI DSS — requirements, implementation guidance, and decision-making support. Used by Govern (compliance-officer) for gap assessments, policy work, and remediation planning.
+
+---
+
+## LGPD — Lei Geral de Proteção de Dados
+
+### Overview
+
+- **Law:** Lei 13.709/2018
+- **Effective:** August 2020
+- **Enforced by:** ANPD (Autoridade Nacional de Proteção de Dados)
+- **Scope:** Applies to any processing of personal data of individuals in Brazil, regardless of where the processor is located
+- **Model:** Based heavily on EU GDPR but with Brazilian context
+
+**Critical 2025 Update:** The ANPD became an **independent regulatory agency** in 2025 via Medida Provisória 1.317/2025, giving it full autonomy. This significantly increases enforcement capacity and risk of penalties.
+
+### LGPD vs. GDPR — Key Differences
+
+| Aspect | LGPD | GDPR |
+|--------|------|------|
+| Data residency | Not explicitly required | Not explicitly required |
+| International transfers | SCCs required (from Aug 2025) | SCCs or adequacy decision |
+| DPO mandatory? | Yes (Encarregado) | Yes for certain controllers |
+| Right to explanation (AI) | Article 20 | Article 22 |
+| Penalties | Up to 2% of revenue in Brazil, max R$ 50M | Up to 4% of global revenue |
+| Children's data | Article 14 — special protection | Article 8 GDPR |
+| Legal age for consent | 18 (children need parental consent) | 16 (member state variation) |
+
+### Key Articles — Technical Implementation
+
+| Article | Requirement | Technical Implementation |
+|---------|-------------|------------------------|
+| **Art. 7-8** | Lawful basis for processing — consent must be explicit | Opt-in forms (never pre-checked), granular consent per purpose |
+| **Art. 9** | Transparency — inform data subjects | Privacy policy, accessible and plain language |
+| **Art. 11** | Sensitive data special protection | Extra security controls for health, biometric, political, religious data |
+| **Art. 14** | Children's data | Parental consent mechanism, age verification |
+| **Art. 18** | Data subject rights | Portal: access, correction, deletion, portability, revoke consent |
+| **Art. 20** | Automated decision-making | Ability to request human review of algorithmic decisions |
+| **Art. 33** | International data transfers | SCCs required (grace period ended Aug 23, 2025) |
+| **Art. 38** | RIPD (DPIA) | Data Protection Impact Assessment for high-risk processing |
+| **Art. 41** | DPO (Encarregado) | Designate and publish contact; ANPD registration if required |
+| **Art. 46** | Security measures | Encryption, access control, RLS, incident procedures |
+| **Art. 48** | Breach notification | 3 business days to ANPD + data subjects |
+
+### LGPD Technical Checklist
+
+```
+Consent Management
+[ ] Opt-in forms with explicit, specific consent (not pre-checked)
+[ ] Separate consent per processing purpose
+[ ] Consent withdrawal mechanism as easy as giving consent
+[ ] Consent records stored with timestamp and mechanism
+
+Data Subject Rights Portal
+[ ] Data export endpoint (download my data)
+[ ] Data correction form or interface
+[ ] Account/data deletion mechanism
+[ ] Consent revocation mechanism
+[ ] Response within 15 days (LGPD Art. 19)
+
+DPO (Encarregado)
+[ ] Designated DPO with name and contact published on website
+[ ] DPO contactable for data subject requests
+[ ] ANPD registration if organization qualifies
+
+Technical Security (Art. 46)
+[ ] TLS 1.2+ on all data transmission
+[ ] Encryption at rest for personal data
+[ ] Access control with least privilege
+[ ] Audit logging for personal data access
+[ ] RLS policies in database
+
+Breach Response (Art. 48)
+[ ] Incident detection capability
+[ ] Breach notification procedure documented
+[ ] ANPD contact and form known
+[ ] Data subjects notification template ready
+[ ] 3 business day timeline enforced
+
+International Transfers (Art. 33, since Aug 2025)
+[ ] Standard Contractual Clauses (SCCs) executed with all vendors
+[ ] Data processing agreements with international processors
+[ ] Transfer impact assessments for high-risk destinations
+```
+
+### ANPD Enforcement Priorities 2025-2026
+
+Based on ANPD public statements:
+1. **Children's data** — apps used by minors, parental consent, age verification
+2. **AI and biometric data** — facial recognition, automated profiling
+3. **Data scraping** — web scraping of personal data without consent
+4. **Health data** — medical records, health apps
+
+Organizations in these sectors should expect active inspections.
+
+---
+
+## ISO/IEC 27001:2022
+
+### Overview
+
+- **Standard:** ISO/IEC 27001:2022 (latest revision — 93 controls vs. 114 in 2013 version)
+- **Result:** Certification (audited by accredited certification body)
+- **Scope:** Information Security Management System (ISMS)
+- **Approach:** Risk-based — implement controls proportional to identified risks
+- **Timeline:** 6-18 months for initial certification
+- **Cost:** $30,000–$200,000+ depending on organization size
+
+### The 4 Control Themes (Annex A, 2022 revision)
+
+| Theme | Controls | Coverage |
+|-------|----------|---------|
+| **Organizational** | 37 controls | Policies, risk management, supplier relationships, incident management |
+| **People** | 8 controls | Screening, training, responsibilities, disciplinary process |
+| **Physical** | 14 controls | Physical security, physical media, clean desk |
+| **Technological** | 34 controls | Access control, cryptography, logging, vulnerability management |
+
+### ISO 27001 Clauses (Mandatory)
+
+| Clause | Requirement |
+|--------|-------------|
+| **4** | Understanding the organization — context, interested parties, ISMS scope |
+| **5** | Leadership — top management commitment, policies |
+| **6** | Planning — risk assessment, risk treatment, objectives |
+| **7** | Support — resources, competence, awareness, communication, documentation |
+| **8** | Operation — risk treatment implementation, supplier assessment |
+| **9** | Performance evaluation — monitoring, internal audit, management review |
+| **10** | Improvement — nonconformities, corrective action, continual improvement |
+
+### New Controls in 2022 (not in 2013)
+
+These 11 new controls reflect modern threats:
+- Threat intelligence
+- Information security for use of cloud services
+- ICT readiness for business continuity
+- Physical security monitoring
+- Configuration management
+- Information deletion
+- Data masking
+- Data leakage prevention
+- Monitoring activities
+- Web filtering
+- Secure coding
+
+---
+
+## SOC 2 (Service Organization Controls 2)
+
+### Overview
+
+- **Standard:** AICPA Trust Services Criteria
+- **Result:** Attestation report (not certification)
+- **Scope:** Controls relevant to security, availability, processing integrity, confidentiality, privacy of service organizations
+- **Timeline:** Type I: 2-3 months | Type II: 6-12 months (observation period)
+- **Cost:** $20,000–$100,000+
+
+### Type I vs. Type II
+
+| Aspect | Type I | Type II |
+|--------|--------|---------|
+| What it says | Controls are suitably designed at a point in time | Controls operated effectively over a period (usually 6+ months) |
+| Timeline | 2-3 months | 6-12 months (observation period required) |
+| Value | Faster to achieve, good starting point | Higher assurance, preferred by enterprise buyers |
+| When to get | Startup needing to close first enterprise deals | Established product with running controls |
+
+### The 5 Trust Service Criteria
+
+| Criterion | Abbreviation | Scope |
+|-----------|-------------|-------|
+| **Security** | CC (Common Criteria) | The baseline — every SOC 2 includes this |
+| **Availability** | A | System available for operation as committed |
+| **Processing Integrity** | PI | System processing is complete, accurate, timely |
+| **Confidentiality** | C | Information designated as confidential is protected |
+| **Privacy** | P | Personal information collected in accordance with privacy commitments |
+
+Most SaaS startups pursue Security + Availability + Confidentiality initially.
+
+### SOC 2 Common Criteria — Technical Controls
+
+Key CC categories with technical implementation:
+
+| CC Category | Examples of Evidence Needed |
+|-------------|--------------------------|
+| **CC6 — Logical and Physical Access** | MFA, access reviews, offboarding procedures, privileged access management |
+| **CC7 — System Operations** | Monitoring, alert management, incident response, change management |
+| **CC8 — Change Management** | Code review process, deployment approvals, environment separation |
+| **CC9 — Risk Mitigation** | Vendor management, business continuity, encryption at rest and transit |
+
+---
+
+## PCI DSS v4.0
+
+### Overview
+
+- **Standard:** Payment Card Industry Data Security Standard v4.0
+- **Effective:** March 2024 (v3.2.1 retired March 2024)
+- **Scope:** Any organization that stores, processes, or transmits cardholder data
+- **Managed by:** PCI Security Standards Council
+- **Validation levels:** SAQ (Self-Assessment) for smaller merchants, QSA audit for larger
+
+### 12 Requirements in 6 Goals
+
+| Goal | Requirements |
+|------|-------------|
+| **Build and Maintain Secure Network** | R1: Firewalls; R2: No vendor defaults |
+| **Protect Cardholder Data** | R3: Store data securely; R4: Encrypt transmission |
+| **Vulnerability Management** | R5: Anti-malware; R6: Secure systems |
+| **Access Control** | R7: Restrict access; R8: Identify and authenticate; R9: Physical access |
+| **Monitor and Test** | R10: Log all access; R11: Test regularly |
+| **Information Security Policy** | R12: Maintain policy |
+
+### Scope Reduction Strategy
+
+**Use a tokenization/hosted payment page to minimize scope:**
+```
+In scope (if you collect card data directly):
+- All systems that process, store, or transmit card data
+- All systems in the same network segment
+- All administration systems for above
+
+Minimal scope (using hosted payment fields / tokenization):
+- Only your tokenization provider integration
+- SAQ A is sufficient (lowest level — just questionnaire)
+```
+
+**Recommended approach for most web apps:** Use Stripe, Braintree, or Adyen hosted payment fields. Card data never touches your servers. Scope reduces to SAQ A.
+
+---
+
+## Compliance Comparison Matrix
+
+| Aspect | LGPD | ISO 27001 | SOC 2 | PCI DSS |
+|--------|------|-----------|-------|---------|
+| **Focus** | Privacy | InfoSec management | Trust for service orgs | Payment card security |
+| **Result** | Compliance (legal) | Certification | Attestation report | Certificate/Report |
+| **Mandatory for** | Brazilian personal data | Voluntary (market-driven) | Enterprise B2B customers | Card processing |
+| **Geographic focus** | Brazil | Global | North America primary | Global |
+| **Timeline** | Ongoing | 6-18 months | 2-12 months | Variable |
+| **Overlap with others** | ~40% with GDPR | ~70% with SOC 2 | ~70% with ISO 27001 | — |
+
+### When to Pursue Which
+
+| Situation | Recommendation |
+|-----------|---------------|
+| Any Brazilian personal data | LGPD is mandatory — not optional |
+| Selling B2B SaaS to US companies | SOC 2 Type I first — reduces friction in deals |
+| Selling globally or to European enterprises | ISO 27001 — globally recognized |
+| Processing payments | PCI DSS scope reduction (tokenization), then SAQ A |
+| Early-stage startup | Start with LGPD + SOC 2 Type I |
+| Scaling to enterprise | Add ISO 27001, then SOC 2 Type II |
+
+### Overlap Efficiency
+
+ISO 27001 and SOC 2 have ~70% control overlap. Pursuing both simultaneously is ~30% more efficient than sequential implementation:
+- Same policies serve both
+- Same control evidence collected once
+- Same training program covers both
+- Auditors can often share work product
+
+---
+
+## Sources
+
+- LGPD full text: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
+- ANPD official: https://www.gov.br/anpd/pt-br
+- ISO 27001:2022: https://www.iso.org/standard/27001
+- AICPA SOC 2: https://www.aicpa-cima.com/resources/article/soc-2-engagements
+- PCI DSS v4.0: https://www.pcisecuritystandards.org/
+- ICLG Brazil Data Protection 2025-2026: https://iclg.com/practice-areas/data-protection-laws-and-regulations/brazil

package/squads/squad-cybersecurity/knowledge-base/database-security.md

@@ -0,0 +1,438 @@
+# Database Security Reference
+
+## Purpose
+
+Comprehensive reference for database security — RLS, parameterized queries, encryption, audit logging, and Supabase-specific patterns. Used across all squad agents, particularly when reviewing or implementing data access controls.
+
+---
+
+## Row Level Security (RLS)
+
+### Why RLS Is Non-Negotiable
+
+RLS is the most critical security control for any Supabase-based application. In January 2025, 170+ applications built with Lovable were found with exposed databases (CVE-2025-48757) because developers did not enable RLS. **RLS is the difference between a secure app and a data breach.**
+
+### RLS Fundamentals
+
+```sql
+-- Enable RLS on a table
+ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
+
+-- CRITICAL: Without policies, NOBODY can access data (deny-all by default)
+-- You must create explicit policies for access
+
+-- Check which tables have RLS enabled
+SELECT tablename, rowsecurity
+FROM pg_tables
+WHERE schemaname = 'public';
+
+-- Find tables WITHOUT RLS (pre-deploy gate -- any result = blocker)
+SELECT tablename FROM pg_tables 
+WHERE schemaname = 'public' AND NOT rowsecurity;
+```
+
+### Core RLS Patterns
+
+```sql
+-- Pattern 1: Users see only their own data
+CREATE POLICY "users_own_data" ON profiles
+FOR SELECT TO authenticated
+USING ((SELECT auth.uid()) = user_id);
+
+-- Pattern 2: Users manage only their own data (all operations)
+CREATE POLICY "users_manage_own" ON profiles
+FOR ALL TO authenticated
+USING ((SELECT auth.uid()) = user_id)
+WITH CHECK ((SELECT auth.uid()) = user_id);
+
+-- Pattern 3: Publicly visible data (e.g., published posts)
+CREATE POLICY "public_published_posts" ON posts
+FOR SELECT
+USING (published = true);
+
+-- Pattern 4: Multi-tenant isolation (org-level)
+CREATE POLICY "tenant_isolation" ON orders
+FOR ALL TO authenticated
+USING (
+  org_id IN (
+    SELECT org_id FROM org_members
+    WHERE user_id = (SELECT auth.uid())
+  )
+);
+
+-- Pattern 5: Role-based access (admin can see all)
+CREATE POLICY "admin_full_access" ON profiles
+FOR ALL TO authenticated
+USING (
+  (SELECT auth.jwt() -> 'app_metadata' ->> 'role') = 'admin'
+);
+
+-- Pattern 6: Read for anyone, write only for owner
+CREATE POLICY "anyone_can_read" ON articles
+FOR SELECT
+USING (true);
+
+CREATE POLICY "owner_can_write" ON articles
+FOR INSERT OR UPDATE OR DELETE TO authenticated
+USING (author_id = (SELECT auth.uid()))
+WITH CHECK (author_id = (SELECT auth.uid()));
+```
+
+### RLS Performance Optimization
+
+| Technique | Performance Gain | Implementation |
+|-----------|-----------------|----------------|
+| Index policy columns | 99.94% | `CREATE INDEX idx_user ON table(user_id)` |
+| Wrap functions in SELECT | 94.97% | `(SELECT auth.uid()) = user_id` not `auth.uid() = user_id` |
+| Explicit role in FOR clause | 99.78% | `FOR SELECT TO authenticated` |
+| Subquery vs JOIN in policies | 99.78% | Use `IN (SELECT ...)` not JOIN |
+| Security definer functions | 99.993% | Cached auth lookups |
+
+```sql
+-- SLOW: Function evaluated per row
+USING (auth.uid() = user_id)
+
+-- FAST: Function evaluated once, cached for all rows (up to 95% faster)
+USING ((SELECT auth.uid()) = user_id)
+```
+
+### RLS Testing Patterns
+
+**Critical:** The Supabase SQL Editor bypasses RLS. Always test via the SDK as a regular user.
+
+```typescript
+// Test RLS via SDK -- this respects policies
+const supabase = createClient(url, anonKey)
+
+// Login as test user
+const { data: { session } } = await supabase.auth.signInWithPassword({
+  email: 'testuser@example.com',
+  // Use environment variable -- never hardcode credentials
+  password: process.env.TEST_USER_PASSWORD
+})
+
+// This will be filtered by RLS -- should only return this user's rows
+const { data, error } = await supabase.from('profiles').select('*')
+console.log('User sees:', data) // Should only see own data
+
+// Try accessing another user's data directly
+const { data: otherData } = await supabase
+  .from('profiles')
+  .select('*')
+  .eq('user_id', 'other-user-uuid')
+console.log('Should be empty:', otherData) // RLS should block this
+```
+
+### Views and RLS
+
+Views bypass RLS by default in PostgreSQL 14 and below. In PostgreSQL 15+:
+
+```sql
+-- PostgreSQL 15+ -- force view to respect RLS
+CREATE VIEW active_profiles WITH (security_invoker = true)
+AS SELECT * FROM profiles WHERE deleted_at IS NULL;
+
+-- Or use security_barrier for older PG versions
+CREATE VIEW user_profiles WITH (security_barrier = true)
+AS SELECT id, name, email FROM profiles;
+```
+
+---
+
+## SQL Injection Prevention
+
+### Parameterized Queries — Always
+
+```javascript
+// FORBIDDEN: String interpolation -- enables SQL injection
+const dangerous = `SELECT * FROM users WHERE name = '${userInput}'`
+
+// REQUIRED: Parameterized queries -- injection impossible
+const safe = 'SELECT * FROM users WHERE name = $1'
+const result = await db.query(safe, [userInput])
+
+// Supabase: always safe -- PostgREST is parameterized
+const { data } = await supabase.from('users').select('*').eq('name', userInput)
+
+// pg (node-postgres): safe
+const { rows } = await pool.query(
+  'SELECT * FROM users WHERE email = $1 AND active = $2',
+  [email, true]
+)
+
+// Prisma: safe
+const user = await prisma.user.findFirst({
+  where: { email: email }
+})
+```
+
+### Dynamic Queries — Safe Pattern
+
+When query structure must be dynamic, use identifier escaping:
+
+```javascript
+// For dynamic table/column names (rare -- prefer static)
+const { Client } = require('pg')
+const client = new Client()
+
+// NEVER: `SELECT * FROM ${tableName}` -- SQL injection
+// SAFE: Use pg's identifier escaping
+const safeQuery = `SELECT * FROM ${client.escapeIdentifier(tableName)}`
+```
+
+### Stored Procedures — Secure Pattern
+
+```sql
+-- SAFE: Function uses parameterized query internally
+CREATE OR REPLACE FUNCTION get_user_data(p_user_id UUID)
+RETURNS TABLE(id UUID, name TEXT) 
+SECURITY DEFINER
+SET search_path = public
+LANGUAGE plpgsql AS $$
+BEGIN
+  RETURN QUERY
+  SELECT u.id, u.name FROM users u WHERE u.id = p_user_id;
+END;
+$$;
+```
+
+---
+
+## Encryption
+
+### Encryption at Rest
+
+**PostgreSQL column-level encryption (pgcrypto):**
+```sql
+-- Enable pgcrypto extension
+CREATE EXTENSION IF NOT EXISTS pgcrypto;
+
+-- Encryption key comes from app setting (set via environment, not hardcoded)
+-- In app startup: SET app.encryption_key = '<value from secrets manager>'
+
+-- Encrypt sensitive data before storing
+INSERT INTO sensitive_data (user_id, ssn_encrypted)
+VALUES (
+  $1,
+  pgp_sym_encrypt($2, current_setting('app.encryption_key'))
+);
+
+-- Decrypt when reading
+SELECT 
+  user_id,
+  pgp_sym_decrypt(ssn_encrypted::bytea, current_setting('app.encryption_key')) AS ssn
+FROM sensitive_data
+WHERE user_id = $1;
+```
+
+**Supabase Vault — preferred for secrets:**
+```sql
+-- Store secret in Vault (key_name must be descriptive, value from env/secrets manager)
+SELECT vault.create_secret(
+  '<secret-value-from-env>',  -- Use env var -- never hardcode
+  'api_key_name',
+  'Description of what this key is for'
+);
+
+-- Read secret (decrypted on the fly)
+SELECT decrypted_secret FROM vault.decrypted_secrets WHERE name = 'api_key_name';
+
+-- CRITICAL: Disable statement logging before inserting secrets
+-- Otherwise plaintext appears in Supabase logs
+ALTER SYSTEM SET log_statement = 'none';
+SELECT pg_reload_conf();
+-- Insert secret here
+-- Re-enable
+ALTER SYSTEM SET log_statement = 'all';
+SELECT pg_reload_conf();
+```
+
+### Encryption in Transit
+
+```sql
+-- Force SSL for all direct connections
+ALTER SYSTEM SET ssl = on;
+ALTER SYSTEM SET ssl_min_protocol_version = 'TLSv1.2';
+
+-- Check current SSL status
+SHOW ssl;
+SELECT * FROM pg_stat_ssl;
+
+-- Verify client is using SSL
+SELECT pid, usename, ssl, version, cipher 
+FROM pg_stat_ssl 
+JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid;
+```
+
+---
+
+## Database Access Control
+
+### Least Privilege Roles
+
+```sql
+-- Application read-only role
+CREATE ROLE app_readonly;
+GRANT CONNECT ON DATABASE myapp TO app_readonly;
+GRANT USAGE ON SCHEMA public TO app_readonly;
+GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;
+ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO app_readonly;
+
+-- Application read-write role (no DDL)
+CREATE ROLE app_readwrite;
+GRANT CONNECT ON DATABASE myapp TO app_readwrite;
+GRANT USAGE ON SCHEMA public TO app_readwrite;
+GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_readwrite;
+GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO app_readwrite;
+ALTER DEFAULT PRIVILEGES IN SCHEMA public 
+  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_readwrite;
+
+-- Migration role (DDL allowed -- rotate credentials after migrations)
+CREATE ROLE app_migrations;
+GRANT ALL ON DATABASE myapp TO app_migrations;
+```
+
+### Supabase Key Management
+
+| Key | Where to Use | Security Level |
+|-----|-------------|---------------|
+| `anon` (publishable) | Frontend/client code | Respects RLS -- safe to expose |
+| `service_role` | Backend server only | Bypasses ALL RLS -- never expose to client |
+| Direct DB connection string | Migrations only | Highest privilege -- use secrets manager |
+
+```typescript
+// WRONG: service_role in frontend (bypasses RLS entirely)
+// NEVER: createClient(url, process.env.SUPABASE_SERVICE_ROLE_KEY) in browser code
+
+// RIGHT: anon key in frontend, service_role only on server
+// Frontend -- uses anon key via environment variable
+const clientSupabase = createClient(
+  process.env.NEXT_PUBLIC_SUPABASE_URL!,
+  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
+)
+
+// Server/API routes only -- service role from non-public env
+const adminSupabase = createClient(
+  process.env.SUPABASE_URL!,
+  process.env.SUPABASE_SERVICE_ROLE_KEY! // NOT prefixed with NEXT_PUBLIC_
+)
+```
+
+---
+
+## Audit Logging
+
+### Automatic Audit Log with Triggers
+
+```sql
+-- Audit log table
+CREATE TABLE audit_log (
+  id BIGSERIAL PRIMARY KEY,
+  table_name TEXT NOT NULL,
+  record_id UUID NOT NULL,
+  action TEXT CHECK (action IN ('INSERT', 'UPDATE', 'DELETE')),
+  old_data JSONB,
+  new_data JSONB,
+  changed_by UUID REFERENCES auth.users(id),
+  changed_at TIMESTAMPTZ DEFAULT now(),
+  ip_address INET,
+  user_agent TEXT
+);
+
+-- Generic trigger function
+CREATE OR REPLACE FUNCTION audit_trigger_func()
+RETURNS TRIGGER AS $$
+BEGIN
+  INSERT INTO audit_log (table_name, record_id, action, old_data, new_data, changed_by)
+  VALUES (
+    TG_TABLE_NAME,
+    COALESCE(NEW.id, OLD.id),
+    TG_OP,
+    CASE WHEN TG_OP IN ('UPDATE', 'DELETE') THEN row_to_json(OLD)::jsonb END,
+    CASE WHEN TG_OP IN ('INSERT', 'UPDATE') THEN row_to_json(NEW)::jsonb END,
+    auth.uid()
+  );
+  RETURN COALESCE(NEW, OLD);
+END;
+$$ LANGUAGE plpgsql SECURITY DEFINER;
+
+-- Apply to sensitive tables
+CREATE TRIGGER audit_profiles
+AFTER INSERT OR UPDATE OR DELETE ON profiles
+FOR EACH ROW EXECUTE FUNCTION audit_trigger_func();
+
+CREATE TRIGGER audit_transactions
+AFTER INSERT OR UPDATE OR DELETE ON financial_transactions
+FOR EACH ROW EXECUTE FUNCTION audit_trigger_func();
+```
+
+### RLS on Audit Log
+
+```sql
+-- Only admins can see the full audit log
+ALTER TABLE audit_log ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY "admin_see_all_audit"
+ON audit_log
+FOR SELECT TO authenticated
+USING (
+  (SELECT auth.jwt() -> 'app_metadata' ->> 'role') = 'admin'
+);
+
+-- Users can only see their own audit entries
+CREATE POLICY "users_see_own_audit"
+ON audit_log
+FOR SELECT TO authenticated
+USING (changed_by = (SELECT auth.uid()));
+```
+
+---
+
+## Common Database Security Misconfigurations
+
+| Misconfiguration | Risk | Fix |
+|----------------|------|-----|
+| Table with no RLS enabled | Anyone can read all data via API | `ALTER TABLE t ENABLE ROW LEVEL SECURITY` |
+| service_role key in frontend | Full database bypass | Move to server-side only |
+| SQL string concatenation | SQL injection | Use parameterized queries |
+| No SSL enforcement | Data in transit interceptable | Set `ssl_min_protocol_version = 'TLSv1.2'` |
+| Superuser app credentials | Privilege escalation trivial | Create least-privilege role |
+| No connection limits | Connection exhaustion DoS | Set `connection_limit` on roles |
+| Unencrypted sensitive columns | Data breach exposes plaintext | pgcrypto or Vault |
+| Public schema grants to public | PostgreSQL 14 default allows all public | `REVOKE ALL ON SCHEMA public FROM public` |
+| Statement logging enabled with secrets | Secrets in logs | Disable before inserting secrets |
+
+---
+
+## Pre-Deploy Database Security Gate
+
+```sql
+-- Run this before every production deployment
+-- Any row returned = BLOCKER
+
+-- 1. Tables without RLS
+SELECT 'TABLE_NO_RLS' as issue, tablename 
+FROM pg_tables 
+WHERE schemaname = 'public' AND NOT rowsecurity;
+
+-- 2. Overprivileged connections check
+SELECT 'SUPERUSER_APP' as issue, usename 
+FROM pg_user 
+WHERE usesuper = true AND usename != 'postgres';
+
+-- 3. Tables with no policies (RLS on but no policies = deny all)
+SELECT 'TABLE_NO_POLICIES' as issue, t.tablename
+FROM pg_tables t
+LEFT JOIN pg_policies p ON p.tablename = t.tablename AND p.schemaname = t.schemaname
+WHERE t.schemaname = 'public' AND t.rowsecurity = true AND p.policyname IS NULL;
+```
+
+---
+
+## Sources
+
+- Supabase RLS Documentation: https://supabase.com/docs/guides/database/postgres/row-level-security
+- Supabase Security Best Practices: https://supabase.com/docs/guides/security
+- CVE-2025-48757 (Lovable/RLS): https://nvd.nist.gov/vuln/detail/CVE-2025-48757
+- OWASP SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
+- PostgreSQL Security Documentation: https://www.postgresql.org/docs/current/security.html