
Env Secrets Manager
Detect hardcoded API keys and tokens, classify severity, and validate required env vars before deploy so solo builders do not ship leaked credentials.
Overview
env-secrets-manager is an agent skill most often used in Ship (also Build integrations and Operate infra) that detects credential exposure patterns and enforces env validation baselines.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill env-secrets-managerWhat is this skill?
- Secret detection tiers: Critical (OpenAI-style sk-, GitHub ghp_, AWS AKIA), High (Slack xox-, PEM, hardcoded secret assi
- Five-step response playbook: rotate, assess blast radius, scrub history, add hooks/CI scans, verify logs
- Preventive baseline: .env.example only, gitignore patterns, secret managers for staging/prod, log redaction
- Startup/CI validate-env.sh pattern with ALWAYS_REQUIRED vars and fail-fast missing checks
- Severity guidance maps critical/high/medium to rotation and investigation actions
- 3 detection severity tiers: Critical, High, Medium
- 5-step response playbook for exposed credentials
- validate-env.sh pattern with ALWAYS_REQUIRED variable list and fail-fast exit
Adoption & trust: 544 installs on skills.sh; 17.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are unsure whether keys, tokens, or .env files in your repo are safe to ship, and production boots without guaranteed required variables.
Who is it for?
Solo builders prepping SaaS or API repos for CI/CD who need agent-guided secret hygiene without skipping rotation steps.
Skip if: Organizations that already run enterprise vaults and mandatory SAST with signed policies—the skill complements but does not replace those platforms.
When should I use this skill?
Adding env files, integrating third-party APIs, preparing deploy/CI, or responding to suspected credential exposure in the repo.
What do I get? / Deliverables
You get classified findings, a rotation-oriented response plan, gitignore and example-file conventions, and a validate-env script outline before deploy.
- Severity-classified secret findings and rotation checklist
- validate-env.sh or equivalent startup guard script
- Updated .env.example, gitignore, and redaction guidance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Secret hygiene is canonically Ship/security, but the same patterns matter whenever you commit code or promote builds—hence multi-phase with security as the primary shelf. Security subphase covers pre-release scanning, rotation playbooks, and env baselines—the skill’s detection categories and validate-env.sh target that gate.
Where it fits
Before wiring Stripe or OpenAI, the agent flags hardcoded api_key assignments and proposes .env.example entries only.
Pre-release pass classifies a ghp_ token as critical and walks through revoke, history scrub, and CI secret scan hooks.
After a staging leak, you rerun the five-step playbook and confirm logs no longer print DATABASE_URL.
How it compares
Checker-style procedural playbook versus installing a full hosted secret scanner or vault product.
Common Questions / FAQ
Who is env-secrets-manager for?
Indie developers and small teams shipping with agents who manage .env files, API keys, and deploy pipelines and want structured leak detection and validation steps.
When should I use env-secrets-manager?
In Ship (security) before release to scan for exposed tokens; in Build when adding integrations; in Operate when rotating credentials after an incident or auditing env setup.
Is env-secrets-manager safe to install?
The skill may instruct reading repo files for secrets; review the Security Audits panel on this page and avoid pasting live credentials into chat while following its playbooks.
SKILL.md
READMESKILL.md - Env Secrets Manager
# Secret Pattern Reference ## Detection Categories ### Critical - OpenAI-like keys (`sk-...`) - GitHub personal access tokens (`ghp_...`) - AWS access key IDs (`AKIA...`) ### High - Slack tokens (`xox...`) - Private key PEM blocks - Hardcoded assignments to `secret`, `token`, `password`, `api_key` ### Medium - JWT-like tokens in plaintext - Suspected credentials in docs/scripts that should be redacted ## Severity Guidance - `critical`: immediate rotation required; treat as active incident - `high`: likely sensitive; investigate and rotate if real credential - `medium`: possible exposure; verify context and sanitize where needed ## Response Playbook 1. Revoke or rotate exposed credential. 2. Identify blast radius (services, environments, users). 3. Remove from code/history where possible. 4. Add preventive controls (pre-commit hooks, CI secret scans). 5. Verify monitoring and access logs for abuse. ## Preventive Baseline - Commit only `.env.example`, never `.env`. - Keep `.gitignore` patterns for env and key material. - Use secret managers for staging/prod. - Redact sensitive values from logs and debug output. # env-secrets-manager reference ## Required Variable Validation Script ```bash #!/bin/bash # scripts/validate-env.sh # Run at app startup or in CI before deploy # Exit 1 if any required var is missing or empty set -euo pipefail MISSING=() WARNINGS=() # --- Define required vars by environment --- ALWAYS_REQUIRED=( APP_SECRET APP_URL DATABASE_URL AUTH_JWT_SECRET AUTH_REFRESH_SECRET ) PROD_REQUIRED=( STRIPE_SECRET_KEY STRIPE_WEBHOOK_SECRET SENTRY_DSN ) # --- Check always-required vars --- for var in "${ALWAYS_REQUIRED[@]}"; do if [ -z "${!var:-}" ]; then MISSING+=("$var") fi done # --- Check prod-only vars --- if [ "${APP_ENV:-}" = "production" ] || [ "${NODE_ENV:-}" = "production" ]; then for var in "${PROD_REQUIRED[@]}"; do if [ -z "${!var:-}" ]; then MISSING+=("$var (required in production)") fi done fi # --- Validate format/length constraints --- if [ -n "${AUTH_JWT_SECRET:-}" ] && [ ${#AUTH_JWT_SECRET} -lt 32 ]; then WARNINGS+=("AUTH_JWT_SECRET is shorter than 32 chars — insecure") fi if [ -n "${DATABASE_URL:-}" ]; then if ! echo "$DATABASE_URL" | grep -qE "^(postgres|postgresql|mysql|mongodb|redis)://"; then WARNINGS+=("DATABASE_URL doesn't look like a valid connection string") fi fi if [ -n "${APP_PORT:-}" ]; then if ! [[ "$APP_PORT" =~ ^[0-9]+$ ]] || [ "$APP_PORT" -lt 1 ] || [ "$APP_PORT" -gt 65535 ]; then WARNINGS+=("APP_PORT=$APP_PORT is not a valid port number") fi fi # --- Report --- if [ ${#WARNINGS[@]} -gt 0 ]; then echo "WARNINGS:" for w in "${WARNINGS[@]}"; do echo " ⚠️ $w" done fi if [ ${#MISSING[@]} -gt 0 ]; then echo "" echo "FATAL: Missing required environment variables:" for var in "${MISSING[@]}"; do echo " ❌ $var" done echo "" echo "Copy .env.example to .env and fill in missing values." exit 1 fi echo "✅ All required environment variables are set" ``` Node.js equivalent: ```typescript // src/config/validateEnv.ts const required = [ 'APP_SECRET', 'APP_URL', 'DATABASE_URL', 'AUTH_JWT_SECRET', 'AUTH_REFRESH_SECRET', ] const missing = required.filter(key => !process.env[key]) if (missing.length > 0) { console.error('FATAL: Missing required environment variables:', missing) process.exit(1) } if (process.env.AUTH_JWT_SECRET && process.env.AUTH_JWT_SECRET.length < 32) { console.error('FATAL: AUTH_JWT_SECRET must be at least 32 characters') process.exit(1) } export const config = { appSecret: process.env.APP_SECRET!, appUrl: process.env.APP_URL!, databaseUrl: process.env.DATABASE_URL!, jwtSecret: process.env.AUTH_JWT_SECRET!, refreshSecret: process.env.AUTH_REFRESH_SECRET!, stripeKey: process.env.STRIPE_SECRET_KEY, // optional port: parseInt(process.env.APP_PORT ?? '3000', 10), } as const ``` --- ## Secret Leak Detection ### Scan Working Tree ```bash #!/bi