robcsaszar/sentinel

セキュリティ監査スキル

ウェブアプリケーションのコードベースに対して厳格な静的セキュリティ監査を実行します。PASS / FAIL / MANUAL-REVIEW のサマリーテーブルと、ファイル:行のエビデンス、リスク説明、修正コードを含む所見ブロックを生成します。

---

フェーズ1 — スタックトリアージ

コードをスキャンする前に、package.json、設定ファイル、README を読んで以下の質問に答えてください：

1. フレームワーク： SvelteKit / Next.js / Express / FastAPI など
2. データベースドライバー： パラメータ化クエリ（libsql、pg、prisma） vs 生文字列（低レベルドライバー）
3. 認証メカニズム： JWT / HMAC トークン / セッション / OAuth
4. デプロイ先： Fly.io / Cloudflare / Vercel / ベアNode — レート制限と監査ログのための信頼するIPヘッダーを決定します（Fly-Client-IP vs CF-Connecting-IP vs X-Forwarded-For）；間違ったものを信頼すると、攻撃者が送信元IPを偽装できるようになります
5. ファイルアップロード： あり/なし — ありの場合、保存場所（ローカルFS、S3互換、CDN）
6. 外部アウトバウンドコール： メールAPI、webhook、メディアフェッチ — 潜在的なSSRF攻撃面

フェーズ2の前に、スタックのサマリーを1段落で記述してください。ここでの誤った前提は、誤った所見を生み出します。

---

フェーズ2 — スキャン

必須読み物： references/security-checklist.md

単一エンドポイントのレビューに対しては references/security-checklist.md を読み込まないでください — タスクの範囲を超えて拡大します。コードベース全体の監査の場合のみ読み込んでください。

チェックリストのすべてのカテゴリを順番に処理してください — グループをスキップする場合は、レポートに理由を明記する必要があります。

各カテゴリについて：

• 該当するソースファイルを読んでください。記憶からPASSと判断しないでください。
• ファイルが存在しない場合は、MANUAL-REVIEWとマークし、メモを添えてください。
• 判定（PASS / FAIL / MANUAL-REVIEW）と1行のエビデンスメモを記録してください。

リポジトリが大きすぎてすべてのファイルを読めない場合は、リスクの高いものから優先してください：認証フローとトークン処理を最初に、次に入出力境界、その後依存関係設定です。スキップしたファイルはメモしておいてください。

---

フェーズ3 — 分類

生のスキャンノートを見直してください。各項目に対して、判定ルールを適用します：

• PASS — 該当するコードを読み、コントロールが適切に実装されていることを確認しました。ファイル:行を引用します。
• FAIL — 確認された悪用可能なギャップを発見しました。スニペットがあります。修正を記述できます。
• MANUAL-REVIEW — 判定には実行時コンテキスト、インフラストラクチャへのアクセス、または人間の判断が必要です（例：「このトークンがTursoダッシュボードで読み取り専用スコープであることを確認する」）。

判定を割り当てる前に、自問してください：「読んだ情報だけで、今すぐ修正コードを書けるか？」 はい → FAIL。 いいえ → MANUAL-REVIEW。

レポートを和らげるためにFAILをMANUAL-REVIEWに格下げしないでください。

---

フェーズ4 — レポート

最初にサマリーテーブル：

#	カテゴリ	ステータス	メモ
1	SQLインジェクション	PASS	全体でパラメータ化済み
2	XSS	FAIL	ユーザー制御フィールドに {@html} 使用 — 所見を参照
…	…	…	…

次に、FAILおよびMANUAL-REVIEWのすべてに対して、所見ブロック：

### [N]. CATEGORY — FAIL
**ファイル：** `src/lib/example.ts:42`
**スニペット：**
  cookies.set(name, token, { httpOnly: true })   // ← Secureフラグ欠落
**リスク：** 本番環境以外でCookieが平文HTTP経由で送信されます；受動的MITMによって取得される可能性があります。
**修正：**
  cookies.set(name, token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === "production",
    sameSite: "lax",
  });

MANUAL-REVIEWブロックは同じ形式ですが、修正 の代わりに アクション を使用し、人間が確認すべき内容と場所を説明します。

PASSアイテムはサマリーテーブルにのみ表示されます — ブロックは不要です。

---

絶対にやってはいけないこと

• 絶対にファイルを読まずにPASSと判断しないこと 代わりに： ファイルを読み、エビデンスメモにファイル:行を引用してください。 理由： 記憶ベースのPASS判断は誤った安心感を生みます — 監査の本質はエビデンスです。

• 絶対にコードスニペットなしでFAILと判断しないこと 代わりに： 脆弱な行を正確に引用してください。スニペットが見つからない場合は、MANUAL-REVIEWとします。 理由： エビデンスのないFAILはノイズです；開発者が修正するには正確な場所が必要です。

• 絶対にFAILとMANUAL-REVIEWを混同しないこと 代わりに： FAIL = 今すぐ修正コードを書ける；MANUAL-REVIEW = 書けない、その理由を述べる。 理由： 混同するとレポートの実用性が損なわれます。

• 絶対にフェーズ1のスタックトリアージをスキップしないこと 代わりに： スキャン前に package.json と1つの設定ファイルを読んでください。 理由： 信頼するIPヘッダー、有効なCSPアプローチ、適用される認証モデルはすべてスタックに依存します — 誤った前提は誤った判定につながります。

• 絶対にプロジェクトのフレームワーク/ライブラリに一致しない修正コードを報告しないこと 代わりに： 既に使用されているAPI（例：SvelteKitの cookies.set、res.setHeader ではない）を使って修正を記述してください。 理由： コンパイルできない汎用的な修正は無視されます；フレームワーク特有の修正はマージされます。

• 絶対にソースファイルを読んでいないカテゴリの所見ブロックを書かないこと 代わりに： ファイルを開き、読み、それからブロックを書いてください。 理由： ファイルのエビデンスがない所見ブロックは主張であって監査ではありません — 間違っていることが判明した場合、レポート全体の信頼性を損なうことになります。

• 絶対に大規模リポジトリでファイルを黙ってスキップしないこと 代わりに： リスクの高いものから優先し（認証/トークン処理 → 入出力境界 → 依存関係設定）、スキップしたすべてのファイルをレポートに明示的にリストしてください。 理由： 黙ったスキップは監査のカバレッジ主張を検証不可能にします — 不完全なスキャンでのクリーンレポートは誤った全クリアとして読まれます。