aegis-vulnerability-management-process

脆弱性管理プロセス（VULN）

適応に関する注記 — 最初にお読みください

このモジュールは、意図的にレッドチーム向けテンプレートから変更されています。脆弱性を探すものではなく、ほかのすべてのモジュールが生成する成果物を処理する、反復的なループを定義します。各セクションの意味は、次のように置き換えられています。

テンプレートのセクション	ここでの意味
確認項目	既存の VM プログラムの準備状況／成熟度監査：各ループ段階が存在し、証拠があるか
確認場所	プログラムの成果物を配置する場所：追跡用ディレクトリ、登録簿、カレンダー、cron、CI 設定
パターンとシグネチャ	テンプレート：優先度の決定ツリー、記入例、例外スキーマ、指標の計算式、アジェンダ
汚染追跡のガイダンス	1 件のアドバイザリ／監査の出力が、最終状態に至るまで各段階にどう伝播するか
悪用と再現	机上演習：1 件の検出事項を、紙上でループ全体の最初から最後までたどる
修正	不足している段階を依存関係の順に構築する
重大度評価	優先度調整の区分と SLA 表そのもの

空の cwe 配列は意図的なものです。このモジュールはコードレベルの脆弱性クラスではなく、プロセスの能力を監査します。両方のオーケストレーター、つまり SKILL-CODE.md（コードスラグ）と SKILL-SERVER.md（ホストスラグ）の下流に位置し、IR（skills/operations/incident-response/SKILL.md）のインシデント対応側の語彙を借用します。検出事項を生成する対象は、プログラム自体に限られます。

前提条件と用語

予備知識がなくても読めるよう、このモジュールで使用する用語をそれぞれ一行で説明します。各分類の平易な言葉による詳しい説明は、リポジトリの GUIDE.md 用語集にあります。

• SLA：各優先度レベルに対して約束された修正の最長所要時間
• トリアージ：新たに届いた検出事項ごとに、優先度と対応期限を決めること
• MTTR：発見から、修正が検証されクローズされるまでの平均時間
• 例外登録簿：意図的に対応を延期した検出事項を記録した一覧。各項目には担当者と期限が設定されます
• 緩和策と修正の違い：リスクを低減する回避策と、実際の修理の違い。記録には必ずどちらかを明記する必要があります
• 期限付き受容：既知の問題を定められた期間にわたって正式に受容し、その後に再レビューすること
• 汚染フロー／ソース→シンク：信頼できないデータが入口から危険な関数へ移動する経路（ここでは、検出事項がループの各段階に伝播する仕組みに置き換えられています）
• 検出事項のステータス：確認済み > 可能性が高い > 要レビュー。証拠のルールは templates/finding-report.md に記載されています

範囲と目標

2つの側面で、1つのライフサイクルを構成します。

前半 — プログラム準備状況の監査。 根拠を示して答えます。明日、監査、スキャナー、アドバイザリーフィードから指摘が見つかったとき、発見から検証済みのクローズまでの間に、場当たり的な対応以外の何かが行われるでしょうか？

後半 — ループ運用システム。 各段階ですぐに記入して使えるテンプレートを用意します。ループ憲章、トリアージ記録、SLA のデフォルト値、例外登録簿、メトリクス一式、月次レビューのアジェンダ、実施頻度のスケジュールです。

このモジュールを使って監査を実施した際の成果物：

1. ループのスコアカード — 各段階を「存在／一部整備／未整備」で評価し、成果物への参照先を記載します。
2. Remediation に引き継ぐギャップ一覧 — 「未整備」の段階をすべて、担当者付きの構築タスクにします。
3. 採用したテンプレート — SLA 表、例外登録簿、アジェンダのひな型をチームのドキュメントに配置し、角括弧内を記入します。
4. 過去分をトリアージしたバックログ — オープンな指摘に、重要度だけでなく、記録済みの優先度判断を付与します。
5. メトリクスのベースライン — 5つの数値を一度手作業で算出し、以降は毎月算出します。

運用ルール：

• 取り込み、重複させない。 監査モジュールは重大度を決定します（評価基準が規範となります）。このモジュールは優先度と期限を決定します。トリアージ中に評価基準の重大度を蒸し返すことは禁止です。代わりに、優先度を明示的に調整してください。
• トラッカーはファイルです。 オープンな指摘が約50件に達するまでは、指摘ごとの .md ファイルを格納したディレクトリと、インデックスファイル1つがシステムそのものです。まずツールを導入してはいけません。
• 緩和措置を正直に記録する。 記録には、実施した対応を必ず記載します。修正済み、緩和して期限のカウントを停止、または期限付きで書面上承認済み、のいずれかです。この3つを曖昧にすることは、小規模チームでよくある失敗です。
• すべての段階で成果物を作成する。 記録されていないトリアージ、アーカイブされていないスイープ、日付のないレビューは、実施されなかったものとします。

対象外：監査自体の実施（SKILL-CODE.md / SKILL-SERVER.md）、インシデント対応（IR）、ページングのしきい値（DETECT）、パッチ適用の仕組み（PATCH）、バックアップ訓練（DR）。このモジュールは、それらの出力をつなぎ合わせます。

メンタルモデル

