課題と判断基準

セキュリティ点検の画面に「高」「重大」が並びます。開発者は次の配備を準備し、運用担当はパッチで停止しないか心配しています。点数順に並べても今日の対応は明確になりません。

推奨する順序は、実際の利用資産に該当するか確認し、悪用証拠・攻撃経路・業務影響を結び付けて対処することです。緊急リスクは露出削減と修正準備を並行し、根拠不足には確認担当と期限を付けます。不明だから低リスクとはしません。

整理の単位も脆弱性番号から「どの配備のどのリスクを誰が除くか」へ変えます。SSVCの運用者モデルも配備製品版と修正・緩和を結んだ個別インスタンスを判断単位とします。[1]

CVSS・EPSS・KEVは別の問いに答える

まずツールに並ぶ情報を区別します。

情報答える問い単独では分からないこと
CVSS基本値（CVSS-B）脆弱性自体の技術的深刻度は？自社サービスの露出と対処順
EPSS今後30日間に悪用活動が観測される可能性は？自社の侵害確率・被害規模
CISA KEV実攻撃での悪用が確認された脆弱性か？自社配備への影響・侵害成功
SSVC利害関係者の役割・環境でどの対応を選ぶか？全組織に共通する一つの点数

CVSSは基本値だけでリスク評価しないよう明記します。ただしCVSS全体に環境情報がないわけではありません。v4.0には脅威・環境指標があり、B・BT・BE・BTEを区別します。点数とともに版、指標群、ベクトルを残します。[2]

EPSSは観測可能な脆弱性集団への予測で、自社ネットワークや補完制御を反映した侵害確率ではありません。新規脆弱性は公開情報が少なく、未観測悪用もあり得ます。低値は安全判定ではなく、未提供値を0にしてもいけません。[3][4]

KEVとEPSSの違いは矛盾ではありません。KEVは実悪用の記録、EPSSは将来推定です。最近悪用が確認された項目を低EPSSだけで後回しにしません。一方、KEV掲載だけで自社侵害済みとも言えません。公開実証コードと実悪用観測も区別します。[1][3][5]

SSVCは信号を行動へ結ぶ判断体系です。運用者モデルは悪用状態、露出、攻撃自動化、人の安全、組織任務への影響を見ます。CISAの調整者向けと個別サービス運用者では役割が異なります。以下の記録表は参考にした実務案で、公式決定木の直接実装ではありません。[1][6]

CISAの米連邦機関向け期限を全韓国企業の共通義務へ置き換えないことも重要です。適用法令・契約・内部基準は別確認し、本記事の分類は運用提案として使います。[7]

サービスの仕組み

サービスの前段でリクエストを分類・防御 — リクエストと遮断記録から防御ルールを調整し、証明書とアクセス制御も管理します。

並べる前に実際の修正対象を確認する

次はコード・依存性点検の発見事項を修正作業へ変える案です。影響確認完了まで明白な緊急リスク緩和を待つ意味ではありません。

第一に発見位置と実配備を結びます。 リポジトリ名だけでなく環境・サービス・配備コミットまたはイメージID・実インストール版を残します。宣言版と稼働パッケージを照合し、直接・推移依存を分けます。修正マージだけで本番反映完了にしません。

第二に本番用と開発用を分けても開発用を一律除外しません。 Dependabotは対応エコシステムの開発依存をscope:developmentで絞れますが、分類表示は配備資産の安全証明ではありません。実行場所・入力・権限も確認します。[8] 信頼しない変更を扱うCIで開発専用ツールが配備権限を持つなら、開発用という理由で後回しにできません。これはツール格付けでなく構成リスク判断です。

第三に重複報告と異なる影響資産を分けます。 複数スキャナーの同じ脆弱性は一修正にまとめられますが、本番API、バッチ、別地域の配備まで一完了表示で消さないよう資産一覧を保持します。同じパッケージ名でも脆弱性と修正版が違えば別判断です。

第四に供給者勧告と対応可能性を照合します。 影響版、必要設定、修正版、サポート、回避策を原文で確認します。推移依存では上位更新も必要か見ます。パッチなし・サポート終了なら機能停止、依存置換、隔離を検討し、修正版なしを作業なしにしません。

