insecure-defaults

Overview of insecure-defaults skill

What insecure-defaults does

The insecure-defaults skill helps you spot fail-open configuration patterns that let software run with unsafe settings instead of stopping. It is most useful for a Security Audit of production code, deployment configs, and secret-handling logic where missing environment variables should be treated as a defect, not silently tolerated.

Who should use it

Use the insecure-defaults skill if you review auth, crypto, API keys, or infrastructure code and need to separate safe fail-secure behavior from risky fallback behavior. It is a good fit for reviewers, AppSec teams, and agents checking whether a service can boot with weak credentials, permissive defaults, or placeholder secrets.

What makes it different

The skill is not a generic “find security bugs” prompt. It focuses on one decision: does missing config cause the system to fail closed, or does it continue insecurely? That narrow scope makes insecure-defaults useful for catching issues like default secrets, fallback passwords, and permissive environment-variable handling that are easy to miss in a broad audit.

How to Use insecure-defaults skill

Install and open the right files

For insecure-defaults install, add the skill with npx skills add trailofbits/skills --skill insecure-defaults. Then read SKILL.md first, followed by references/examples.md for the reported and non-reported patterns. If you are adapting the skill to another repo, also inspect any config, deployment, or secrets-related files where defaults could matter.

Give the skill a concrete audit target

The best insecure-defaults usage starts with a specific question, not a vague ask. Good inputs name the service, the config surface, and the risk boundary:

• “Review this auth service for insecure-defaults in env var handling and secret loading.”
• “Check Docker and IaC files for fallback credentials or permissive defaults.”
• “Audit these startup paths to confirm missing config fails secure, not open.”

Use the skill as a triage workflow

A practical insecure-defaults guide is: identify where config is read, check whether missing values crash or fallback, and confirm whether the default is safe in production. The repository examples show the key distinction: env['KEY'] or explicit validation is usually safe, while env.get('KEY') or 'default' is a reportable issue when the value controls security behavior.

Improve output quality with scoped context

Provide the exact files, stack, and deployment context the agent should examine. For example, mention src/auth/, config/, docker-compose.yml, or helm/ if those paths exist. Also state whether test fixtures, sample files, or development-only configs should be excluded; the skill explicitly treats those as non-findings unless they affect production behavior.

insecure-defaults skill FAQ

Is insecure-defaults only for app code?

No. The insecure-defaults skill also fits deployment manifests, IaC, container setup, and environment-variable logic. If a missing secret or password causes the app to run with a weak default, that is exactly the kind of issue it is built to catch.

How is this different from a normal prompt?

A normal prompt often produces broad security advice. The insecure-defaults skill is narrower and more decision-oriented: it checks whether a missing setting is a safe failure or a dangerous fallback. That focus reduces false positives and makes the review more consistent across codebases.

When should I not use it?

Do not use insecure-defaults for test fixtures, sample .example or .template files, documentation snippets, or development-only scripts unless they are actually used in production. It is also the wrong tool when the system is supposed to crash if config is absent; that fail-secure behavior is a pass, not a finding.

Is it beginner-friendly?

Yes, if you can identify where a system reads secrets or config. The insecure-defaults skill guide is easy to apply because it relies on a simple question: “What happens when the value is missing?” The nuance comes from knowing which files are real runtime inputs versus placeholders.

How to Improve insecure-defaults skill

Give stronger evidence at the prompt

The best way to improve insecure-defaults results is to include the exact security-sensitive variable or file path. For example, “Check whether SECRET_KEY, DB_PASSWORD, or JWT_SECRET has any fallback in production startup code” is much better than “find security problems.” Specific inputs help the skill focus on exploitable defaults instead of harmless convenience settings.

Separate production from non-production

A common failure mode is over-reporting defaults in local-only, test, or example files. Tell the skill which directories are deployable and which are not. If a fallback is intentional in dev but not allowed in prod, say so explicitly so the review can assess whether the boundary is enforced.

Ask for reasoning, not just findings

When you iterate, request the exact code path and why the default is dangerous. For instance: “Show whether the app still starts with a missing secret, and explain the impact if that secret signs sessions or tokens.” This makes insecure-defaults more useful for a Security Audit because it ties each finding to exploitability.

Refine after the first pass

If the first output is broad, rerun it with a narrower scope: one service, one configuration class, or one deployment manifest set. If you need higher precision, ask the skill to prioritize only fail-open cases that affect auth, cryptography, or access control, and to skip harmless defaults that do not change security posture.