Database credentials are rotated on a defined schedule

A database password that has never been rotated since project creation has been exposed to every team member who ever had environment access, every CI system that logged the connection string, and any third-party service that consumed it. CWE-255 captures long-lived credentials as a vulnerability class: the longer a credential is in use without rotation, the larger the set of people and systems that have seen it. A defined rotation schedule limits the exposure window for any past compromise that has not yet been detected.

Document a 90-day rotation schedule in SECURITY.md and set a calendar reminder. For production systems, prefer AWS Secrets Manager or Doppler with automatic rotation.

# SECURITY.md — Credential Rotation Policy

## Database Credentials
- Rotation schedule: every 90 days
- Rotation procedure:
  1. Generate new password: openssl rand -base64 32
  2. Update DB user: ALTER USER app_user WITH PASSWORD 'new_password';
  3. Update secret in Vercel/AWS/Doppler env configuration
  4. Redeploy application
  5. Verify application health, then document rotation date below

Last rotated: [date]

For AWS RDS, configure Secrets Manager rotation: aws secretsmanager rotate-secret --secret-id myapp/db-credentials --rotation-rules '{"AutomaticallyAfterDays": 90}'. For Supabase, reset the database password in Dashboard > Settings > Database and update all deployment environments.

• ID: database-design-operations.backup-recovery.credential-rotation

• Severity: low

• What to look for: Enumerate every database credential type in use (connection string password, API keys, service role keys) and look for documentation of credential rotation policy. Evidence includes: (1) A security policy document or SECURITY.md mentioning rotation schedule. (2) Integration with a secrets manager that auto-rotates (AWS Secrets Manager with rotation lambda, HashiCorp Vault, Doppler). (3) Evidence in deployment history or git log of credential changes (without exposing the credentials themselves). (4) Infrastructure-as-code that provisions credentials with rotation configuration. Check if the project uses long-lived, static database passwords versus short-lived or auto-rotating credentials. For Supabase: database passwords can be reset in the dashboard, check if there's a policy to do so. For AWS RDS: check for Secrets Manager integration with auto-rotation.

• Pass criteria: At least 1 credential rotation policy is documented (e.g., every 90 days) and adhered to, OR a secrets manager with automatic rotation is in use. Rotation policy is actionable — there is a defined process for rotating credentials with minimal downtime.

• Fail criteria: No credential rotation policy. Same database password since project creation with no documented intent to rotate. No secrets manager, no rotation schedule, no documentation.

• Skip (N/A) when: Using IAM database authentication (AWS RDS IAM auth, Google Cloud SQL IAM auth) where tokens are short-lived and auto-managed. Or using a managed service that handles credential rotation automatically with no user-managed password.

• Detail on fail: Example: "No credential rotation policy found. No secrets manager. Database password appears to have been set at project creation and never rotated.".

• Remediation: Establish a rotation schedule and tooling:

  Option A — Manual rotation on a schedule (minimum viable):
  1. Document the rotation schedule in SECURITY.md: "Database credentials rotated every 90 days"
  2. Set a recurring calendar reminder for credential rotation
  3. Rotation procedure:
     a. Generate a new strong password: openssl rand -base64 32
     b. Update the database user password: ALTER USER app_user WITH PASSWORD 'new_password';
     c. Update the secret in your secrets manager/env var provider (Vercel, Netlify, AWS, etc.)
     d. Redeploy the application to pick up the new credentials
     e. Verify the application is working with the new credentials
     f. Document the rotation date in SECURITY.md
  
  Option B — AWS Secrets Manager with auto-rotation (recommended for production):
  

  // AWS Secrets Manager rotation lambda (simplified)
  // Rotates credentials automatically on a schedule
  // Configure via AWS Console or Terraform:
  // aws secretsmanager rotate-secret --secret-id myapp/db-credentials
  //   --rotation-lambda-arn arn:aws:lambda:... --rotation-rules '{"AutomaticallyAfterDays": 90}'
  

  For Supabase: document that the database password is managed in the Supabase dashboard and set a 90-day rotation reminder.