現配備に非該当と確認したら除外根拠を残します。開発環境の残余リスク不在や全検知が誤検知という意味ではありません。OWASPも誤検知根拠・再評価、担当指定、例外の定期確認を別業務とします。[9]

到達しないことと未確認を分ける

攻撃経路では二問を分けます。信頼しない入力・利用者がサービスへ届くか。その入力が脆弱機能の悪用条件まで届くか。

前者はネットワーク・認証・業務フロー、後者はコード・設定・実行条件の問題です。内部網という位置だけで両方に否とは答えません。外部ファイルを内部バッチが扱うなら、直接接続の有無と別に処理経路を確認します。

ツールの状態定義も読みます。Semgrep Supply Chainはreachable、conditionally reachable、unreachable、no reachability analysisを分けます。解析で到達不能としたことと、解析自体がないことは異なります。[10]

課題には確認済み・条件付き・未確定などの証拠状態と根拠を残します。これは提案記録方式で、公式SSVC入力の代用ではありません。未確定には不足証拠・担当・期限が必要です。重大影響の可能性があれば確認と同時に露出削減も検討します。

到達不能判断には当時の配備・設定を結びます。コード・経路・認証・依存・配備構成の変更で再評価します。永久除外一覧ではなく、どの条件下でのみ有効かを記します。

緊急度と対処方法を別に決める

以下は編集上の運用分類で、国際標準の必須期限や点数式ではありません。どれだけ急ぐかと、どの方法でリスクを減らすかを分けます。

判断条件優先行動次の判断・完了条件
影響資産があり、最近の悪用証拠または重大経路を確認、現制御不足直ちに露出緩和と緊急修正準備を並行。進行被害の兆候は事故対応へ暫定制御を検証し、修正・置換・停止の持続策を決定
影響確認済みで修正版ありリスク相応の日程でパッチ対象配備で脆弱条件解消と正常機能を再検証
パッチなし・終了・反復欠陥で版変更では解決不能機能制限・隔離しながら置換・構造変更を計画暫定制御担当、有効期限、代替日程すべて必要
影響版・経路・制御効果が未確定確認を割当。大きな潜在影響には保守的緩和も検討期限に再判断し、無証拠の低優先度終了をしない
残余リスクを理解し延期理由があり、有效制御と承認権限あり期限付き受容を検討承認者・満了・再確認条件を記録し修正完了と分離

パッチのサービス影響は方法・配備順を変える根拠で、脆弱性リスク低下の根拠ではありません。変更リスクが高ければ事前検証、限定配備、復旧を準備します。暫定露出を十分減らせず残余も受容不能なら、対象機能停止まで選択肢に入れます。

暫定制御には範囲と検証が必要です。「WAF使用中」「内部網」だけでなく問題経路を何が止めるか確認します。OWASPは例外承認、補完制御、定期確認を管理に含めます。[9] 満了と早期再確認条件を加え、制御解除や新経路発見では定例を待たず再判断します。

同緊急度内では、一つの検証済み修正で複数高リスク資産を守れるか検討できます。ただし容易な低リスクだけを直して件数を減らす指標運用にしません。任意加重の点数より選択理由一文の方がレビューしやすくなります。

サービスの仕組み

監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。

資産の文脈を含む対処記録

以下は提案項目です。新製品より先に既存課題管理の欄から始められます。機密ログ・顧客情報・認証情報は貼らず、制限された証拠位置を参照します。

項目残す内容
識別と原文課題ID、CVEまたは勧告・内部発見ID、原文リンク、発見日
実影響資産サービス・環境・インスタンス、配備コミット・イメージ、実パッケージ版
文脈直接・推移依存、本番・開発・CI、重複報告と影響資産の関連
深刻度CVSS版・評価主体・点数・ベクトル・指標群。なければ未提供
悪用信号EPSS値・照会日・モデル、KEV掲載・確認日、最近の悪用報告。未照会と未掲載を区別
露出・経路アクセス主体、入力経路、必要権限・設定、到達証拠と未確定事項
業務影響データ・業務・顧客範囲、停止・権限侵害の結果
現制御範囲、効果確認時点と証拠、破られる条件
対処選択緩和・パッチ・構造変更・追加確認・受容と理由
実行・承認修正担当、検証担当、リスク承認者、変更影響、配備・復旧方法
期限・例外対処期限、確認期限、例外満了、早期再確認条件
終了・再発防止配備確認、再検証証拠、残存資産、暫定制御処理、再開条件

