[Audit] Operationalize SecurityAuditService

[2witstudios]

Summary

SecurityAuditService and the security_audit_log hash chain are implemented, but they are not operationalized across core auth/authz/runtime paths.

Evidence

• packages/db/src/schema/security-audit.ts:30 defines broad security event types (auth.*, authz.*, data.*, admin.*, security.*).
• packages/lib/src/audit/security-audit.ts:102 provides the tamper-evident service with hash-chain insert logic and convenience methods for auth/token/access/rate-limit events.
• Runtime usage of the service is currently limited to anomaly detection: packages/lib/src/security/anomaly-detection.ts:298 (securityAudit.logAnomalyDetected(...)).
• Common runtime helpers (logAuthEvent, logSecurityEvent) only emit to structured logs, not to security_audit_log: packages/lib/src/logging/logger-config.ts:174 and packages/lib/src/logging/logger-config.ts:199.

Problem

The platform has a strong immutable security-audit subsystem, but most high-value events are still only in standard logs. This creates a gap between “designed” and “operationalized” auditability.

Enterprise Impact

• Inconsistent security-event coverage in tamper-evident records.
• Harder evidence collection for SOC 2 / ISO 27001 / customer due diligence.

Proposed Work

1. Define a canonical mapping from runtime security/auth events to SecurityEventType.
2. Add a shared adapter (or event bus hook) so logAuthEvent / logSecurityEvent can optionally fan out into securityAudit.logEvent(...).
3. Wire critical flows first: login success/failure, access denied, token lifecycle, privileged admin reads/changes.
4. Ensure failures in audit writes are non-blocking for request path but visible (warn/error with correlation IDs).

Acceptance Criteria

• Critical auth/authz/token/admin runtime paths write tamper-evident entries to security_audit_log.
• Mapped entries include correlation fields where available (userId, sessionId, requestId, ipAddress, resourceType, resourceId).
• Unit/integration tests verify entries are produced for representative success/failure/denied scenarios.
• Documentation lists guaranteed audited event classes and known exclusions.