security-audit

セキュリティ監査 - モジュール式実行計画

この計画では、フレームワークに依存しない包括的なセキュリティ監査を、 順次実行するモジュール式ルールによって行います。各ステップでは、 個別に実行できる特定のルールを使用し、その出力を最終レポートに反映します。

エージェントの役割とコンテキスト

役割：セキュリティ監査担当者

中核となる専門知識

次の分野に精通しています。

• フレームワークに依存しないセキュリティ監査：実行時にプロジェクトの種類を検出し、 それに応じてセキュリティチェックを適応させる
• 機密ファイルの検出：あらゆる種類のプロジェクトから、公開された認証情報、API キー、 シークレット、機密ファイルを特定する
• ソースコード内のシークレットスキャン：ソースコード内のハードコードされたシークレット、認証情報、 危険なパターンを検出する
• 依存関係の脆弱性分析：パッケージマネージャー標準の脆弱性スキャン （npm audit、pub outdated、pip audit など）を実行する
• 依存関係の経過期間分析：各エコシステムで古くなった依存関係や非推奨の依存関係を特定する
• 定量的なセキュリティスコアリング：重み付けルーブリック（5 つのセクション、加重式）を使用して セクションごとのスコアを算出し、セキュリティ態勢のラベル（Strong/Fair/Weak/Critical）に対応付ける
• エビデンスに基づくレポート作成：ファイルパス、行番号、重大度分類、定量的スコアを含む、 実行可能なセキュリティレポートを作成する

責務：

• 分析を実行する前に、プロジェクトの種類を自動的に検出する
• 検出されたテクノロジーに合わせてセキュリティチェックを実行する
• リポジトリ内で見つかったエビデンスに基づき、客観的に検出結果を報告する
• 必須ステップが失敗した場合は、直ちに実行を停止する
• 情報を決して捏造したり推測したりせず、エビデンスが見つからない場合は「見つかりません」と報告する

期待される動作：

• プロフェッショナルでエビデンスに基づく：すべての検出結果は、 実際のリポジトリ内のエビデンスによって裏付けられている必要があります
• 客観的な報告：重大度の高い検出結果、中程度の検出結果、低い検出結果を明確に区別する
• 明示的な記録：確認した内容、見つかった内容、不足している内容を記録する
• エラー処理：必須ステップが失敗した場合は実行を停止し、重要度の低い問題については 警告を出して続行する
• 推測しない：リポジトリ内のエビデンスで証明できないことは、「見つかりません」と記載し、 何があれば証明できるかを明示する

重要なルール：

• CODEOWNERS ファイルや SECURITY.md ファイルを決して推奨しない。これらはガバナンス上の 判断であり、技術的な要件ではありません
• 運用ドキュメント（ランブック、デプロイ手順、監視など）を決して推奨しないでください。 技術的なセキュリティのみに焦点を当てます

プロジェクトの検出（最初に実行）

分析の前に、プロジェクトの種類を検出します。

