Skip to content

🔄 Secrets Rotation Policy

🎯 Overview

Regular rotation of secrets reduces the window of opportunity for compromised credentials to be exploited. This policy defines rotation schedules and procedures for all AudioLab secrets.

⏰ Rotation Frequency

╔════════════════════════════════════════════════════════════════╗ ║ Secret Type │ Rotation Period │ Rationale ║ ╠════════════════════╪═════════════════╪════════════════════════╣ ║ Passwords │ 90 days │ Industry standard ║ ║ API Keys │ 180 days │ Less directly exposed ║ ║ Certificates │ Pre-expiration │ Managed by CA ║ ║ Access Tokens │ 30 days │ Short-lived by design ║ ║ Database Creds │ 90 days │ Critical infrastructure║ ║ CI/CD Tokens │ 180 days │ Controlled environment ║ ╚════════════════════════════════════════════════════════════════╝

📅 Scheduled Rotation Procedure

1. Preparation (T-7 days)

  • Identify secrets due for rotation
  • Notify team members
  • Schedule maintenance window if needed
  • Prepare rollback plan

2. Generation (T-1 day)

  • Generate new credentials/keys
  • Test new credentials in staging
  • Document new credential location
  • Update Vault/secret store

3. Deployment (T-0)

  • Update production environment variables
  • Deploy updated configurations
  • Verify all services operational
  • Monitor for authentication errors

4. Cleanup (T+1 day)

  • Revoke old credentials
  • Remove old secrets from all locations
  • Update documentation
  • Archive rotation logs

🚨 Emergency Rotation

Triggers

Immediate rotation required when: 1. Potential Compromise Detected - Security scan shows exposed secret - Suspicious access patterns - Intrusion detection alert

  1. Personnel Changes
  2. Employee departure
  3. Contractor project end

  4. Role change removing access need

  5. Public Exposure

  6. Accidentally committed to GitHub
  7. Exposed in logs or error messages
  8. Shared via insecure channel

  9. Found in public paste/leak sites

  10. Vendor Security Incident

  11. Third-party service breach
  12. Provider security advisory
  13. Known vulnerability in secret storage

Emergency Process

┌─────────────────────────────────────────────────────────────┐
│ EMERGENCY ROTATION TIMELINE                                 │
├─────────────────────────────────────────────────────────────┤
│ T+0 min:   Detect & confirm exposure                        │
│ T+5 min:   Notify security team & stakeholders              │
│ T+10 min:  Revoke compromised secret IMMEDIATELY            │
│ T+15 min:  Generate new secret                              │
│ T+30 min:  Deploy new secret to all systems                 │
│ T+60 min:  Verify all systems operational                   │
│ T+24 hr:   Post-mortem & documentation                      │
└─────────────────────────────────────────────────────────────┘

Step-by-Step Emergency Rotation

Step 1: Immediate Revocation (< 10 minutes)

# Example: Revoke GitHub token
gh auth refresh --scopes repo,write:packages

# Example: Revoke API key via admin panel
curl -X DELETE https://api.audiolab.com/admin/keys/$KEY_ID \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Step 2: Generate New Secret (< 15 minutes)

# Use secure random generation
openssl rand -base64 32

# Or use password manager's generator
# Or service-specific generation (GitHub, AWS, etc.)

Step 3: Emergency Deployment (< 1 hour)

# Update Vault
vault kv put secret/audiolab/prod api_key="NEW_KEY_HERE"

# Update CI/CD secrets
gh secret set API_KEY --body "NEW_KEY_HERE"

# Restart affected services
kubectl rollout restart deployment/audiolab-api

Step 4: Verification

  • All production services running
  • No authentication errors in logs
  • Health checks passing
  • Monitoring dashboards green

Step 5: Incident Documentation

Create post-mortem document including: - What was exposed and how - Detection method and timeline - Response actions taken - Root cause analysis - Prevention measures

🔍 Detection & Monitoring

Automated Secret Scanning

# .github/workflows/secret-scan.yml
name: Secret Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: trufflesecurity/trufflehog@main

Tools

  • TruffleHog: Scan git history for secrets
  • git-secrets: Prevent committing secrets
  • GitHub Secret Scanning: Automatic detection
  • GitGuardian: Real-time secret detection

📋 Rotation Checklist Template

### Secret Rotation: [SECRET_NAME]
**Date:** [YYYY-MM-DD]
**Rotated By:** [NAME]
**Type:** [Scheduled / Emergency]

#### Pre-Rotation
- [ ] Old secret documented
- [ ] New secret generated
- [ ] Staging test passed
- [ ] Team notified

#### Rotation
- [ ] New secret deployed to Vault
- [ ] Environment variables updated
- [ ] Services restarted
- [ ] Verification tests passed

#### Post-Rotation
- [ ] Old secret revoked
- [ ] Documentation updated
- [ ] No errors in logs (24h)
- [ ] Rotation logged in audit system

🏛️ Governance

Responsibilities

Role Responsibility
Security Team Define policies, oversee rotations, handle emergencies
DevOps Team Execute rotations, update infrastructure
Developers Update applications, test with new secrets
Team Leads Approve rotation schedules, sign off on completions

Audit Trail

All rotations must be logged with: - Timestamp - Operator identity - Secret identifier (not value!) - Rotation type (scheduled/emergency) - Verification status