This skill should be used when the user asks to "find hardcoded secrets", "audit for credential leaks", "check for API keys in code", "review secret scanning alerts", "rotate a leaked secret", or needs to detect hardcoded credentials, review secret handling patterns, or remediate exposed secrets.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
detecting-secrets
description
This skill should be used when the user asks to "find hardcoded secrets", "audit for credential leaks", "check for API keys in code", "review secret scanning alerts", "rotate a leaked secret", or needs to detect hardcoded credentials, review secret handling patterns, or remediate exposed secrets.
Secret Patterns
Look for these categories of hardcoded secrets in code:
High-Confidence Patterns
Type
Example Patterns
API Keys
AKIA[0-9A-Z]{16} (AWS), AIza[0-9A-Za-z_-]{35} (Google), strings assigned to variables named *apiKey*, *api_key*
Values assigned to variables named *password*, *passwd*, *secret*, *credential*
Certificates
PFX/P12 files with embedded passwords, PEM files with private keys
Lower-Confidence Patterns (Require Context)
Base64-encoded strings in configuration (may be encrypted or may be cleartext secrets)
JWT tokens (may be test tokens or production tokens)
Hex strings of 32+ characters (may be encryption keys or hashes)
URLs with embedded credentials (https://user:pass@host)
Context-Aware Detection
Distinguish real secrets from false positives. Not every pattern match indicates an actual secret — consider context:
Test Fixtures and Mock Data
// NOT a real secret — test fixture with obvious fake valuevar testApiKey = "test-api-key-not-real-12345";
var mockPassword = "P@ssword123"; // Used only in unit tests// REAL secret — production-looking value in non-test codevar apiKey = "sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx";
Decision criteria:
Is it in a test directory (**/test/**, **/tests/**, **/*.Test/**)?
Does the value contain obvious placeholder text ("test", "fake", "mock", "example", "placeholder")?
Is the value used in assertions or mock setups?
Example and Placeholder Values
// NOT a real secret — documented example{"apiKey":"YOUR_API_KEY_HERE"}// REAL secret — actual value in config{"apiKey":"sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx"}
Encrypted or Hashed Values
Hashed passwords (bcrypt $2b$, argon2 $argon2id$) are NOT secrets — they're properly stored
Encrypted values with proper key management are NOT secrets in the same way
But the encryption KEY itself, if hardcoded, IS a secret
Common Hiding Spots
Search these locations when auditing for secrets:
Location
What to Look For
appsettings.json / appsettings.Development.json
Connection strings, API keys, service credentials
.env / .env.local
Environment variable definitions with real values
web.config / app.config
Machine keys, connection strings
docker-compose.yml / Dockerfile
ENV directives with credentials, build args with secrets
CI/CD files (.github/workflows/*.yml)
Inline secrets instead of ${{ secrets.* }} references
Test seed scripts / migration files
Database passwords, service account credentials
Comments and TODO notes
"Temporary" credentials left in comments
Default parameter values
function connect(password = "admin123")
Constants files
Centralized credential definitions
GitHub Secret Scanning Integration
# List all secret scanning alerts
gh api /repos/{owner}/{repo}/secret-scanning/alerts --jq '.[] | {number, state, secret_type, secret_type_display_name, created_at, push_protection_bypassed}'# Get details for a specific alert
gh api /repos/{owner}/{repo}/secret-scanning/alerts/{alert_number}
# List alerts that bypassed push protection
gh api "/repos/{owner}/{repo}/secret-scanning/alerts?state=open" --jq '.[] | select(.push_protection_bypassed == true)'
Push protection prevents commits containing detected secrets from being pushed. When someone bypasses push protection, the alert is flagged — review these with extra scrutiny.
Remediation Workflow
When a secret is found in code, follow this sequence:
1. Rotate Immediately
Assume any committed secret is compromised. Even if the repo is private, the secret may have been cached, logged, or accessed by CI/CD systems.
Revoke the existing credential
Generate a new credential
Update the credential wherever it's used (services, deployments)
2. Remove from Code
Replace the hardcoded secret with a secure reference:
If the secret was committed to a public repo or a repo that will become public:
# Using git filter-repo (preferred over filter-branch)
git filter-repo --path-glob '*.json' --replace-text expressions.txt
# expressions.txt format:# literal:the-secret-value==>REDACTED
Warning: Rewriting git history is destructive and affects all collaborators. Only do this when the secret was exposed in a public or soon-to-be-public repository.
4. Prevent Recurrence
Add patterns to .gitignore for files that should never be committed (.env, *.pfx, appsettings.Development.json)
Enable GitHub push protection for the repository
Use secret scanning custom patterns for organization-specific secret formats
Secure Alternatives
Bitwarden uses Azure Key Vault for secrets management, provisioned by the BRE team:
Instead Of
Use
Hardcoded connection strings
Azure Key Vault secrets
API keys in config files
Environment variables set at deployment
Certificates in source
Azure Key Vault certificates
Shared team credentials in code
Managed identities (Azure)
Secrets in CI/CD workflow files
GitHub Actions secrets (${{ secrets.NAME }})
For local development, use user-secrets or .env files that are .gitignored — never commit them.
Critical Rules
Assume any committed secret is compromised. Always rotate, even if the repo is private. No exceptions.
Never suppress secret scanning alerts without rotation. Dismissing an alert doesn't make the exposure go away.
Validation, not just detection. When a potential secret is found, verify it's real before raising an alarm. Check if it's a test value, placeholder, or encrypted content.
Check the full commit history. A secret removed in the latest commit may still exist in git history. Use git log -p -S "secret-pattern" to search history.
Bitwarden uses Azure Key Vault for secrets management. If a new secret needs to be stored, work with BRE to provision vault access for the repository.