• pubspec.yaml が存在する -> Flutter/Dart プロジェクト（*.dart をスキャンし、 android/.gitignore などを確認）
• package.json に @nestjs/core が含まれる -> NestJS プロジェクト（*.ts をスキャンし、 認証ガード、OWASP などを確認）
• package.json に @nestjs/core が含まれない -> Node.js プロジェクト（*.ts/*.js をスキャン）
• go.mod -> Go プロジェクト
• Cargo.toml -> Rust プロジェクト
• pyproject.toml または requirements.txt -> Python プロジェクト
• build.gradle または build.gradle.kts -> Java/Kotlin Gradle プロジェクト
• pom.xml -> Java/Kotlin Maven プロジェクト
• Package.swift -> Swift SPM プロジェクト
• Podfile -> Swift/ObjC CocoaPods プロジェクト
• *.sln または *.csproj -> .NET プロジェクト
• 該当なし -> 汎用プロジェクト（一般的なパターンをスキャン）

プロジェクト検出の優先順位（複数のマニフェストが存在する場合）：

1. pubspec.yaml、2. package.json、3. go.mod、4. Cargo.toml、5. pyproject.toml、
2. build.gradle/build.gradle.kts、7. pom.xml、8. Package.swift、9. Podfile、
3. .sln/.csproj。最初に一致したものだけを監査します。複数のスタックを含む モノレポの場合は、サブディレクトリから監査を実行するか、マルチテクノロジー検出（有効な場合）を 使用してください。

ステップ 1. ツールの検出とセットアップ

目標：プロジェクトの種類を検出し、セキュリティツールチェーンを設定します。

references/tool-installer.md の指示を読み、従ってください。

統合：以降のステップで使用するため、ツールの検出結果を保存します。

ステップ 2. 機密ファイルの分析

目的：機密ファイルを特定し、プロジェクト内のすべてのディレクトリで .gitignore の適用状況を確認し、設定ファイルの露出を検出します。

references/file-analysis.md の指示を読み、それに従ってください。

統合：セキュリティレポート用に、ファイル分析の調査結果を保存します。

ステップ 3. ソースコードのシークレットスキャン

目的：ソースコードを検索し、危険なシークレットのパターン、ハードコードされた認証情報、API キー、トークンを検出します。

references/secret-patterns.md の指示を読み、それに従ってください。

統合：セキュリティレポート用に、シークレットスキャンの調査結果を保存します。

ステップ 4. Gitleaks スキャン（任意）

目的：Gitleaks を使用して、作業ディレクトリと Git の履歴に含まれるシークレットをリポジトリ全体からスキャンします。

references/gitleaks.md の指示を読み、それに従ってください。

統合：シークレット検出セクション用に、Gitleaks の調査結果を保存します。Gitleaks がインストールされていない場合は、レポートにインストールの推奨事項を追加します。step_04 で GIT_HISTORY_FINDINGS > 0 が見つかった場合、レポート生成ツールは「Git の履歴内のシークレット：-15」を適用します。

ステップ 5. 依存関係の脆弱性監査

目的：パッケージマネージャー標準の脆弱性スキャンを実行し、古い依存関係や脆弱な依存関係を特定します。

references/dependency-audit.md の指示を読み、それに従ってください。

統合：セキュリティレポート用に、依存関係監査の調査結果を保存します。

ステップ 6. 依存関係の経過年数監査

目的：プロジェクト全体で、古くなった依存関係や非推奨の依存関係を特定します。

references/dependency-age.md の指示を読み、それに従ってください。

統合：レポートの依存関係セキュリティセクション用に、依存関係の経過年数に関する調査結果を保存します。レポート生成ツールは step_06 の成果物から、古くなった依存関係と非推奨の依存関係の件数および一覧を取得します。

ステップ 7. Trivy 脆弱性スキャン（任意）

目的：Trivy のファイルシステムスキャンを実行し、依存関係と設定に含まれる既知の脆弱性を検出します。Trivy がインストールされていない場合は、問題なくスキップします。

references/trivy.md の指示を読み、それに従ってください。

統合：セキュリティレポート用に、Trivy スキャンの調査結果を保存します。Trivy がインストールされていない場合は、レポートにインストールの推奨事項を追加します。

ステップ 8. SAST 分析

目的：検出されたプロジェクトの種類に応じて、OWASP の脆弱性パターン（SQL インジェクション、XSS、パストラバーサル、eval／コードインジェクション）を対象とした基本的な SAST 形式の grep を実行します。また、Firebase Auth が検出された場合は、Firebase Auth の不正利用チェック（App Check の適用と SMS の地域ポリシーを確認し、利用可能な場合は gcloud ベースのライブ検証を含む）を実行します。調査結果は、LOW／MEDIUM の重大度として統合された調査結果に反映されます。

references/sast.md の指示を読み、それに従ってください。

統合：セキュリティレポートの統合された調査結果用に、SAST の調査結果を保存します。調査結果は、メインセクションのスコアには影響しません。

ステップ 9. セキュリティレポートを生成する

目標：すべての調査結果を総合し、定量的なスコア、重大度分類、実行可能な推奨事項を含む包括的なセキュリティ監査レポートを作成します。

references/report-generator.md の指示を読み、従ってください。

統合：このルールでは、これまでの分析結果をすべて統合し、最終的なセキュリティレポートを生成します。レポートの内容を書く前に、採点基準を使って5つすべてのセクションスコアを必ず算出してください。スコアが算出されていないレポートは無効です。

レポートのセクション（定量スコアを含む12セクション）：

• セキュリティスコアの内訳（| Area | Score | テーブル：5つの領域の行＋Overall Scoreの行、その後にPosture）
• Overall Scoreを含むエグゼクティブサマリー
• スコア付き詳細セクション（5セクション。スコアの昇順で動的に並べ替え、最も低いものを先頭にする）：
  • 機密ファイルの保護（スコア付き、重み25%）
  • シークレットの検出（スコア付き、重み30%）
  • 依存関係のセキュリティ（スコア付き、重み20%）
  • サプライチェーンの完全性（スコア付き、重み10%）
  • セキュリティ自動化とCI/CD（スコア付き、重み15%）
• 重大度別の統合された調査結果（HIGH、MEDIUM、LOW）
• 修復優先度マトリクス
• プロジェクト検出結果
• 付録：エビデンス索引
• 付録：採点方法（番号なし。重みと計算式を記載し、Report Metadataの前に配置）
• Report Metadata

採点要件：スコア付きの各セクションには、必ず次の内容を含めてください。[Score]/100 ([Label]) 形式のスコア行、スコアの内訳（基本点、減点・加点、最終スコア）、主な調査結果、エビデンス、リスク、推奨事項。

ステップ 10. セキュリティレポートを検証してエクスポートする

目標：生成したレポートを構造とMarkdown形式のルールに照らして検証し、最終版のMarkdownレポートを保存します。

references/report-format-enforcer.md の指示を読み、従ってください。

検証：生成したレポートを読み、フォーマット強制ルールの構造チェックをすべて検証してください。セクションが正確に12個あること、セクション1が5つの領域の行＋Overall Scoreの行＋Postureを含む| Area | Score |テーブルであること（重みと計算式は番号なしの採点方法の付録に記載）、セクション3～7にスコア行があること、セクションがスコアの昇順に並んでいること、スコアラベルが範囲に一致していること、Markdown構文が適切であることを確認してください。問題があれば、その場で修正してください。スコアがまったく記載されていない場合は、エクスポート前にステップ10を再実行してください。

エクスポート：検証済みのレポートを./reports/<YYYY-MM-DD>-<project>-security-audit.mdに保存します。

形式：Markdown形式のレポート（適切なMarkdown構文を使用し、#見出し、太字のマーカー、バッククォートによるコード参照を使用）。

コマンド：

mkdir -p reports
# Save validated report to ./reports/<YYYY-MM-DD>-<project>-security-audit.md

実行の概要

ルールの合計：分析ルール 10 件＋形式適用ルール 1 件

ルールの実行順序：

1. references/tool-installer.md の指示を読み、従ってください（必須 — ツールの検出）{model: cheap}
2. references/file-analysis.md の指示を読み、従ってください {model: cheap}
3. references/secret-patterns.md の指示を読み、従ってください {model: cheap}
4. references/gitleaks.md の指示を読み、従ってください（任意 — Gitleaks がインストールされていない場合はスキップ）{model: cheap}
5. references/dependency-audit.md の指示を読み、従ってください {model: mid}
6. references/dependency-age.md の指示を読み、従ってください {model: mid}
7. references/trivy.md の指示を読み、従ってください（任意 — Trivy がインストールされていない場合はスキップ）{model: mid}
8. references/sast.md の指示を読み、従ってください（SAST OWASP パターン、LOW/MEDIUM の検出結果）{model: cheap}
9. references/report-generator.md の指示を読み、従ってください（定量的なスコアリングを含む 12 セクションのレポートを生成）{model: frontier}

生成後：references/report-format-enforcer.md の指示を読み、従ってレポートを検証・修正してください（ステップ 9 の後に自動実行）{model: frontier}

スコアリングシステム：

• 重み付け評価基準を用いて 5 つのセクションを採点（各 0～100 点）
• 加重計算式で総合スコアを算出
• 総合スコアに基づきセキュリティ態勢を判定：Strong（85～100）、Fair（70～84）、 Weak（50～69）、Critical（0～49）
• セキュリティスコアの内訳により、CTO が状況をすぐに把握できます
• 採点対象のセクションは、スコアの低い順（最も弱い領域が先）に並べます

モジュール方式のメリット：

• 各ルールを個別に実行できます
• 実行時のプロジェクト検出により、フレームワークに依存しません
• 出力を保存して再利用できます
• 責務が明確に分離されています
• 定量的なスコアリングにより、監査間の客観的な比較が可能です
• 単独で、またはヘルス監査の後に実行できます

サブエージェントのディスパッチ（セッション内）

このセクションでは、Claude Code が 1 つのセッション内で Agent ツールを使ってサブエージェントをディスパッチする場合のセッション内パスについて説明します。上記のルール実行順序は CLI パス（somnio run）であり、ステップを順番に実行します。どちらのパスでも同じレポートが生成されますが、ステップのスケジュール方法と、各ステップの実行に使用するモデルのティアが異なります。

エントリポイント：agents/orchestrator.md（モデル：mid）

オーケストレーターは、この SKILL.md を読み込んで対象範囲を把握した後、依存関係の順序に従って分析サブエージェントを複数のウェーブに振り分けます。次のウェーブに進む前に、各成果物が存在するかを検証します。成果物がない場合は 1 回再試行し、その後、不足分を記録してレポート作成者に引き継ぎ、却下基準に従って処理させます。

ウェーブ計画

ウェーブ	モード	ディスパッチするエージェント	ティア
ウェーブ 0	順次（失敗時に停止）	tool-installer	cheap
ウェーブ 1	並列	file-analyzer、secret-scanner、sast-analyzer	cheap
ウェーブ 2	順次	dependency-analyzer	mid
ウェーブ 3	順次	report-writer	frontier

ディスパッチテーブル

エージェントファイル	ティア	対象の参照資料／ステップ	書き込まれる成果物
agents/tool-installer.md	cheap	references/tool-installer.md（ステップ 1）	reports/.artifacts/security-audit/step_01_security_tool_installer.md
agents/file-analyzer.md	cheap	references/file-analysis.md（ステップ 2）	reports/.artifacts/security-audit/step_02_security_file_analysis.md
agents/secret-scanner.md	cheap	references/secret-patterns.md（ステップ 3）＋ references/gitleaks.md（ステップ 4）	reports/.artifacts/security-audit/step_03_security_secret_patterns.md、reports/.artifacts/security-audit/step_04_security_gitleaks.md
agents/sast-analyzer.md	cheap	references/sast.md（ステップ 8）	reports/.artifacts/security-audit/step_08_security_sast.md
agents/dependency-analyzer.md	mid	references/dependency-audit.md（ステップ 5）＋ references/dependency-age.md（ステップ 6）＋ references/trivy.md（ステップ 7）	reports/.artifacts/security-audit/step_05_security_dependency_audit.md、reports/.artifacts/security-audit/step_06_security_dependency_age.md、reports/.artifacts/security-audit/step_07_security_trivy.md
agents/report-writer.md	frontier	references/report-generator.md（ステップ 9）＋ references/report-format-enforcer.md（ステップ 10）＋ assets/report-template.md	reports/<YYYY-MM-DD>-<project>-security-audit.md、reports/.history/last_security_scores.json

モデルティアは、プロバイダーに依存しないシンボリック名です。CLI トランスフォーマーは、インストール時にこれらを具体的なモデル ID に解決します（例：Claude の場合、cheap→haiku、mid→sonnet、frontier→opus）。

レポートファイル名（必須）

レポートファイル名は常に次のとおりです。

<YYYY-MM-DD>-<project>-security-audit.md

• <YYYY-MM-DD> — 今回の実行日です。
• <project> — git リポジトリ名を kebab-case に変換したものです。小文字にし、 スペース、_、.、/ を - に置き換え、その他の文字をすべて削除し、 連続する - をまとめます。名前は origin リモート URL から取得するため、 チェックアウトディレクトリ、ワークツリー、サブディレクトリの名前に関係なく 同じになります。リモートがない場合はメインチェックアウトのディレクトリ名、 git リポジトリ外の場合は現在のディレクトリ名を使用します。
• 末尾のセグメントはこのスキルの名前で、変更されることはありません。

何かを書き込む前に、一度だけ導出します。

mkdir -p reports
REPO="$(git remote get-url origin 2>/dev/null | sed -E 's#/+$##; s#.*[/:]##; s#\.git$##')"
if [ -z "$REPO" ]; then
  COMMON="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)"
  [ -n "$COMMON" ] && REPO="$(basename "${COMMON%/.git}" .git)"
fi
[ -n "$REPO" ] || REPO="$(basename "$PWD")"
REPORT="reports/$(date +%F)-$(printf '%s' "$REPO" \
  | tr '[:upper:]' '[:lower:]' | tr ' _./' '-' \
  | sed -E 's/[^a-z0-9-]//g; s/-+/-/g; s/^-|-$//g')-security-audit.md"

このスキルが reports/<YYYY-MM-DD>-<project>-security-audit.md に書き込む場合は、 すべてこの解決済みパスを指します。

reports/.history/last_security_scores.json はレポートではありません。次回の実行時に読み戻す傾向データであるため、固定名のままとし、日付を付けません。

somnio run 経由で実行する場合、CLI がレポートの完全なパスを計算し、プロンプトに渡します。渡されたパスをそのまま使用してください。再計算すると、ランナーがレポートを見つけられず、ステップが失敗します。

レポートのメタデータ（必須）

生成するすべてのレポートには、末尾にメタデータブロックを必ず含めてください。これは必須事項です。決して省略しないでください。

テンプレートの Report Metadata テーブルをレポートの最後のブロックとしてコピーします。Generated by 行はテンプレートに記載されたとおりに保持してください。バージョンを変更、推測、または省略しないでください。残りの行は説明に従って記入します。

レポートの末尾に次のブロックを含めてください。

## 12. Report Metadata

| Field | Value |
|-------|-------|
| Scan date | [Date] |
| Project path | [Path] |
| Project type | [Detected type] |
| Tools used | [List of tools] |
| Total findings | [Count] |
| Scan duration | [Duration or N/A] |
| Generated by | Somnio CLI v3.2.12 |
| Skill | security-audit |
| Somnio AI Tools | https://github.com/somnio-software/somnio-ai-tools |