「EPSSが低いので保留」で終えません。「本番配備にパッケージがないと確認。分離文書ビルドの残課題は担当が定期更新で処理し、配備方式変更時に再確認」のように対象と根拠を明示します。

同じ一覧でも結論が異なる六つの設計例

すべて架空で、顧客脆弱性、実CVE評価、IXC成果ではありません。深刻度も説明用のスキャナー格付け仮定で、新計算CVSSではありません。

架空課題確認済み文脈と不足証拠対処判断
A. 高：本番ファイル処理ライブラリ最近の実悪用、外部入力の脆弱機能到達、機密ファイル、有效遮断策なし露出緩和と緊急パッチを並行。低EPSSを待機理由にしない
B. 重大：文書生成依存本番成果物に含まれず、別環境で信頼入力のみ、認証情報接続なしを確認本番影響なしの根拠を残し開発更新は別日程。環境変更で再確認
C. 高：内部バッチのパーサー外部顧客ファイルを受け、脆弱関数経路は未解析内部網を免除理由にしない。入力制限と経路確認担当・期限
D. CVE・EPSSなし：自社API権限欠陥許可環境で他テナントの機密データアクセス確認を仮定外部点数を待たず優先対応。詳細権限検証は別範囲
E. 高：開発専用解析ツール不信頼変更を扱うCIで脆弱条件成立、配備権限も存在開発依存で除外せず、権限・実行境界を制限して修正
F. 高：サポート終了拡張本番に必要だが不信頼入力を扱い修正版なし機能制限・停止し代替・構造変更。継続制限には担当・再確認・満了

BはAより格付けが高くても対応順が後になり得ます。Cは低リスクではなく証拠不足です。Dのように外部番号がない自社欠陥も、影響確認済みなら優先一覧に入れます。

Cの記録は追加確認中で、残る問いは外部ファイルが脆弱条件を満たす経路に入るかです。期限まで未確定のときの入力制限と承認責任も定めれば、待機一覧への埋没を防げます。

修正完了には配備と再検証を含める

PRマージと実資産のリスク除去を区別する終了基準を推奨します。コード・依存・設定が対象へ反映されたか、旧版のままのインスタンスがないかを確認します。

所有または明示許可のある環境で元の脆弱条件解消を検証し、正常機能・データ処理も回帰試験します。再スキャンはその一段階です。OWASP ASVSで検証要件を整理でき、確認した安定版は5.0.0です。引用時は版と識別子を併記します。参照だけで認証や全要件充足を主張しません。[11]

変更機能の範囲は変更別回帰テスト範囲決定ワークブックで整理できます。本記事の表は対処根拠、ワークブックは変更後試験範囲を記録します。

復旧も点検します。旧イメージへの復帰で再導入しないか、再配備のベースイメージとロックファイルにも修正があるか確認します。SSVCもロールバックや旧ソフト再配備での再流入を指摘します。[1]

終了は修正・再検証完了、資産非対象確認、期限付き受容、追加確認中に分けます。受容したリスクや未確認を修正実績に混ぜないためです。

指標もこの区分に従います。重要資産の未緩和リスク、影響確認時間、期限超過例外、未再検証修正、現配備の点検対象比率を合わせて見ます。対象除外や例外増による発見件数減少はリスク低下ではありません。

資産と担当が明確で変更量が少ないチームは既存課題管理とこの表で始められます。対象増に応じて自動収集・重複整理を検討し、重大経路の判断が難しい、検証責任が空いている場合は外部専門確認を検討します。次の会議では何を直し、どの攻撃経路が閉じ、どのリスクが誰の責任で残るかを説明できる必要があります。