このスキルセットを各段階に対応づけたループ：

            ┌─────────────────────────────────────────────────────────┐
            │                                                         │
            ▼                                                         │
   [1 INVENTORY]  repos, hosts, tunnels/hostnames, k8s clusters,      │
    what exists?   DBs, third-party SaaS with data access, DNS names  │
            │                                                         │
            ▼                                                         │
   [2 FIND]       <- SKILL-CODE.md / SKILL-SERVER.md audits on cadence;    │
    hunt for      dependency scanners (commands per SUPPLY module);   │
    weaknesses    sweep-patching.sh host state; distro security       │
                  trackers; pentest/bug-bounty intakes                │
            │                                                         │
            ▼                                                         │
   [3 TRIAGE &    priority = f(base severity, reachability/exposure,  │
    PRIORITIZE]    known-exploitation intel, asset criticality)        │
            │                                                         │
            ▼                                                         │
   [4 REMEDIATE]  batches BY COMPONENT, quick wins first inside the   │
    do the work    batch; fix-vs-mitigate decided explicitly; finding │
                   reports' Remediation sections ARE the work orders  │
            │                                                         │
            ▼                                                         │
   [5 VERIFY]     <- each finding's own Fix Verification Plan;        │
    prove closure  regression tests merged; module greps re-run;      │
                   run-all-sweeps.sh evidence diff where applicable   │
            │                                                         │
            ▼                                                         │
   [6 TRACK &     open-by-severity, MTTR per band, exception count,   │
    METRICS]      audit-coverage freshness, SLA breaches              │
            │                                                         │
            └─────────────────────────────────────────────────────────┘

5つの原則：

1. 監査の重大度は、運用上の優先度ではありません。 評価基準から重大度が導かれます。ループでは、影響範囲、到達可能性、悪用に関する情報、資産の重要度を加味して優先度を導きます。重大度が同じ2つの指摘が異なるキューに入るのは、システムが機能している証拠です。
2. 検証を経ない限り、ループから指摘がなくなることはありません。 templates/finding-report.md の Fix Status の遷移（Open → Fixed (unverified) → Verified-Fixed（または Risk-Accepted））には条件があります。最後の段階に進むには、その指摘の Fix Verification Plan を実行する必要があります。そのため、テンプレートではこのセクションを必須としています。
3. 期限のカウントは修正時ではなく、トリアージ時に始まります。 指摘に優先度が割り当てられた時点でSLAのカウントダウンが始まります。トリアージ前のバックログ期間は、プログラム上の別の不備です。
4. インベントリが結合キーです。 アドバイザリーはパッケージ単位で届きますが、影響はサービス単位で決まります。「自分たちはこれを実行しているか？」に数分で答えられるのは、インベントリだけです。インベントリがなければ、情報を掘り起こす必要があります。
5. 継続性は英雄的な奮闘に勝ります。 四半期ごとに繰り返す全体監査、毎週の cron スイープ、30分の月次レビューは、恐ろしいブログ記事を読んだ後の一時的な努力より効果的です。

実施頻度のデフォルト値（全表は Patterns & Signatures を参照）：全体監査は四半期ごと、または大きな変更があったときに実施します。対象を絞った監査はイベント発生時に実施します。スイープは毎週、アドバイザリーの監視も毎週実施します。インベントリの再確認は最低でも四半期ごと、レビューは毎月実施します。

確認項目

ループの各段階を監査し、「存在／一部整備／未整備」で評価して、成果物への参照先（または成果物がないこと）を記録します。定義：「存在」＝成果物が存在し、最新の状態で、指名された担当者が要求に応じて提示できます。「一部整備」＝存在するものの、古い、担当者が不在、または実行されていません。「未整備」＝場当たり的な対応が仕組みになっています。

V1. ステージ 1 — インベントリが存在し、最新であることが再認証されている

インベントリには、すべての対象領域が含まれています。コードリポジトリ、ホスト、Cloudflare トンネルとそのホスト名、k8s クラスター／名前空間、データベース、データアクセス権を持つサードパーティ SaaS（決済、メール、分析、エラー追跡）、およびすべての DNS 名が対象です。証拠：項目ごとの last-reviewed 日付を記載した、名前の付いた成果物が 1 つあり、90 日以内（最低でも四半期ごと）に再認証されていること。コードとしてのインベントリの原則：可能な限り IaC／マニフェストから項目を導出し、最新性が自動的に保たれるようにします。双方向で照合します。インベントリから無作為に 2 行選び、実環境に存在することを確認します。また、稼働中のサービスまたは DNS 名を 1 つ選び、インベントリに記載されていることを確認します。最も新しいサービスが記載されていない場合、この項目は不合格です。継続的に更新する成果物：sweep-code-recon.sh の出力アーカイブと、最新の TARGET-PROFILE.md ／ HOST-PROFILE.md（SKILL-CODE.md Phase 1 ／ SKILL-SERVER.md Phase 1 を相互参照）。

V2. ステージ 2 — FIND の情報源が、実際に連携されている

各情報源について、明示された意図ではなく、実際のトリガーがあることを確認します。

情報源	存在する状態	要求する証拠
全体監査	前四半期中に実施済み、または大きな変更時のトリガーが文書化されている	security-audit/ 配下の日付入り実行ディレクトリ、PROGRESS.md ファイル
対象を絞った監査	イベント駆動のルールが明文化されている（新しいエンドポイント／サービス／依存関係の分類が発生したら、同じスプリント内にそのスラッグを監査する）	規約文書と最近実施した対象監査
依存関係スキャン	エコシステムごとのコマンドが CI またはスケジュールに従って実行される	SUPPLY-module のコマンドを呼び出すワークフローファイル
ホストのパッチ適用状況	sweep-patching.sh の出力がホストごとにアーカイブされ、レビューされている	tools/run-all-sweeps.sh による日付入りの証拠ディレクトリ
アドバイザリーの監視	ディストリビューションのセキュリティトラッカー（Ubuntu Security Notices ／ Debian tracker ／ Fedora errata）と依存関係のアドバイザリーフィード（RustSec、npm／GitHub advisories）を毎週確認する習慣がある	定期的なカレンダー登録と日付入りのメモファイル
外部からの情報	ペンテストレポート／バグバウンティレポートの名前付き受付経路がある（「トリアージに転送」というプレースホルダーでも可）	トラッカーへの経路が文書化されている
動的スキャン（DAST）	OWASP ZAP（または同等のツール）で到達可能な環境のベースラインスキャンを定期的に実行し、検出結果を同じトラッカーに反映している	スキャン設定と日付入りのレポート。注：動的テストは、このキットの静的スコープの対象外です。ZAP のようなツールが橋渡しとなり、その検出結果も同様にステージ 3 に取り込まれます

