insecure-defaultsDetects fail-open insecure defaults (hardcoded secrets, weak auth, permissive security) that allow apps to run insecurely in production. Use when auditing security, reviewing config management, or analyzing environment variable handling.
Install via ClawdBot CLI:
clawdbot install atlas-secint/insecure-defaultsFinds fail-open vulnerabilities where apps run insecurely with missing configuration. Distinguishes exploitable defaults from fail-secure patterns that crash safely.
SECRET = env.get('KEY') or 'default' ā App runs with weak secretSECRET = env['KEY'] ā App crashes if missingDo not use this skill for:
test/, spec/, tests/).example, .template, .sample suffixes)When in doubt: trace the code path to determine if the app runs with the default or crashes.
Follow this workflow for every potential finding:
Determine language, framework, and project conventions. Use this information to further discover things like secret storage locations, secret usage patterns, credentialed third-party integrations, cryptography, and any other relevant configuration. Further use information to analyze insecure default configurations.
Example
Search for patterns in /config/, /auth/, **/database/, and env files:
getenv.\) or ['"], process\.env\.[A-Z_]+ \|\| ['"], ENV\.fetch.default:password.=.['"][^'"]{8,}['"], api[_-]?key.=.['"][^'"]+['"]DEBUG.=.true, AUTH.=.false, CORS.=.\*MD5|SHA1|DES|RC4|ECB in security contextsTailor search approach based on discovery results.
Focus on production-reachable code, not test fixtures or example files.
For each match, trace the code path to understand runtime behavior.
Questions to answer:
Determine if this issue reaches production:
If production config provides the variable ā Lower severity (but still a code-level vulnerability)
If production config missing or uses default ā CRITICAL
Example report:
Finding: Hardcoded JWT Secret Fallback
Location: src/auth/jwt.ts:15
Pattern: const secret = process.env.JWT_SECRET || 'default';
Verification: App starts without JWT_SECRET; secret used in jwt.sign() at line 42
Production Impact: Dockerfile missing JWT_SECRET
Exploitation: Attacker forges JWTs using 'default', gains unauthorized accessFallback Secrets: SECRET = env.get(X) or Y
ā Verify: App starts without env var? Secret used in crypto/auth?
ā Skip: Test fixtures, example files
Default Credentials: Hardcoded username/password pairs
ā Verify: Active in deployed config? No runtime override?
ā Skip: Disabled accounts, documentation examples
Fail-Open Security: AUTH_REQUIRED = env.get(X, 'false')
ā Verify: Default is insecure (false/disabled/permissive)?
ā Safe: App crashes or default is secure (true/enabled/restricted)
Weak Crypto: MD5/SHA1/DES/RC4/ECB in security contexts
ā Verify: Used for passwords, encryption, or tokens?
ā Skip: Checksums, non-security hashing
Permissive Access: CORS *, permissions 0777, public-by-default
ā Verify: Default allows unauthorized access?
ā Skip: Explicitly configured permissiveness with justification
Debug Features: Stack traces, introspection, verbose errors
ā Verify: Enabled by default? Exposed in responses?
ā Skip: Logging-only, not user-facing
For detailed examples and counter-examples, see examples.md.
Generated Mar 1, 2026
Auditing a microservices-based SaaS application for insecure defaults in environment variable handling and configuration files. This scenario involves reviewing Dockerfiles, Kubernetes manifests, and application code to detect hardcoded secrets or weak authentication fallbacks that could be exploited if production configurations are missing.
Conducting a security assessment for a banking or fintech application to ensure compliance with regulations like PCI-DSS or GDPR. The skill helps identify fail-open vulnerabilities in authentication mechanisms, cryptographic implementations, and API security defaults that could lead to data breaches or unauthorized access.
Reviewing a healthcare app's configuration management before deployment to production environments. This scenario focuses on detecting insecure defaults in environment variables for patient data encryption, API keys for third-party integrations, and debug settings that might expose sensitive health information if left enabled.
Performing a pre-deployment security scan on an e-commerce platform to find weak defaults in payment processing modules, user authentication flows, and CORS settings. The goal is to prevent vulnerabilities like hardcoded API keys or permissive access controls that could be exploited during high-traffic sales events.
Offering specialized audits and penetration testing services to clients, using this skill to identify and report insecure defaults in their applications. Revenue is generated through project-based fees or retainer contracts for ongoing security reviews.
Integrating this skill into CI/CD pipelines as part of a DevSecOps platform, providing automated security scanning for development teams. Revenue comes from subscription-based SaaS pricing or enterprise licensing for the tool.
Assisting organizations in achieving security certifications (e.g., ISO 27001, SOC 2) by using the skill to detect and remediate insecure defaults as part of compliance audits. Revenue is generated through consulting packages and certification preparation services.
š¬ Integration Tip
Integrate this skill into CI/CD pipelines by adding automated scans during build or deployment stages to catch insecure defaults early, and ensure it excludes test and example files as specified to reduce false positives.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
Security-first skill vetting for AI agents. Use before installing any skill from ClawdHub, GitHub, or other sources. Checks for red flags, permission scope, and suspicious patterns.
Perform a comprehensive read-only security audit of Clawdbot's own configuration. This is a knowledge-based skill that teaches Clawdbot to identify hardening opportunities across the system. Use when user asks to "run security check", "audit clawdbot", "check security hardening", or "what vulnerabilities does my Clawdbot have". This skill uses Clawdbot's internal capabilities and file system access to inspect configuration, detect misconfigurations, and recommend remediations. It is designed to be extensible - new checks can be added by updating this skill's knowledge.
Use when reviewing code for security vulnerabilities, implementing authentication flows, auditing OWASP Top 10, configuring CORS/CSP headers, handling secrets, input validation, SQL injection prevention, XSS protection, or any security-related code review.
Security check for ClawHub skills powered by Koi. Query the Clawdex API before installing any skill to verify it's safe.
Scan Clawdbot and MCP skills for malware, spyware, crypto-miners, and malicious code patterns before you install them. Security audit tool that detects data exfiltration, system modification attempts, backdoors, and obfuscation techniques.