CISA「BOD 26-04」とは？日本企業が知るべき脆弱性対策と4つの判断基準
脆弱性の報告件数が増加する中、2026年6月10日、米国CISAは、実際のリスクに基づいて脆弱性対応を優先する「BOD 26-04」を公表しました。
直接の対象は米国連邦政府機関ですが、その考え方は日本企業の脆弱性管理にも活用できます。
本記事では、BOD 26-04の4つの判断基準や対応期限、BOD 22-01との違いに加え、日本企業への影響や国内ガイドラインとの共通点を解説します。
国内唯一のISMAP登録済
SBOM・脆弱性管理ツール
脆弱性・EOL・OSSライセンスを一元管理
対応の優先順位を自動判定
クラウド・オンプレ（閉域網）環境に対応
目次[非表示]
- 1.BOD 26-04とは
- 2.BOD 22-01から何が変わったのか
- 3.BOD 26-04が定める4つの判断基準
- 3.1.① Asset Exposure——資産が外部公開されているか
- 3.2.② KEV Status——CISA KEVに掲載されているか
- 3.3.③ Exploit Automation——攻撃を自動化できるか
- 3.4.④ Technical Impact——悪用後に得られる制御の範囲
- 3.5.SSVCとBOD 26-04の関係
- 4.BOD 26-04の対応期限
- 4.1.最短3日が適用されるケース
- 4.2.対応期限は動的に変わる
- 4.3.「次回システム更新時」の意味
- 5.フォレンジックトリアージが必要な理由
- 5.1.CISAが示す6つのステップ
- 6.BOD 26-04は日本企業にも関係するのか
- 6.1.原則として日本企業への直接的な義務はない
- 6.2.米国政府関連の事業者は契約範囲を確認する
- 6.3.一般企業にも参考になる理由
- 6.4.日本でもリスクベースの脆弱性管理はすでに求められている
- 6.5.今後、日本のガイドラインへ具体化される可能性
- 7.リスクベースの脆弱性管理をyamoryで支援
BOD 26-04とは
BOD 26-04は、リスクに応じて脆弱性の修正を優先し、必要に応じて緩和策やフォレンジックトリアージを組み合わせる指令です。脆弱性の技術的な深刻度だけではなく、実際の攻撃リスクと資産の状況を組み合わせて対応期限を決めます。
項目 | 内容 |
|---|---|
正式名称 | Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk |
公表日 | 2026年6月10日 |
発行主体 | 米国CISA |
直接の適用対象 | Federal Civilian Executive Branch（FCEB）機関（※） |
主な判断基準 | 外部公開、CISA KEV、攻撃自動化、技術的影響 |
対応期限 | 3日、14日、60日、次回システム更新時 |
BOD 26-04は単にパッチ適用を急がせる指令ではありません。自社の資産と脆弱性情報を結び付け、限られた対応能力を高リスクの対象へ集中させるための枠組みです。
（※）FCEB機関とは：Federal Civilian Executive Branch agencies（連邦政府の文民行政機関）の略で、米国連邦政府の行政機関のうち、国防総省や軍、情報機関などを除いた文民系の省庁・機関（国土安全保障省、財務省、商務省など）を指します。
CISAが2026年6月に公表した拘束的運用指令
BODは「Binding Operational Directive」の略称です。米国の連邦行政機関に対して、連邦政府の情報や情報システムを保護するための措置を求める拘束的な指令を指します。
BOD 26-04では、対象となる資産をハードウェアまたはソフトウェアと定義しています。対象範囲には、連邦政府機関が自ら運用するシステムだけでなく、第三者が機関に代わって運用し、連邦政府の情報を扱うシステムも含まれます。
第三者環境やクラウドサービスで連邦情報システムを運用している場合も、FCEB機関は対象システムのインベントリを維持し、継続的に状況を確認しなければなりません。
ただし、契約上の定めがない限り、すべての委託先にBOD 26-04が直接適用されるわけではありません。FCEB機関は、指令を実施するために契約変更が必要かを契約担当者と確認することになります。
BOD 26-04が公表された背景
BOD 26-04の背景には、脆弱性の公表から悪用までの時間が短くなり、従来型の一律なパッチ管理では対応が難しくなっている状況があります。
CISAは、攻撃者が未修正の脆弱性を悪用していることに加え、AIの利用によって、パッチ公開から悪用までに防御側へ与えられる時間がさらに短くなる可能性を指摘しています。
一方、組織が利用するソフトウェアやクラウドサービスは増加し、日々公表される脆弱性も増えています。すべての脆弱性を同じ緊急度で扱うと、次の問題が生じます。
- 対応件数が担当者や開発部門の処理能力を超える
- 本当に危険な脆弱性への着手が遅れる
- 外部公開サーバーと隔離された検証環境が同じ優先度になる
- パッチ適用によるシステム停止リスクを適切に考慮できない
- 対応を延期した理由を監査や経営層へ説明しにくい
BOD 26-04は、すべてを一律に急ぐのではなく、現実の攻撃につながる可能性が高い脆弱性から処理する考え方を明確にしています。
3段階で実装を進める
BOD 26-04では、FCEB機関に段階的な対応を求めています。
フェーズ | 期限 | 主な内容 |
|---|---|---|
Phase I | 公表後ただちに | 脆弱性管理ポリシーの見直し、役割・責任、検証、報告手順の整備 |
Phase II | 公表から60日以内 | CVEデータベースとKEVを利用した継続的な脆弱性対応プロセスの整備 |
Phase III | 公表から180日以内 | 期限表に基づく修正、外部から到達可能な資産の継続的な特定・タグ付け |
Phase IIIの期限は2026年12月7日です。FedRAMPもこれに合わせ、Vulnerability Detection and ResponseおよびVulnerability Evaluation and Reportingルールを、2026年12月7日から対象クラウドサービスへ義務付ける方針を示しています。
重要なのは、パッチ適用だけではありません。誰が判断し、誰が修正し、どのように進捗を追跡し、例外を承認するかまで、運用として整備する必要があります。
BOD 22-01から何が変わったのか
BOD 22-01がKEVに掲載された脆弱性の修正を中心としていたのに対し、BOD 26-04は資産の公開状況などを加え、脆弱性と資産の組み合わせごとに期限を決めます。
BOD 22-01は、実際の攻撃で悪用されている脆弱性をまとめたCISA Known Exploited Vulnerabilities（KEV）カタログを基礎とし、掲載された脆弱性を期限内に修正するよう求める指令でした。
BOD 26-04はBOD 22-01とBOD 19-02を失効させ、両者の考え方を発展・統合しています。
比較項目 | BOD 22-01 | BOD 26-04 |
|---|---|---|
優先順位の中心 | KEVへの掲載 | 4つの判断基準 |
外部公開状況 | 中核的な判定要素ではない | 資産ごとの明示的な判定要素 |
攻撃の自動化 | 独立した中核要素ではない | Automatableとして判定 |
技術的影響 | 独立した中核要素ではない | Partial／Total Controlで判定 |
対応期限 | KEV中心の期限 | 条件に応じて3日、14日、60日など |
低リスクの脆弱性 | KEV掲載対象は期限内対応 | 条件によって次回更新時まで延期可能 |
侵害有無の調査 | 中心的な要件ではない | 最高リスクのケースで明示的に要求 |
期限の考え方 | KEVの期限を確認 | 資産・脆弱性の状況に応じて動的に変化 |
BOD 26-04でもKEVの重要性は変わりません。ただし、KEVへの掲載だけで優先順位を決めるのではなく、資産の外部公開状況、攻撃の自動化可能性、技術的影響と組み合わせます。
例えば、同じKEV掲載脆弱性でも、インターネットから到達可能な本番サーバーと、外部から到達できない検証環境では、実際の攻撃リスクが異なります。BOD 26-04は、この違いを期限に反映します。
BOD 26-04が定める4つの判断基準
BOD 26-04では、「外部公開」「CISA KEV」「攻撃の自動化」「技術的影響」の4要素を組み合わせて、脆弱性への対応期限を決めます。
① Asset Exposure——資産が外部公開されているか
Publicly Exposedは、対象資産がインターネットなどの公開ネットワークを通じて、認証されていない、または信頼されていない主体からアクセスできる状態を指します。
判断するときは、サーバーが社内設置かクラウド上かだけを見るのではありません。物理的・論理的な場所にかかわらず、外部から到達可能かを確認します。
CISAは、CDM、Cyber Hygiene、脆弱性スキャナー、クラウドのタグなど、複数の手段を用いた確認を想定しています。いずれかの方法で外部公開と判定された場合は、原則として「Yes」と扱います。
実務では、次の情報を資産ごとに管理する必要があります。
- 本番環境か開発環境か
- 公開IPアドレスを持つか
- インターネットから到達できるポートがあるか
- 認証前にアクセスできる機能があるか
- VPNやアクセス制御の内側にあるか
- クラウドのセキュリティグループやファイアウォールの設定
- 資産の管理部門と担当者
公開状況は固定ではありません。クラウド設定、ルーティング、ファイアウォールなどが変更されると、同じ資産でも判断が変わります。
② KEV Status——CISA KEVに掲載されているか
CISA KEVは、実際の攻撃で悪用されている証拠をCISAが確認した脆弱性のカタログです。
CVSSは脆弱性の技術的な深刻度を表しますが、スコアが高いことと、現実に悪用されていることは同じではありません。一方、CVSSがCriticalではない脆弱性でも、攻撃者が悪用している場合があります。
そのため、KEVへの掲載状況は、脆弱性の現実的な緊急度を判断する重要な材料です。
BOD 26-04では、KEVが単独の優先順位ではなく、4つの判断基準の一つとして位置付けられています。外部公開や技術的影響などと組み合わせることで、同じKEVでも資産ごとの対応期限が変わります。
KEVの掲載基準や脆弱性管理での活用方法は、「既知の悪用された脆弱性一覧 CISA KEVカタログ」で詳しく解説しています。
③ Exploit Automation——攻撃を自動化できるか
Automatableは、攻撃者が脆弱性を悪用するまでの手順を自動化できるかを示します。
CISAは、公開されたPoCコードによってリモートコード実行を安定して再現できる場合などを、自動化可能と判断するための一つの目安に挙げています。
ただし、PoCが公開されているだけで、すべての脆弱性が自動化可能になるわけではありません。次のような条件も確認する必要があります。
- 攻撃に人手による複雑な操作が必要か
- 対象ごとに大量の調整が必要か
- 認証情報や内部情報が必要か
- 複数段階の攻撃を安定して自動化できるか
- 公開コードが実際に動作するか
- リモートから大量の対象へ適用できるか
自動化可能な攻撃は、攻撃者が短時間で多数の対象を探索・攻撃できるため、対応の緊急性が高くなります。
④ Technical Impact——悪用後に得られる制御の範囲
Technical Impactは、脆弱性の悪用後に、攻撃者が対象資産をどこまで制御できるかを示します。BOD 26-04では「Partial Control」と「Total Control」に分類します。
Total Controlの例は次のとおりです。
- 任意のソフトウェアをインストール・実行できる
- 対象コンポーネントが実行可能なすべての処理を操作できる
- 管理者またはroot権限を取得できる
- 対象を完全に制御できる認証情報が漏えいする
Partial Controlの例には、次のようなものがあります。
- 限定的な情報だけが漏えいする
- 対象の一部機能だけを操作できる
- サービス停止を引き起こす
- 特定条件下でのみ限定的な影響が生じる
Technical ImpactはCVSSの深刻度と共通する部分がありますが、BOD 26-04では、外部公開やKEVなど他の要素と合わせて期限を決めます。
SSVCとBOD 26-04の関係
OD 26-04の期限表は、Stakeholder-Specific Vulnerability Categorization（SSVC）の考え方を参考にしています。
SSVCは、脆弱性を単一のスコアで表すのではなく、複数の条件を決定木で評価し、取るべき対応を導く手法です。
ただし、一般的なSSVCの決定木とBOD 26-04の4変数モデルは同一ではありません。BOD 26-04は、FCEB機関の修正期限を決めるために、KEV、外部公開、攻撃自動化、技術的影響を利用しています。
SSVCの仕組みやCVSSとの違いは、「SSVCとは？CVSSに代わる脆弱性評価の手法でスピーディーな判断を実現」をご覧ください。
BOD 26-04の対応期限
BOD 26-04の期限は、3日、14日、60日、次回システム更新時の4段階です。すべての脆弱性が3日以内の対応になるわけではありません。
以下は、CISAの期限表を日本語で整理したものです。
※対応期限日数は営業日ではなく、暦日（土日・祝日を含む）です。
外部公開 | KEV | 自動化可能 | 技術的影響 | 対応期限 |
|---|---|---|---|---|
Yes | Yes | Yes | Total | 3日＋フォレンジックトリアージ |
Yes | Yes | Yes | Partial | 3日 |
Yes | Yes | No | Total | 3日＋フォレンジックトリアージ |
Yes | Yes | No | Partial | 14日 |
Yes | No | Yes | Total | 3日 |
Yes | No | Yes | Partial | 14日 |
Yes | No | No | Total | 14日 |
Yes | No | No | Partial | 60日 |
No | Yes | Yes | Total | 3日＋フォレンジックトリアージ |
No | Yes | Yes | Partial | 14日 |
No | Yes | No | Total | 14日 |
No | Yes | No | Partial | 14日 |
No | No | Yes | Total | 60日 |
No | No | Yes | Partial | 60日 |
No | No | No | Total | 次回システム更新時 |
No | No | No | Partial | 次回システム更新時 |
最短3日が適用されるケース
対応期限が3日となるのは、複数の高リスク条件が重なったケースです。
なかでもフォレンジックトリアージが必要になるのは、次の3条件を満たす組み合わせです。
- KEVに掲載されている
- Technical ImpactがTotal Control
- 外部公開または攻撃自動化の少なくとも一方がYes
外部公開され、KEVに掲載され、自動化可能で、Total Controlとなる脆弱性は、最も分かりやすい最高リスクのケースです。
一方、KEVに掲載されていなくても、外部公開され、攻撃が自動化可能で、Total Controlとなる場合は3日以内の修正が必要です。
対応期限は動的に変わる
BOD 26-04の期限は、最初の判定後に固定されるわけではありません。
例えば、対象システムをインターネットから切り離すと、Publicly Exposedが「Yes」から「No」に変わります。これは有効な緩和策となり、その後に必要な修正期限が変わる場合があります。
反対に、当初KEVに掲載されていなかった脆弱性が後日KEVへ追加されると、期限が短くなる可能性があります。
期限の起点は、原則として次のいずれか早い時点です。
- CISAが脆弱性をKEVへ追加した時点
- 機関が資産上の脆弱性を特定し、CDMのダッシュボードへ反映した時点
このため、資産や脆弱性を月次・四半期ごとに確認するだけでは不十分です。KEVの更新や外部公開状況の変化を継続的に把握する必要があります。
「次回システム更新時」の意味
「Fix on system upgrade」に分類された脆弱性は、直ちに優先対応する必要はなく、対象システムを次に計画的にメジャーアップグレードまたは再構築するときに修正します。
ただし、「対応不要」という意味ではありません。
管理対象から削除せず、次回更新の計画に紐付けて追跡することが重要です。また、外部公開された、KEVに追加されたなど、条件が変わった場合は再評価します
フォレンジックトリアージが必要な理由
パッチは脆弱性を修正しますが、すでに侵入した攻撃者や永続化された不正な設定まで自動的に排除するものではありません。
KEVに掲載され、Total Controlにつながる高リスクの脆弱性では、パッチ適用前から攻撃者に悪用されていた可能性があります。
パッチを適用して新たな侵入経路を閉じても、次の状態が残っていれば侵害は継続します。
- 不正な管理者アカウントが追加されている
- Webシェルやマルウェアが設置されている
- 認証情報が窃取されている
- 別のサーバーへ横展開されている
- 永続化のための設定が追加されている
- 機密情報が持ち出されている
そのため、BOD 26-04の最高リスク区分では、修正または緩和とともに、対象資産が侵害されていないかを確認するフォレンジックトリアージが求められます。
CISAが示す6つのステップ
CISAの実装ガイダンスは、フォレンジックトリアージを次の6段階で整理しています。
- スコーピング
- 対象となるCVE、資産、システム、サービスを特定する
- 必要な対応チームを招集する
- 侵害された可能性のある環境に依存しない連絡手段を用意する
- 証拠の保全・収集
- メモリ、キャッシュ、通信中のデータなど、消失しやすい情報を優先して取得する
- 対象機器、取得日時、取得者を記録する
- 重要パッチの適用と安定化
- 必要な証拠を確保した後、利用可能な重要パッチを適用する
- パッチによる業務影響がある場合は、関係部門とシステムを安定化する
- 封じ込め
- 影響を受けた、または受けた可能性のあるシステムを隔離する
- 証拠収集やパッチ適用と連携して進める
- トリアージ分析
- 不正アクセス、攻撃者の存在、横展開、永続化、データ持ち出しを確認する
- IOCを検証し、他の環境にも存在しないか確認する
- エスカレーション判断
- 調査結果と対応経緯をレポートにまとめる
- 侵害なし、侵害あり、侵害の疑いありに分類する
- 必要に応じて本格的なインシデントレスポンスへ移行する
CISAは、最初の2時間から72時間までの推奨タイムラインも示しています。ただし、これらはベストプラクティスとしての目安です。BOD 26-04上の要件は、個々の推奨時間を厳密に守ることではなく、適切なフォレンジックトリアージを実施することです。
また、パッチ適用や再起動によって、侵害の痕跡が失われる可能性があるため、可能な場合は証拠を収集する前に対象システムを変更・修正しないよう注意が必要です。
BOD 26-04は日本企業にも関係するのか
日本企業一般は、BOD 26-04の直接的な拘束対象ではありません。ただし、米国政府関連の事業やクラウドサービスに関係する企業は、契約と対象システムを確認する必要があります。
原則として日本企業への直接的な義務はない
BOD 26-04の直接的な適用対象はFCEB機関です。そのため、日本国内で事業を行う一般企業が、BOD 26-04を理由に一律で法的な対応義務を負うわけではありません。
米国政府関連の事業者は契約範囲を確認する
日本企業でも、次のような場合は影響を確認する必要があります。
- FCEB機関向けにシステムを提供している
- FCEB機関の情報を処理・保存・送信する
- FedRAMP認定クラウドサービスを提供している
- 米国政府機関のシステム運用を受託している
- 契約上、CISAの指令やFedRAMPルールへの対応が求められている
BOD 26-04は、契約上の定めがないすべての委託先へ自動的に適用されるわけではありません。ただし、FCEB機関は指令の実施に必要な契約変更を検討します。
FedRAMP認定を取得または維持するクラウドサービスについては、FedRAMPが2026年12月7日から新しい脆弱性検知・対応ルールを義務付ける方針を示しています。該当する企業は、個別の契約、認証範囲、共有責任モデルを確認してください。
一般企業にも参考になる理由
直接の義務がない企業でも、BOD 26-04の考え方は脆弱性管理の改善に役立ちます。
従来、CVSSの基本値が一定以上なら一律に緊急対応とする組織もありました。しかし、実際のリスクは、脆弱性そのものの深刻度だけでは決まりません。
- インターネット（外部）から攻撃できるか
- 現実の攻撃で悪用されているか
- 攻撃を大規模に自動化できるか
- 対象資産が重要な業務を支えているか
これらを踏まえて優先順位を決めれば、限られた人員を高リスクの脆弱性へ集中できます。また、対応を延期する場合も、判断根拠、期限、承認者を記録しやすくなります。
日本でもリスクベースの脆弱性管理はすでに求められている
日本の公的文書でも、リスクベースの脆弱性管理はすでに示されています。
金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」は、システムの重要度、リスク、脆弱性の深刻度に応じた対応期限の設定を求めています。
金融庁・日本銀行が2026年5月に公表した要請は、重要業務を支える外部公開ITシステムを優先対象としています。
また、経済産業省の「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」は、KEVやEPSSを活用した優先順位付けが効果的であると明記しています。
今後、日本のガイドラインへ具体化される可能性
日本政府がBOD 26-04をそのまま導入するかは不明です。しかし、国内の政策文書はすでに、KEVやEPSSなどの脅威情報、資産・サービスの重要度、外部公開状況、攻撃成立の可能性を利用して脆弱性対応を優先する方向へ進んでいます。
また、政府の重要インフラ政策では、国際標準や海外の指針のうち、日本でも参考にすべきものを適宜取り入れる方向性が示されています。
そのため、重要インフラ、金融、製造、政府調達、サプライチェーンなどの分野を中心に、リスクベースの脆弱性管理が、より具体的な評価基準や対応期限へ発展する可能性があります。
リスクベースの脆弱性管理をyamoryで支援
脆弱性管理クラウド「yamory」は、オンプレミス（閉域網）・クラウド環境の全レイヤーに潜む脆弱性を可視化し、対応の優先度付けまでを自動化する国産のクラウドサービスです。
脆弱性の他にも、EOL、OSSライセンス違反、クラウドの設定不備（CSPM）を一元管理でき、組織単位で対応の進捗管理を支援します。
幅広いレイヤーのITリスクを一元管理
クラウド・オンプレミス環境に問わず、インフラからアプリレイヤー内のITリスク（脆弱性・EOL・OSSライセンスリスク・クラウド設定不備）を一元管理することができます。
対応の優先順位を自動判別
CISA KEVカタログを参照し、危険度、外部からのアクセス可否、攻撃手段の公開状況などを用いたオートトリアージ機能（特許技術）によって、対応の優先順位を自動判定します。
これにより、担当者が脆弱性を一件ずつ手作業で調査し、「どれから対応すべきか」を判断する負担を軽減できます。
分かりやすいダッシュボードで結果を可視化
オートトリアージ機能で優先度付けを行った結果は、ダッシュボードで可視化。
組織を横断して検出件数を把握でき、迅速かつ正確な意思決定を下せるようになります。
脆弱性管理クラウドyamoryで、効率的な脆弱性管理を実現しませんか？
yamoryは、政府情報システムのためのセキュリティ評価制度『ISMAP』において、国産の脆弱性・SBOM管理サービスとして初めて登録されたクラウドサービスです。
経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」にて、唯一の国産ツールとしても紹介され、数多くの企業様に導入いただいております。
フロンティアAIの登場によってリスクベースの脆弱性管理をお求めの方、yamoryを使って、リスクベースの脆弱性管理を始めませんか？
以下より、yamoryのサービス紹介資料をダウンロードできますので、ぜひご覧ください。
脆弱性管理クラウドyamoryの詳しい機能をご紹介しています。
脆弱性・EOL・OSSライセンスを一元管理
クラウド・オンプレ（閉域網）環境に対応
対応の優先順位を自動判定
■参考文献
BOD 26-04に関するFAQ
Q. BOD 26-04とは何ですか？
A. BOD 26-04は、CISAがFCEB機関に対して発出した、リスクに応じて脆弱性の修正を優先し、必要に応じて緩和策やフォレンジックトリアージを組み合わせる拘束的運用指令です。2026年6月10日に公表され、BOD 19-02とBOD 22-01を置き換えました。
Q. BOD 26-04は日本企業にも適用されますか？
A. 日本企業一般は、BOD 26-04の直接的な拘束対象ではありません。ただし、FCEB機関の情報システムやFedRAMP認定クラウドサービスに関係する企業は、契約や認証範囲を確認する必要があります。また、一般企業もリスクベースの脆弱性管理モデルとして参考にできます。
Q. BOD 26-04とBOD 22-01の違いは何ですか？
A. BOD 22-01は、CISA KEVに掲載された脆弱性の修正を中心とする指令でした。BOD 26-04では、KEVに加えて、外部公開、攻撃自動化、技術的影響を評価し、資産と脆弱性の組み合わせごとに対応期限を決めます。
Q. すべての脆弱性を3日以内に修正する必要がありますか？
A. いいえ。対応期限は4つの判断基準により、3日、14日、60日、次回システム更新時に分かれます。最短3日となるのは、複数の高リスク条件が重なるケースです。
Q. BOD 26-04ではCVSSを使わないのですか？
A. CVSSが不要になったわけではありません。CVSSは脆弱性の技術的な深刻度を理解する材料として利用できます。ただし、CVSSの基本値だけで対応優先度を決めず、悪用状況や資産環境なども合わせて判断することが重要です。
Q. CISA KEVとは何ですか？
A. CISA KEVは、実際の攻撃で悪用されている証拠をCISAが確認した脆弱性のカタログです。BOD 26-04では、対応期限を決める4つの判断基準の一つとして利用されます。
Q. BOD 26-04でフォレンジックトリアージが指定されたケースでは、なぜパッチ適用前の証拠保全が重要ですか？
A. パッチを適用しても、すでに作成された不正アカウント、窃取された認証情報、マルウェア、横展開などは残る可能性があるためです。また、パッチ適用や再起動によって侵害の証拠が失われる場合があるため、可能な場合は必要な証拠を収集してから修正します。なお、フォレンジックトリアージはすべての脆弱性で求められるのではなく、CISAの期限表で指定された高リスクの組み合わせが対象です。