V3. ステージ 3 — トリアージのルールが文書化され、実際に適用されている

優先度の計算式が記録されている（Patterns & Signatures）。SLA テーブルが承認を得て採用されている。未解決の各検出項目に、基本深刻度、調整内容、最終優先度が TRIAGE RECORD に記載されている。逸脱には書面で根拠を示します。検出項目を 5 件サンプリングし、TRIAGE RECORD が 1 件でも欠けていれば、この項目の評価は PARTIAL が上限です。

V4. ステージ 4 — 修正ワークフローが整理されている

修正作業は深刻度ごとに散在させず、コンポーネント／サービスごとにまとめます。検出項目レポートの Remediation セクションを作業指示としてそのまま使用します。修正と緩和の判断は根拠とともに記録し、サービスごとにダウンタイムの時間帯をまとめます。

V5. ステージ 5 — 検証ゲートが徹底されている

各検出項目について、固有の Fix Verification Plan を実行しない限り Verified-Fixed にしません。対象を絞った PoC の再テスト、回帰テストのマージ、再スキャン対象範囲の grep の再実行と問題がないことの確認、該当する場合はスイープ証拠の実施前／実施後の差分のアーカイブが必要です。クローズ済みの検出項目をサンプリングし、この証拠の連鎖を確認します。

V6. ステージ 6 — 追跡とメトリクスが存在する

1 つのインデックスから、実行ディレクトリ全体の検出項目ファイルを検索できます。5 つのメトリクスを 30 分以内に算出できます。日付入りのアジェンダファイルを用意し、月次レビューを実施します。誰も検索できないトラッカーは、完全性にかかわらず PARTIAL です。

V7. 例外ワークフローが徹底されている

登録簿が存在し、各行に有効期限（180 日以内）を含む必須フィールドがすべて記載されています。期限切れの例外は、黙って延長せず、期限内にレビューされています。

V8. 実際にスケジュールされた実施頻度

四半期ごとまたは変更時の完全監査、イベント駆動の対象限定監査、週次スイープ、週次のアドバイザリ確認、月次レビュー、四半期ごとのインベントリ再確認を示すカレンダー／cron／CI の証跡が必要です。スケジュールされていない実施頻度は、定義上 PARTIAL です。意図だけでは繰り返し実施されません。

確認場所

機能があれば、成果物が残ります。本来あるべき場所に成果物がないこと自体が、調査結果となります。

