insecure-defaults

Detects fail-open insecure defaults like hardcoded secrets and weak authentication in production code.

Updated Apr 5, 2026
One-click install
npx skills add https://github.com/marumo333/atrox --skill insecure-defaults-marumo333
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: insecure-defaults
Source: https://github.com/marumo333/atrox/tree/main/.claude/skills/trailofbits/plugins/insecure-defaults/skills/insecure-defaults
Command: npx skills add https://github.com/marumo333/atrox --skill insecure-defaults-marumo333

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Applications often ship with fail-open defaults—hardcoded secret fallbacks, disabled authentication, permissive CORS, or weak cryptography—that silently run insecurely in production when configuration is missing. This Skill finds those vulnerabilities and distinguishes them from safe fail-secure patterns. ## Core Features & Use Cases - Fail-Open Detection: Identifies fallback secrets, default credentials, disabled auth, weak crypto (MD5/SHA1/DES/ECB), permissive access, and debug features enabled by default. - Verification Workflow: Traces code paths to confirm runtime behavior and production impact before reporting, filtering out test fixtures and example files. - Evidence-Based Reporting: Produces findings with location, pattern, verification, production impact, and exploitation scenario. - Use Case: During a pre-deployment security audit, scan a Node.js codebase and discover const secret = process.env.JWT_SECRET || 'default' in the auth module, confirming the Dockerfile never sets JWT_SECRET—an attacker could forge tokens. ## Quick Start Audit this repository for insecure default configurations and report any fail-open vulnerabilities with evidence of production impact.

Frequently Asked Questions about insecure-defaults

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find hardcoded secrets in my codebase?▼

Search for fallback patterns like `os.environ.get('KEY', 'default')`, `process.env.X || 'value'`, or `ENV.fetch(..., default:)` in config, auth, and database directories. Then verify the app actually runs with the default when the environment variable is missing.

What is the difference between fail-open and fail-secure defaults?▼

Fail-open defaults let the app run insecurely when configuration is missing, such as `SECRET = env.get('KEY') or 'default'`. Fail-secure patterns like `env['KEY']` crash the app on startup, preventing insecure production operation.

Should test files with hardcoded credentials be reported as vulnerabilities?▼

No. Test fixtures explicitly scoped to test directories, example files, documentation samples, and development-only tools should be skipped. Only production-reachable code paths with insecure defaults qualify as findings.

Which weak cryptographic algorithms should be flagged in security audits?▼

Flag MD5, SHA1, DES, RC4, and ECB mode when used for passwords, encryption, or tokens. Skip them when used for non-security purposes like cache keys or checksums, and prefer bcrypt, Argon2, or AES-GCM instead.

When is a fallback secret not a critical vulnerability?▼

Severity is lower when production configuration verifiably provides the variable, though the code-level vulnerability remains. It becomes critical when production config is missing or relies on the default, allowing exploitation with known values.