[SECURITY] Audit all stored tokens and implement rotation schedule #10

Open
opened 2026-04-04 16:02:15 +00:00 by bezalel · 0 comments
Owner

Summary

Conduct a thorough audit of all API tokens, credentials, and secrets stored in Bezalel's environment. Implement a rotation schedule and secure storage practices.

Motivation

Tokens and credentials are the keys to the kingdom. Hardcoded or stale tokens are a security risk. An artisan wizard should know exactly what credentials exist, where they're stored, what they can access, and when they expire.

Acceptance Criteria

  • Create an inventory file at entries/security/token-inventory.md listing:
    • Token name/purpose (e.g., 'Gitea API token', 'Telegram bot token')
    • Storage location (file path, env var, config file)
    • Permission scope (what can this token do?)
    • Creation date (if known)
    • Expiration date (if any)
    • Last verified working date
  • NO actual token values in the inventory (only metadata)
  • Verify all tokens have restrictive file permissions (600 or tighter)
  • Check that no tokens are committed to any git repo in plaintext
    • Run git log --all -p | grep -i 'token\|secret\|password\|api_key' on all repos
  • Create a script scripts/token_audit.sh that:
    • Scans common locations for exposed secrets
    • Checks file permissions on known credential files
    • Verifies each token still works (API ping)
    • Reports findings in a structured format
  • Document a rotation procedure for each token type
  • Set up a reminder (Gitea issue or cron) to rotate tokens every 90 days
  • Investigate using environment variables or a secrets file with restricted permissions instead of inline tokens

Implementation Notes

  • Be VERY careful not to leak tokens in issue bodies, commit messages, or logs
  • Consider using git-secrets or similar tool to prevent future leaks
  • Profile.yaml and any config files should reference env vars, not raw tokens

Definition of Done

All tokens are inventoried, verified, properly permissioned, and a rotation schedule is in place.

## Summary Conduct a thorough audit of all API tokens, credentials, and secrets stored in Bezalel's environment. Implement a rotation schedule and secure storage practices. ## Motivation Tokens and credentials are the keys to the kingdom. Hardcoded or stale tokens are a security risk. An artisan wizard should know exactly what credentials exist, where they're stored, what they can access, and when they expire. ## Acceptance Criteria - [ ] Create an inventory file at `entries/security/token-inventory.md` listing: - Token name/purpose (e.g., 'Gitea API token', 'Telegram bot token') - Storage location (file path, env var, config file) - Permission scope (what can this token do?) - Creation date (if known) - Expiration date (if any) - Last verified working date - [ ] NO actual token values in the inventory (only metadata) - [ ] Verify all tokens have restrictive file permissions (600 or tighter) - [ ] Check that no tokens are committed to any git repo in plaintext - Run `git log --all -p | grep -i 'token\|secret\|password\|api_key'` on all repos - [ ] Create a script `scripts/token_audit.sh` that: - Scans common locations for exposed secrets - Checks file permissions on known credential files - Verifies each token still works (API ping) - Reports findings in a structured format - [ ] Document a rotation procedure for each token type - [ ] Set up a reminder (Gitea issue or cron) to rotate tokens every 90 days - [ ] Investigate using environment variables or a secrets file with restricted permissions instead of inline tokens ## Implementation Notes - Be VERY careful not to leak tokens in issue bodies, commit messages, or logs - Consider using `git-secrets` or similar tool to prevent future leaks - Profile.yaml and any config files should reference env vars, not raw tokens ## Definition of Done All tokens are inventoried, verified, properly permissioned, and a rotation schedule is in place.
bezalel self-assigned this 2026-04-04 16:02:15 +00:00
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bezalel/forge-log#10