項目	保存されているべき場所	典型的な欠如
プログラム憲章 + SLA 表（V3）	バージョン管理されたドキュメント（docs/vuln-mgmt.md または wiki のルート）にあり、CI とレビュー議題からリンクされている	チャットの履歴か誰かの頭の中にしかない
発見事項トラッカー／インデックス（V6）	<run-id>/findings/ 内のすべての発見事項ファイルをインデックス化する単一の security-audit/TRACKER.md。未解決項目が約50件を超えた場合に限り、スプレッドシート／DefectDojo クラスのツールへ移行する	発見事項が古い実行ディレクトリに取り残され、インデックスがない
インベントリ成果物（V1）	TARGET-PROFILE.md／HOST-PROFILE.md と sweep-code-recon.sh のアーカイブを基に更新され、項目ごとのレビュー日が記録された、継続的に管理されるドキュメント	監査のたびに場当たり的に再生成され、実態と照合されない
例外レジスター（V7）	単一の security-audit/EXCEPTIONS.md	承認が DM／チケットに散在している
スイープのスケジュール（V2/V8）	tools/run-all-sweeps.sh を実行する cron／systemd タイマーまたは CI ジョブ。証跡は日付付きディレクトリにアーカイブされる	「監査中に一度実行した」
依存関係スキャン（V2）	エコシステムごとに SUPPLY モジュールのコマンドを実行する CI ワークフローファイル（.github/workflows/*.yml）	手動実行しかなく、最後の出力が何か月も前のもの
アドバイザリ監視メモ（V2）	毎週繰り返すカレンダーイベント + 追記専用のメモファイル	誰がトラッカーを監視しているのか、誰も説明できない
監査の実施頻度（V8）	四半期ごとのカレンダーイベント + 対象限定監査のトリガー一覧を記載した文書	最後の完全監査から12か月以上が経過している
トリアージ記録（V3）	各発見事項ファイル内の追記セクション、または発見事項 ID を参照する一元管理の決定ログ	優先度が口頭で決められ、記録されていない
メトリクス + 議題（V6）	トラッカーと並べて保存する、日付付きの月次ファイル	数値を四半期ごとに記憶を頼りに再計算している

また、憲章の git 履歴も確認してください（年に一度しか編集されないドキュメントは、棚に置かれたままの文書です）。CI のスキャン手順が実際に成功しているかも確認してください（無視されたままの赤いジョブは、ない場合よりも悪く、無視を常態化させます）。

パターンとシグネチャ

運用テンプレートです。すべてのブロックは記入して使える状態です。発見事項が届いてからではなく、届く前にチームのドキュメントへコピーし、角括弧内を記入してください。

P1. 優先度決定ツリー（ステージ 3 の中核）

START: base severity from the finding report (C/H/M/L/Info). The rubric in
       templates/finding-report.md is normative; do NOT re-derive it.
  |
  v
Q1 KNOWN EXPLOITATION: maps to a CISA Known Exploited Vulnerabilities (KEV)
   Catalog entry, or credible active-exploitation reporting for the class?
   YES -> P0 treatment: fix-or-mitigate inside 7d REGARDLESS of base severity.
   Record what maps.
  |
Q2 REACHABILITY: vulnerable surface reachable from public internet WITHOUT
   auth? YES -> bump one band UP (Critical stays Critical; Low -> Medium).
   NO -> keep band; record the gate (auth / internal-only / build-time).
  |
Q3 COMPENSATING CONTROLS: does a named control genuinely cover THIS path?
   (Cloudflare WAF rule blocking the payload class; Cloudflare Access gating
   the admin route; tunnel ingress pinning the hostname; egress firewall
   denying metadata reach) -> MAY hold at band WITH written justification:
   control named, what it blocks, what slips past. Provisional — control
   changing or failing reopens the question automatically.
  |
Q4 EPSS TIE-BREAK: published EPSS score exists for the relevant CVE (FIRST
   Exploit Prediction Scoring System — probability-of-exploitation)? Use it
   to order same-band items, higher first. Never invent or estimate scores;
   "not consulted" is a valid entry.
  |
Q5 ASSET CRITICALITY: payment path > auth plane > prod data stores > internal
   tooling > marketing site. Same-band conflicts resolve toward the more
   critical asset; criticality also justifies tightening SLAs below.
  |
  v
FINAL PRIORITY (P0-P3) -> SLA clock starts today (table in Severity Assessment).

記入して使えるトリアージ記録（各発見事項ファイルまたは一元管理のログに追記）：

TRIAGE RECORD — <SLUG-NNN>
Base severity: [C/H/M/L]        (from finding report — not re-litigated here)
KEV / active exploitation: [no | yes + source named]
Reachability: [internet-unauth | internet-auth | internal-only | build-time]
Band adjustment: [none | bumped +1 band | held-at-band-with-control]
Compensating control: [named control + covers / does-not-cover]
EPSS: [published value + date checked | "not consulted"]
Asset criticality: [payment-path | auth-plane | prod-data | internal | marketing]
FINAL PRIORITY: [P0|P1|P2|P3]   SLA due date: [YYYY-MM-DD]
Decided by / date: [name] / [date]

P2. 優先順位付けの具体例（発見事項3件）

発見事項 A — SSRF-003、Webhook URL フェッチャーの SSRF。基本 High。 Q1：アプリケーションロジックの欠陥であり、CVE はない → KEV へのマッピングなし。Q2：エンドポイントはインターネットから到達可能だが、リクエストに署名が必要（認証済みクラス）→ 自動引き上げなし。ゲートを記録。Q3：ホストの送信ファイアウォールが 169.254.169.254／リンクローカルを拒否し、メタデータへの経路は閉じている → High のまま HOLD。根拠にはルールと、すり抜ける可能性があるもの（DNS リバインディングクラスのフェッチ）を明記。Q5：決済統合経路のため、同じバンド内で緊急度を上げる。最終：P1、期限30日 — バンド内に維持し、引き下げはしない。ファイアウォールルールが変更された場合は、保留の期限が切れる。

発見事項 B — SUPPLY-004、本番経路で使用される脆弱な依存関係、DoS クラスの CVE。基本 Medium。 Q1：CVE が KEV Catalog に掲載されている → ただちに JUMP QUEUE。最終：P0、7日以内に修正または緩和。基本が Medium であっても、実環境での悪用は理論上の影響度計算より優先される。

発見事項 C — WEB-007、CSP ヘッダーの欠落（反射型 XSS の妨害に関するクラス）。基本 Low。 Q1：マッピングなし。Q2：マーケティングページは認証不要でインターネットから到達可能 → 1バンド引き上げ、Low → Medium。Q3：代替コントロールの主張なし → 保留なし。Q5：最も重要度の低いアセットは、新しいバンドの下限にとどまる。最終：P2、期限90日 — 引き上げを正直に適用し、1バンドを超えて上げない。

P3. 例外登録簿のスキーマ

# Exception Register — security-audit/EXCEPTIONS.md
# Every field mandatory. Expiry MANDATORY, max 180 days from approval.

| Exception ID | Finding ID | Reason (why now) | Compensating control | Owner | Approved by | Expiry date | Review trigger |
|---|---|---|---|---|---|---|---|
| EXC-2026-001 | AUTHZ-002  | [refactor lands next sprint] | [Access policy gates admin route] | [name] | [name] | 2026-11-20 | [policy removed / new pentest finding] |

ルール：オーナーまたは有効期限が記入されていない行は無効です。修正されるまで、その指摘事項は優先度を最大として未解決として扱ってください。期限切れの例外があると、指摘事項は元の優先度で自動的に再開されます。補完的な統制が変更された場合は、レビューのトリガーが早期に作動します。指摘事項ファイルのRisk-Accepted修正ステータスは、ここにある該当行へのリンクです。

P4. 実施頻度の表＋スイープ用 cron の概要

アクティビティ	トリガー	実施頻度
適用対象のすべてのスラッグに対する完全監査（SKILL-CODE.md ＋ SKILL-SERVER.md）	定期実施、または大規模な変更（新規サービス、認証の全面的な見直し、移行）	最低でも四半期ごと
対象を絞った監査	イベント駆動：新しいエンドポイント／サービス／依存関係のクラスの導入	導入するスプリント内
ホストのスイープ（tools/run-all-sweeps.sh）	定期実施	毎週
依存関係のスキャン	main へのプッシュ＋定期実施	CI ごと、最低でも週 1 回
アドバイザリーの監視（ディストリビューションのトラッカー＋依存関係のアドバイザリー）	定期的な確認	毎週、約 30 分
インベントリの再確認	定期実施	最低でも四半期ごと
月次 VM レビュー	カレンダー	毎月、厳守で 30 分
DR 復元訓練	DR モジュールごとの実施頻度	DR モジュールごと
例外期限の確認	定期実施	毎月（議題項目）

# /etc/cron.d/vuln-mgmt-sweeps (or systemd timer) — weekly read-only sweeps,
# evidence archived by date; %% escaping so cron passes literal % to date(1).
0 6 * * 1  ubuntu  cd /opt/sec-tools/aegis-skills && ./tools/run-all-sweeps.sh \
  > /var/log/vm-sweeps/"$(date +\%Y\%m\%d)"-sweeps.log 2>&1

CI 版：同じスクリプトに加えて SUPPLY モジュールのスキャナーコマンドを実行する、夜間の定期ワークフローです。フェイルオープンは禁止です。スキャンジョブが気付かれずに無効化された場合は、誰かにページャー通知を送る必要があります（DETECT の配線に関する規律）。

P5. メトリクスの計算式（ファイルから計算し、推定せずに数え直す）

メトリクス	計算式	信頼できる情報源
重大度別の未解決件数の推移	Fix Status ∈ {Open, Fixed (unverified)} の指摘事項ファイル数を重大度別に集計。毎月スナップショットを記録	<run-id>/findings/*.md にあるトラッカーのインデックス
重大度別の平均修正所要時間（MTTR）	重大度区分ごとに、Verified-Fixed に到達した日付 − 指摘事項ファイルの作成日付の平均を算出。Risk-Accepted は除外し、MAX も報告	指摘事項ファイルの日付／ステータス
例外件数＋期限間近の件数	登録簿の行数。有効期限まで 30 日以内の行を別途集計	EXCEPTIONS.md
監査カバレッジの最新性	スラッグごとに、最後の完全監査／対象を絞った監査からの経過日数 ＝ 今日 − そのスラッグに触れた最新の実行の run-id の日付	security-audit/<run-id>/PROGRESS.md ファイル
SLA 違反件数	SLA 期限が今日より前の未解決の指摘事項を、優先度別、古い順に一覧表示	トリアージ記録

P6. 月次レビューの議題の概要（30 分、厳守）

MONTHLY VM REVIEW — <YYYY-MM>
1. Numbers first (5m): five metrics vs last month; note trends, not anecdotes.
2. SLA breaches (10m): every breached finding gets a NEW committed date or an
   escalation; "we'll get to it" is not an outcome.
3. Exceptions (5m): expiring ≤30d — renew with fresh justification or lapse to
   open; verify compensating controls still exist.
4. Coverage gaps (5m): slugs stale beyond a quarter → schedule targeted audits.
5. One improvement (5m): smallest automation that shrinks NEXT month's load.
Output: dated agenda file appended beside tracker; actions get owners+dates.

テイント追跡ガイダンス

入力（アドバイザリ、スキャナーの出力、監査での指摘、外部レポート）が、各段階を経て終端状態に至るまで、どのように伝播するかをマッピングします。すべての入力はシンクに到達しなければなりません。フローの途中で消える入力は、このループの漏れです。

SOURCES (entry points):                SANITIZERS (legal transformations):
 - finding file, any slug of             - dedup merge onto existing finding
   SKILL-CODE.md / SKILL-SERVER.md              (SKILL-CODE.md Phase 4; cross-ref line,
 - dependency-scanner output               not duplicate file)
   (SUPPLY-module commands)              - documented compensating control
 - sweep-patching.sh evidence              (holds band, never deletes)
 - distro security notice / dep          - scope exclusion WITH recorded
   advisory feed                           reason ("vendored fork, patched" + proof)
 - KEV catalog update / EPSS movement    - false-positive disproval w/ evidence
 - pentest / bug-bounty report
 - staff observation                     SINKS (terminal states only):
                                           - Verified-Fixed (evidence chain)
                                           - Risk-Accepted (exception row)
                                           - closed-as-false/disproven (recorded)

伝播ルール：

1. 1営業日以内に単一のエントリーポイントへ登録します。 すべての情報源は、新規の指摘ファイル（テンプレートをそのまま使用）として、または既存ファイルへの相互参照行として、トラッカーに記録されます。チャットで話題になっていても、トラッカーに記録されていないアドバイザリは、受領されていません。
2. トリアージの前にインベントリを照会します。 パッケージごとの入力について、まずインベントリで照合します。どのリポジトリがそのパッケージをインポートしているか、どのホストで実行されているか、どのトンネルからアクセスできるかを確認します。ビルドホストと決済経路の API で同じ CVE が見つかった場合でも、優先度が異なる2つのインスタンスとして扱います。
3. TRIAGE RECORD なしに作業を開始しません。 優先順位を付ける前に修正を始めると、声の大きい人がキューを決めることになります。テイントは、Stage 4 が開始する前に Stage 3 まで到達します。
4. Stage 4 では、作業指示として指摘の Remediation セクションをそのまま引き継ぎます。 作業途中でスコープを変更する場合は、トリアージに戻して再度確認します。変更を黙って反映してはいけません。
5. Stage 5 は、良好なシンクへ進むための障壁です。 Open から Fixed (unverified) へは、差分がマージされていれば進められます。Verified-Fixed にするには、FVP の実行が必要です。PoC の再テスト、回帰テストのマージ、再スキャンの grep で問題がないことの確認、および該当する場合はスイープ差分のアーカイブが必要です。
6. サニタイザーは一時的なものです。 補償制御による保留は、制御が変更されると期限切れになります。例外行には日付による期限があり、どちらかの事象が発生すると、指摘は元の優先度で再投入されます。
7. すべての入力は、記録とともに、名前が付けられた1つのシンクを通って終了します。 成果物なしに「問題ないと判断した」だけではシンクになりません。それは漏れです。

悪用と再現

再構成版：1つの調査結果が最初から最後まで完全なサイクルをたどる様子を、紙上で検証する卓上ウォークスルーです。非破壊的で、パケットは一切送信しません。実在するチームの成果物があれば使用し、見つからないものは準備状況に関する指摘として記録します。所要時間は60分、参加者はテックリードと監査担当者1名です。ファシリテーターが各段階を進行し、想定外の事態を提示して、成果物を評価します。

対象： INJ-001 — orders-api の注文検索エンドポイントにおける、サニタイズされていない ORDER BY を介した SQL インジェクション。ステータスは Confirmed、基本深刻度は High、完全な修正検証計画（FVP）が調査結果レポートに記載されています。

日	段階	紙上で起こること	作成される成果物
D0	FIND	四半期ごとの完全監査で INJ スラッグを割り当てます。PoC と FVP を含む調査結果ファイルを作成します	findings/INJ-001-order-search.md、PROGRESS.md の行
D0	INVENTORY	トラッカーの索引で、調査結果からインベントリ行にリンクします：orders-api、cloudflared トンネル経由でインターネットに公開、Postgres バックエンド、決済パス	トラッカー索引の行
D1	TRIAGE	トリアージ記録：KEV へのマッピングなし（アプリケーションロジックの欠陥）。インターネットから未認証で到達可能なため、High から Critical 相当の扱いに引き上げます。適用可能な制御策の申告なし（トンネルの Access ポリシーは、この公開された製品エンドポイントを制御しません — 利用不可として扱います）。資産は決済パスです	記入済みトリアージブロック
D1	CLOCK	最終優先度は P0 相当です。SLA 期限は D8 です	期限を記録
D2–D7	REMEDIATE	1つのウィンドウで orders-api コンポーネント全体をまとめて処理します。同じサービスで見つかった INJ-001 と関連する LOGIC-003 の競合状態が対象です。まず簡易修正を実施します（レポートによると、ORDER BY の許可リスト化にかかる時間は1時間未満）。修正と緩和策の選択欄では、WAF ルールを最終対策としては却下します。ペイロードの形式がさまざまであるためです。判断を記録します	調査結果 ID を参照するマージ済み PR
D7–D8	VERIFY	この調査結果の FVP を実行します。元の PoC は HTTP 400 を返すようになりました。GIVEN/WHEN/THEN 回帰テストを CI にマージしました。変更ファイルに対してインジェクションモジュールの grep を再実行し、問題がないことを確認しました。コード修正のため差分スイープは該当せず、対象を絞った再スキャンを記録します	テスト名と出力を調査結果ファイルで参照
D8	TRANSITION	マージ時に Fix Status を Open → Fixed (unverified) に変更し、ゲート通過後に Verified-Fixed に変更します	ステータスを更新
D9	TRACK	メトリクスを更新します。MTTR のサンプルは9日で、P0 の7日 SLA を超えていますが、違反としてカウントされますか？いいえ。D8 に検証済みのため、期限内です。INJ のカバレッジ最新性のタイムスタンプを更新します	月次メトリクスのスナップショット
D30	REVIEW	月次レビューでこの事例を取り上げます。教訓：コンポーネント単位でまとめて処理したことで、深刻度ごとに分散していたら対応が先送りされていた LOGIC-003 が表面化しました	議題ファイルの記載

ファシリテーターが提示する想定外の事態（ウォークスルーの途中で1つ提示します）：

• 「Cloudflare Access ポリシーでこのエンドポイントを制御できるとしたら、そこで保留しますか？どのくらいの期間ですか？」（修正と緩和策の選択欄と期限管理）
• 「D6 に、正当な Unicode の order-by 値で回帰テストが失敗します。」（VERIFY は正直にクローズを阻止しますか？）
• 「同じパターンが、別のリポジトリの管理ツールにも見つかりました。」（インベントリへの反映と再トリアージを行い、優先度をコピー＆ペーストしません）
• 「検証時に修正担当者が休暇中です。」（バス係数：誰が FVP を実行できますか？）

合格基準：6つすべての段階で、指定された成果物が作成されていること。テンプレートのルールに基づき、両方のステータス遷移が適切であること。期限が守られていること。提示されたすべての想定外の事態について、その場しのぎではなく判断が記録されていること。

是正措置

不足している段階を構築し、各ステップが次のステップを可能にする順序で進めます。各項目は対応する V 検出事項に紐づき、成果物を作成します。

B1. まずトラッカーを用意します（V6 を修正）。 security-audit/TRACKER.md を作成し、すべての実行ディレクトリにある検出事項ファイルを索引化します。項目は ID、タイトル、重大度、修正状況、優先度、期限です。ほかの作業に着手する前に、<run-id>/findings/ を 30 分かけて grep します。後続のすべての段階で、このファイルを読み書きするためです。

B2. トリアージ基準と SLA の既定値を採用します（V3）。 Severity Assessment の表を docs/vuln-mgmt.md にコピーし、TEAM-TUNABLE の行に印を付け、指名したオーナー 1 名の承認を得ます。未解決のバックログを古いものから順に遡及トリアージし、未解決の検出事項すべてに TRIAGE RECORD が付くまで続けます。バックログに期限が設定されるまでは新しいスキャンを実施しません。そうしないと、意思決定より速く負債を生み出すことになります。

B3. インベントリを継続的に更新される成果物にします（V1）。 最新の TARGET-PROFILE.md と HOST-PROFILE.md を 1 つのインベントリドキュメントに統合し、7 つすべてのサーフェスクラスを網羅するように、各項目に last-reviewed の日付を付けます。DNS ゾーン一覧、トンネルの ingress 設定、k8s の名前空間ダンプと照合して現状を確認し、四半期ごとの再確認リマインダーを設定します。可能な限り IaC から導出し、記憶に頼らず自動的に最新状態を保ちます。

B4. FIND ソースを自動化します（V2）。 手間の少ないものから順に実施します。（1）存在するエコシステムごとに SUPPLY-module スキャナーコマンドを実行する CI ジョブ、（2）日付入りの証跡ディレクトリを作成する tools/run-all-sweeps.sh の週次 cron、（3）カレンダーの予定 — 四半期ごとのフル監査、ディストリビューションのトラッカーと依存関係フィードの週次確認、（4）イベント駆動型の対象を絞った監査のための、文書化されたトリガー一覧。

B5. 検証ゲートを必須にします（V5）。 CONTRIBUTING にチーム規約を定めます。検出事項を修正する PR は、必ず検出事項 ID を参照し、その Fix Verification Plan を実行します。回帰テストはコメントではなく CI に追加します。レビュアーはテストを求めるのと同じように、FVP の証跡を求めます。

B6. 例外レジスターを作成します（V7）。 P3 スキーマを security-audit/EXCEPTIONS.md にコピーします。口頭でのリスク受容は直ちに移行します。オーナーと期限がない従来の「問題ないと判断した」という項目は、今日から優先度を下げずに OPEN に戻します。

B7. 初回の月次レビューを実施します（V6/V8）。 5 つのメトリクスを一度手作業で算出します。手間がかかること自体が診断になります。30 分を確保し、日付入りのアジェンダファイルを追加します。あとは定例化すれば進みます。

B8. すべての実施頻度をスケジュールします（V8）。 P4 の表に基づき、カレンダーと cron に登録します。成果物だけを見れば、初めて見る人でも各活動の次回実施時期を予測できる状態になって初めて完了です。

順序の根拠：トラッカーは基準より先に用意します（実在する項目に優先順位を付けるため）。基準は自動化より先に整えます（スキャナーが大量の検出事項を生み出す前に、期限を設定する必要があるため）。インベントリは早期に整えます（すべての入力を照合するため）。

少人数チームの現実 — 時間がない場合に削る順序

対応能力が著しく低下した場合は、以下の順（左端から）に削減します。

metrics formality < exception formality < monthly review < SLA-table precision
    < triage discipline < inventory accuracy

トリアージの徹底とインベントリの作成は、決して省略しないでください。この 2 つによって未知のリスクが既知のリスクに変わります。それこそが目的のすべてです。この 2 つより後の項目は、右側にあるファイルの正確性を保てば、後から再構成できるレポート作成の負担です。そこから導かれるのは、人員の増強より自動化を先にということです。決定論的なスイープ（tools/run-all-sweeps.sh、tools/sweeps/sweep-code-recon.sh、tools/sweeps/sweep-patching.sh）と CI スキャナーで、アナリストの作業時間を直接置き換えます。人員を増やすのは、自動化を最大限活用した後にしてください。

検証と妥当性確認

プログラムの検証は、検査ではなく実践によって行います。

能力	検証方法	合格基準
トラッカーの網羅性（V6）	稼働中のサービスをランダムに1つ選び、5分以内にトラッカーでそのサービスのすべての検出事項を見つけます	過去の記録を掘り起こさずに見つかる
トリアージの完全性（V3）	オープンな検出事項を5件、クローズ済みの検出事項を5件抽出します。TRIAGE RECORDがあり、調整がツリーに文字どおり従っていることを確認します	5件中4件以上が正しいこと。見落としは同じ週に修正
検証ゲート（V5）	Verified-Fixedの検出事項を10件抽出します。FVPの証拠（再テスト結果、マージ済みテスト名、再スキャンの参照情報）があることを確認します	10件すべて、または違反した検出事項をOpenに再オープン
例外の衛生状態（V7）	すべての行に担当者と180日以内の有効期限があり、期限切れの行が期日どおりに処理されていることを確認します	知らないうちに延長されたものがゼロ
SLAの算定	違反指標を手計算し、直近の報告値と照合します	数値が完全に一致
最新性（V1/V8）	インベントリが90日以内に再承認されており、登録済みのすべてのスラッグが所定の頻度期間内に監査されていることを確認します	範囲内であること、または不足分がチケット化されていること
全体のループ（すべて）	テーブルトップ演習（悪用と再現）を年2回、対象となる検出事項を交代させて実施します	どちらの回も合格基準を満たす

検証ルール：

1. すべての検証で成果物を作成します — サンプルシート、訓練記録、再計算メモなどです。成果物がなければ検証済みとは見なされず、次回の監査でPARTIALになります。
2. リグレッションが発生した場合、検出事項を当初の重大度と優先度で再オープンします — 劣化した修正が、以前のクローズ日を理由に優遇されることはありません。
3. 実際のインシデントが発生するたびに、このモジュールの準備状況監査（Half A）を再実行します。実際のインシデントは、利用可能な準備状況データの中で最も低コストです（IRの事後分析のAUDIT-SKILLSETセクションを相互参照）。
4. 毎年、デフォルト設定自体を監査します：SLAの期間、頻度の表、資産の重要度区分を再承認するか、意識的に変更します。放置によるずれが、プログラムを形骸化させます。

重大度の評価

意図的に分けた2つの層です。重大度は検出報告書の基準（templates/finding-report.md、悪用可能性を優先する場合のタイブレーク）に基づき、報告時に確定します。優先度は運用上のもので、ここで割り当てます。検出事項の優先度を上げたり維持したりできますが、気付かれないまま下げることはありません。

優先度の調整ルール

ルール	優先度帯への影響	制約
認証なしでインターネットから到達可能	1段階上げます（最大でCritical）	到達可能性の証拠をトリアージ記録に記載します
認証が必要／内部限定／ビルド時のみ	変更なし	ゲートを記録に明記します
KEVカタログへの該当、または信頼できるアクティブな悪用	優先度帯に関係なく、優先キューに移動してP0として扱います	情報源を明記します。伝聞は不可
補完的な制御がこの経路をカバー	現在の優先度帯を維持してもかまいません	正当化の根拠を記載します。制御に変更があれば維持は失効します
公開済みのEPSSスコアが存在	同じ優先度帯内での順序決定に使用します	値を捏造してはいけません。「参照せず」も可
資産の重要度（決済 > 認証 > 本番データ > 内部 > マーケティング）	同じ優先度帯で競合する場合、重要度の高い資産を優先します	区分はチーム憲章に記載します

2つの優先度のどちらにするか本当に迷う場合は、低い方を選び、その理由を書き留めます。これは重大度基準の保守的なタイブレークに倣うものです。

SLA テーブル（デフォルト — TEAM-TUNABLE と記された行はチームで調整可能）

優先度	意味	修正または緩和までの期限	調整可能か
P0	既知の悪用クラス、または深刻度が Critical	7 日	下限のみ — 厳格化は可能ですが、緩和はできません
P1	深刻度が High、または High から引き上げ	30 日	はい
P2	深刻度が Medium（Low から引き上げた場合を含む）	90 日	はい
P3	Low / Info	次の四半期 — または記録に一行の注記があれば、無期限でも問題ありません	はい

緩和を進捗として数えるルール。 悪用を実際に阻止する WAF ルール、Cloudflare Access のゲート、または設定変更は、緩和策として記録されていれば、SLA の計測を誠実に停止できます。条件は、制御策の名称、残存する経路、180 日以内のレビュー日が記載されていることです。これによって完了扱いに暗黙で切り替わることは決してありません。記録されていない緩和策は、全員がクローズ済みだと思っている一方で、SLA に違反した未解決の指摘事項です。

例外ワークフロー。 期限までに修正されなかったものは、いずれかになります。（a）記録済みの例外（P3 スキーマ：finding-id、reason、compensating-control、owner、必須の 180 日以内の expiry、review trigger）とし、対応する行に Fix Status: Risk-Accepted を関連付ける、または（b）月次レビューで SLA 違反を明示する。指摘事項がひそかに期限切れになる第三の状態はありません。

よくある誤検知

成熟度が実際より高く見える、プログラム監査の落とし穴：

1. ドキュメントが存在する ≠ プログラムが存在する。 実際の指摘事項に適用されたことのない SLA テーブルは、せいぜい PARTIAL です。テスト方法：未解決の指摘事項を一つ選び、その期限を追跡します。
2. スキャナーの出力 ≠ 追跡対象の指摘事項。 チャットに貼り付けた npm audit の出力は、指摘事項ファイルまたは相互参照行になるまで、ループに入ったことにはなりません。
3. 深刻度 ≠ 優先度。 キューが異なり期限も異なる、深刻度が同じ指摘事項があるのは、調整ルールが機能している証拠です。これを不整合として指摘するのは、設計の読み違いです。
4. CVSS のベーススコアだけで優先度を決める。 ベーススコアは到達可能性や悪用に関する情報を考慮しません。ベーススコアだけを使うと、Stage 3 が解決しようとしている問題が再発します。
5. 緩和済み ≠ 修正済み。 WAF ルールをひそかに恒久的な修正として扱い、記録もレビュー日も残さないことは、小規模チームで最もよくある暗黙の失敗です。
6. 例外 ≠ クローズ。 有効期限を記載した台帳の行がない Risk-Accepted は、仮装した未解決の指摘事項です。
7. 前回の監査の TARGET-PROFILE ≠ インベントリ。 実行後にリリースされたサービスは対象外です。鮮度を示す日付は、これを検知するためにあります。
8. 開発専用依存関係のノイズによる件数の水増し。 メトリクスを数える前に、SUPPLY のガイダンスに従ってスキャナーの出力を本番パスに絞り込みます。ただし、開発パスの項目も P3 として修正してください。
9. FVP を実行せずに Verified-Fixed を申告する。 マージ済みの回帰テストも再スキャンの出力もなければ、再オープンします。ステータス遷移ルールは単なる推奨事項ではありません。
10. 平均 MTTR が外れ値を覆い隠す。 平均と併せて MAX も報告してください。400 日かかった Critical が一件あると、健全な平均の中に埋もれてしまいます。
11. 静かな四半期が一度あった ≠ 傾向。 メトリクスは四半期をまたいで初めて意味を持ちます。単一時点のスナップショットから正当化できるのは、ベースラインの確立だけです。
12. トリアージ記録で EPSS/CVSS/悪用に関する主張を捏造する。 このスキルセットではどこでも禁止されており、キューの設定に使うここでは特に問題です。「参照せず」は常に許容されます。

参考資料

• NIST SP 800-40 パッチ管理出版物シリーズ（改訂番号は版によって変わっているため、最新の改訂版はCSRCカタログを参照してください）：https://csrc.nist.gov
• NIST Cybersecurity Framework — 前付けに記載されたIdentify/Respond機能のマッピング：https://www.nist.gov/cyberframework
• CISA Known Exploited Vulnerabilities（KEV）Catalog — 既知の悪用済み脆弱性を収録した権威あるリストです。最新の項目はhttps://www.cisa.govで確認してください
• FIRST Exploit Prediction Scoring System（EPSS）— 公開されている悪用確率スコア：https://www.first.org
• FIRST Common Vulnerability Scoring System（CVSS）仕様 — 検出結果レポートで使用する基本深刻度の用語体系：https://www.first.org
• オーケストレーター：SKILL-CODE.md Section 4のレジストリ（コードスラッグ、Phase 4の重複排除ルール、Phase 6の修正プロトコル）；SKILL-SERVER.md Section 3のレジストリ（SRVスラッグ、Phase 6の強化適用）
• 関連モジュール：SUPPLY skills/code/supply-chain/SKILL.md（依存関係スキャナーのコマンド一覧 — 参照のみで、ここでは重複して記載しません）、PATCH skills/server/updates-patching/SKILL.md、DETECT skills/operations/blue-team-detection/SKILL.md（P1～P4のページング基準：アラートの緊急度。このモジュールの修復優先度とは異なります）、IR skills/operations/incident-response/SKILL.md（追跡中の検出結果が実際のインシデントになった場合）、DR skills/server/backup-dr/SKILL.md（訓練頻度モデル）
• テンプレート：templates/finding-report.md（深刻度基準、ステータス、修正検証計画の必須要件、Fix Statusの遷移）；templates/target-profile.md（インベントリの初期作成用アーティファクト）
• ツール：tools/run-all-sweeps.sh、tools/sweeps/sweep-code-recon.sh、tools/sweeps/sweep-patching.sh、tools/README.mdのスイープ規約