Audit logs append-only: no deletion, modification, or truncation

An audit log that can be edited or deleted is not an audit log — it is a mutable ledger that any database administrator, compromised application role, or insider threat can silently rewrite. SOX §404 requires that internal controls over financial reporting be reliable; a log table with UPDATE or DELETE grants on the application role fails that test on its face. PCI-DSS 4.0 Req-10.3 requires protection of audit logs from destruction and unauthorized modification. FINRA Rule 4511 (book-and-records) requires that records be preserved in a non-rewriteable, non-erasable format. NIST 800-53 AU-9 mandates protection of audit information from unauthorized access, modification, and deletion. CWE-284 (Improper Access Control) is the vulnerability class. An attacker who gains write access to a role that can UPDATE transaction_logs can backdate or erase evidence of fund transfers with no trace.

Explicitly REVOKE modification permissions in a migration under db/migrations/ or supabase/migrations/ — implicit defaults are not sufficient and do not count as pass:

REVOKE ALL ON transaction_logs FROM app_role;
GRANT INSERT, SELECT ON transaction_logs TO app_role;
-- Only a superuser/DBA role may ever touch rows
GRANT ALL ON transaction_logs TO dba_role;

For PostgreSQL with row-level security, add an INSERT-only policy and intentionally leave out UPDATE and DELETE policies so those operations are denied by default:

ALTER TABLE transaction_logs ENABLE ROW LEVEL SECURITY;
CREATE POLICY rls_insert_only ON transaction_logs
  FOR INSERT TO app_role WITH CHECK (true);
-- No UPDATE/DELETE/TRUNCATE policy means those paths are blocked.