INSIGHT
脆弱性の通知が来たら——自社への影響から修正の適用まで確かめる
自分たちへの影響をどう調べ、修正が本番へ届いたと確かめるか。
「利用中の部品に脆弱性があります」という通知が届いた。作成者は、最新版へ更新したと言う。しかし、その部品が公開中の仕組みに本当に入っているのか、影響する設定なのか、修正が本番へ届いたのか、業務が壊れずに動くのかは、更新の一言だけでは分かりません。
脆弱性対応は、通知を受け取ることでも、更新ボタンを押すことでも終わりません。
通知を、自社の一件へ変える
通知を受けたら、件名をそのまま回覧せず、次の情報を一件の記録にします。
- 問題になった製品・部品と影響する版
- 通知元と確認した日
- 自社で使っている場所、版、設定
- 外部公開、扱う情報、使える権限
- 現時点で分かる影響と、まだ分からないこと
- 調査、判断、更新、試験、本番反映の担当
依存部品は、アプリが機能するために利用するライブラリ、実行環境、外部サービスなどです。設計書に書かれた名前、開発時に取得した版、公開中の環境で実際に動く版が一致するとは限りません。通知の部品名だけで「該当する」「該当しない」を決めず、稼働中の構成と照合します。
SBOMは、ソフトウェアを構成する部品を一覧にする方法です。納品時の一覧があっても、更新後の稼働物や外部サービスまで自動的に表すとは限りません。一覧を、ソース、配備した版、設定、管理先と結び付けて使います。
「深刻」だけで、更新の順番を決めない
NISTのEnterprise Patch Management Planning は、更新を予防保守として捉え、把握、優先付け、適用、確認を組織の計画にする考え方を示しています。米国の政府機関が公表した一般的な文書で、AI専用でも、日本企業へすべての更新を即時に求めるものでもありません。
自社での優先順位は、通知の深刻度に加え、該当する版が稼働しているか、問題の機能を使っているか、外部から届くか、扱う情報と権限、代替・停止の可否、更新による業務影響で決めます。
影響がまだ分からない間は、担当者が判断する対応として、公開範囲を狭める、問題の機能を止める、強い操作を保留する、提供者へ確認するという選択があります。「調査中」を放置と同じにせず、期限と次の判断者を付けます。
OWASPのVulnerable Dependency Management Cheat Sheet は、検出された脆弱な第三者部品を状況に応じて扱う方法を提案し、万能の手順ではなく環境へ合わせる必要があると説明しています。スキャン結果の件数だけで、自社で悪用できることや事故が起きたことを確定する資料ではありません。
通知の深刻度と、自社で急ぐ理由を分けて記録します。
更新計画には、戻し方まで入れる
修正版がある場合も、すぐ本番へ入れるだけが選択ではありません。更新を担当する人が対象の版と入手先を確認し、許可された試験環境で更新します。ログイン、主要な一件、外部連携、出力形式、影響の大きい例外を試し、問題があれば前の構成へ戻せるかを確認します。
ただし、前の構成へ戻すと、対応中の脆弱性も再び残る場合があります。切戻しを安全な状態への復帰と決めつけず、戻している間に止める機能、限定する公開範囲、再適用の期限まで決めます。
修正版をすぐ適用できない場合は、問題の機能を止める、外部公開を狭める、権限を減らす、補助的な検知を置く、置換を計画するなど、採用する対応と残る影響を書きます。これらが十分かは、対象製品の公式情報と自社の構成で判断します。
更新によって別の不具合が出る可能性を理由に放置もしません。適用による影響と、適用しない間の影響を同じ記録で比べ、業務責任者が利用範囲を決めます。例外的に保留するなら、期限、対象、追加対応、見直す人を残します。
「修正済み」は、本番の版で確かめる
開発環境で更新しただけでは、本番の対応は終わりません。適用した部品の版、試した業務、結果、公開した時刻、配備先を記録します。再起動、自動配備、複数の稼働環境がある場合は、公開中のすべてが想定の版かを確かめます。
修正後は、問題となった条件に加え、通常の一件と以前に通った重要な例を試します。脆弱性への対応で、認証、連携、出力が壊れていないかを見るためです。試験後に、利用を再開する機能と、引き続き保留する範囲を業務側へ伝えます。
修正済みという報告は、変更したソースではなく、確認を終えた公開中の稼働物へ結び付けます。
通知経路と判断記録を、次回へ残す
通知が退職者のメールへ届く、契約アカウントを一人だけが管理する、委託先から更新状況が来ない。この状態では、判断の前に通知を失います。サービスと部品ごとに、通知窓口、管理アカウント、ソース・設定へのアクセス、緊急連絡先を確認します。
一件の記録には、対応した内容だけでなく、「該当しない」と判断した理由、分からず保留した点も残します。部品が存在しないのか、版を確認できないのか、問題の機能を使っていないのかで、次回の調査は変わります。
技術担当は構成と試験を説明し、業務責任者は停止・再開する範囲を決め、契約・調達担当は提供者との連絡を支えます。この記録を共有すれば、次の通知でも同じ確認を最初からやり直さずに済みます。
脆弱性の通知から修正後の本番確認まで、一件の記録でつなぐ
脆弱性の通知は、更新を急ぐだけの合図ではありません。いま何が動いているかを確認し、影響から優先順位を決め、修正を本番へ届け、業務が続くことを確かめる仕事の入口です。
通知が来たら、まず自分の成果物の名前と版、保守窓口を結び付けてください。分からない影響は推測せず、通知原文と利用条件を担当へ渡します。修正後も、どの公開版で何を試したかを確かめる。自分の確認と担当の作業を、一件の記録でつなげます。