insecure-defaults

insecure-defaults スキルの概要

insecure-defaults ができること

insecure-defaults スキルは、ソフトウェアが安全でない設定のまま動き続けてしまう fail-open の構成パターンを見つけるのに役立ちます。特に、実運用コード、デプロイ設定、シークレット取り扱いロジックの Security Audit で有効で、環境変数が不足している場合は黙って許容するのではなく、欠陥として扱うべき場面に向いています。

どんな人に向いているか

認証、暗号、API キー、インフラのコードをレビューしていて、安全に失敗する fail-secure の挙動と、危険なフォールバック挙動を切り分けたいなら insecure-defaults スキルを使ってください。レビュー担当者、AppSec チーム、そしてサービスが弱い認証情報、許容度の高いデフォルト値、プレースホルダのシークレットで起動できてしまうかを確認したいエージェントに適しています。

何が違うのか

このスキルは、単なる「セキュリティバグを見つける」ための汎用プロンプトではありません。見るポイントはただ一つ、設定が足りないときにシステムは安全側に倒れて止まるのか、それとも危険なまま動き続けるのか、です。この狭い焦点があるからこそ、insecure-defaults はデフォルトシークレット、フォールバックパスワード、環境変数の甘い扱いのような、大規模な監査では見落としやすい問題を拾いやすくなります。

insecure-defaults スキルの使い方

インストールして、正しいファイルを開く

insecure-defaults install では、npx skills add trailofbits/skills --skill insecure-defaults でスキルを追加します。最初に SKILL.md を読み、そのあとで報告対象パターンと非報告パターンが載っている references/examples.md を確認してください。別の repo に合わせて調整する場合は、デフォルト値が重要になりうる設定ファイル、デプロイ関連ファイル、シークレット関連ファイルもあわせて確認します。

スキルには具体的な監査対象を与える

insecure-defaults usage で最も精度が高いのは、曖昧な依頼ではなく、具体的な問いから始めるやり方です。よい入力には、対象サービス、設定の接点、リスクの境界が含まれます。

• “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.”

トリアージのワークフローとして使う

実践的な insecure-defaults guide は、どこで設定を読み込むかを特定し、値が足りないときにクラッシュするのかフォールバックするのかを確認し、デフォルト値が本番で安全かどうかを見極める、という流れです。repo の例が示している重要な違いは、env['KEY'] や明示的なバリデーションは通常安全である一方、env.get('KEY') or 'default' は、その値がセキュリティ挙動を左右するなら報告対象になりうる、という点です。

スコープを絞った文脈で出力品質を上げる

エージェントに見てほしい正確なファイル、スタック、デプロイ環境の情報を与えてください。たとえば、src/auth/、config/、docker-compose.yml、helm/ などのパスがあるなら明示します。また、テスト用フィクスチャ、サンプルファイル、開発専用設定を除外するかどうかも伝えてください。このスキルは、それらが本番動作に影響しない限り、原則として findings ではないものとして扱います。

insecure-defaults スキルの FAQ

insecure-defaults はアプリコード専用ですか？

いいえ。insecure-defaults スキルは、デプロイ用マニフェスト、IaC、コンテナ設定、環境変数ロジックにも適しています。シークレットやパスワードが不足したときにアプリが弱いデフォルトで動いてしまうなら、それこそがこのスキルが見つけるために作られた問題です。

通常のプロンプトと何が違いますか？

通常のプロンプトは、幅広いセキュリティ助言に流れがちです。insecure-defaults スキルはより狭く、判断軸も明確で、設定不足が安全な失敗なのか危険なフォールバックなのかを確認します。この焦点があることで false positive を減らし、コードベースが違ってもレビュー結果の一貫性を保ちやすくなります。

使わないほうがよいのはどんなときですか？

テスト用フィクスチャ、.example や .template のサンプルファイル、ドキュメントの断片、開発専用スクリプトには、実際に本番で使われている場合を除いて insecure-defaults を使わないでください。また、設定がなければシステムが落ちること自体が正しい設計なら、このスキルは不向きです。その fail-secure な挙動はパスであって、finding ではありません。

初心者でも使えますか？

はい。システムがどこでシークレットや設定を読み込むかを追えるなら使えます。insecure-defaults スキルのガイドは、「値がなかったらどうなるか？」という単純な問いに基づいているので、適用自体は難しくありません。重要なのは、どのファイルが実行時の実データで、どれがプレースホルダかを見分けることです。

insecure-defaults スキルの改善方法

プロンプトで根拠を強くする

insecure-defaults の結果を改善する最善策は、セキュリティ上重要な変数名やファイルパスを正確に入れることです。たとえば、“Check whether SECRET_KEY, DB_PASSWORD, or JWT_SECRET has any fallback in production startup code” は、“find security problems” よりずっと有効です。具体的な入力があれば、このスキルは無害な利便性設定ではなく、悪用可能なデフォルトに集中しやすくなります。

本番と非本番を分ける

よくある失敗は、ローカル専用、テスト用、サンプル用ファイルのデフォルトまで過剰に報告してしまうことです。どのディレクトリがデプロイ対象で、どれが対象外かをスキルに伝えてください。dev では意図的なフォールバックでも、prod では許可されないなら、その境界が強制されているかをレビューできるよう、明示しておく必要があります。

結果だけでなく、理由も求める

繰り返し確認するときは、どのコードパスなのか、なぜそのデフォルトが危険なのかまで求めてください。たとえば、“Show whether the app still starts with a missing secret, and explain the impact if that secret signs sessions or tokens.” のように依頼します。これにより、各 finding を悪用可能性と結びつけられるため、insecure-defaults は Security Audit でより実用的になります。

1回目の結果を踏まえて絞り込む

最初の出力が広すぎる場合は、対象をさらに狭めて再実行します。1つのサービス、1つの設定クラス、1組のデプロイマニフェストだけに絞ると精度が上がります。さらに高い精度が必要なら、認証、暗号、アクセス制御に影響する fail-open ケースだけを優先し、セキュリティ姿勢を変えない無害なデフォルトは除外するよう依頼してください。