Security alerts monitored and acted upon

CMMC 2.0 SI.L1-3.14.4 (NIST 800-171r2 3.14.4) requires that organizations identify and report security alerts and advisories in a timely manner. Without error monitoring, failed authentication attempts, rate limit hits, and access denials are written to console.log and lost on the next pod restart. Security incidents in FCI-handling systems go undetected until a user reports a symptom — often long after the breach. ISO 27001:2022 A.8.16 (Monitoring activities) reinforces this as a required operational control. The absence of a security contact (SECURITY.md or security.txt) also means external researchers have no path to report vulnerabilities responsibly.

Configure Sentry or equivalent for real-time error alerting and add structured security event logging to lib/security-log.ts. Create a security contact file so external reporters have a path:

// instrumentation-client.ts (Next.js)
import * as Sentry from '@sentry/nextjs'
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  beforeSend(event) {
    // Strip PII before sending to Sentry
    if (event.user) { delete event.user.email; delete event.user.ip_address }
    return event
  },
})

// lib/security-log.ts
export function logSecurityEvent(
  event: 'auth_failure' | 'rate_limited' | 'access_denied',
  ctx: { ip?: string; path?: string; userId?: string }
) {
  console.log(JSON.stringify({ type: 'security_event', event, ...ctx, ts: new Date().toISOString() }))
}

Create public/.well-known/security.txt:

Contact: security@yourcompany.com
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en

SI.L1-3.14.4 requires at least 2 of the 3 monitoring mechanisms — error alerting, structured security logging, and documented security contact.