Insecure Defaults Detection

Insecure Defaults Detection

Finds fail-open vulnerabilities where apps run insecurely with missing configuration. Distinguishes exploitable defaults from fail-secure patterns that crash safely.

• Fail-open (CRITICAL): SECRET = env.get('KEY') or 'default' → App runs with weak secret
• Fail-secure (SAFE): SECRET = env['KEY'] → App crashes if missing

When to Use

• Security audits of production applications (auth, crypto, API security)
• Configuration review of deployment files, IaC templates, Docker configs
• Code review of environment variable handling and secrets management
• Pre-deployment checks for hardcoded credentials or weak defaults

When NOT to Use

Do not use this skill for:

• Test fixtures explicitly scoped to test environments (files in test/, spec/, __tests__/)
• Example/template files (.example, .template, .sample suffixes)
• Development-only tools (local Docker Compose for dev, debug scripts)
• Documentation examples in README.md or docs/ directories
• Build-time configuration that gets replaced during deployment
• Crash-on-missing behavior where app won't start without proper config (fail-secure)

When in doubt: trace the code path to determine if the app runs with the default or crashes.

Rationalizations to Reject

• "It's just a development default" → If it reaches production code, it's a finding
• "The production config overrides it" → Verify prod config exists; code-level vulnerability remains if not
• "This would never run without proper config" → Prove it with code trace; many apps fail silently
• "It's behind authentication" → Defense in depth; compromised session still exploits weak defaults
• "We'll fix it before release" → Document now; "later" rarely comes

Workflow

Follow this workflow for every potential finding:

1. SEARCH: Perform Project Discovery and Find Insecure Defaults