パッチ管理：既知の脆弱性が未解決のまま残る理由

「既知」とは、誰が知っているということか

既知の脆弱性という表現には、重要な問いが抜けていることがあります。誰にとって既知なのでしょうか。研究チームが不具合を調査し、非公開で報告済みでも、企業にはまだ公開の通告が届いていない場合があります。その後、ベンダーが更新版を公開しても、影響を受ける環境ではまだ導入されていないかもしれません。それぞれ必要な対応が異なります。

企業のパッチ管理は、判断を追跡できる形でつなぐ作業と捉えられます。どのシステムが影響を受けるのか、誰が変更できるのか、どの修正が適切か、実際に有効になったのか。未解決の CVE の件数だけでは答えられません。深刻度が「重大」であることも、資産の把握や具体的なサービスとの照合の代わりにはなりません。

有用な進捗表示は、次に必要な証跡を示します。「ベンダーが調査中」「パッケージ承認済み」「稼働中のインスタンスは未検証」の方が、一括した「対応中」よりも次の行動を判断しやすくなります。

PHP2Shell：時系列から確認できること

PHP の事例には、こうした状態が複数含まれています。以下では、早期の兆候、非公開での調整、公開リリースを分けて示します。Calif の日付は同社が後から公表した経緯に基づきます。8 月 11 日の報告は PHP Foundation も記録しています。

Calif の最初の報告である 8 月 11 日から、修正版が公開された 10 月 21 日までは、開始日を含めない日付差で 71 暦日です。この数字は、何も行われなかった期間や、公知になってからの 71 日間を表すものではありません。特定のホスティング事業者や顧客が、いつ修正を有効にしたかも分かりません。 [1] [2] [3] [4]

PHP2Shell：修正版とホスティング環境の確認項目

表は左右にスクロールできます。

脆弱性の確認後、すぐに更新版を出せない理由

PHP Foundation は、互換性、性能、新たな停止リスク、拡張機能への変更といった技術上のトレードオフを挙げています。専門人材の稼働余力にも制約があり、意思決定の仕組みについては自ら構造的な不全と評価し、改革を説明しています。情報が予定より早く広まったため、公開は一日前倒しされました。その時点でもディストリビューターは、インストール可能なパッケージを準備していました。

これは、遅延を一律に正当化する説明ではありません。問題を上位の担当者に引き継ぐ際には、何が不足しているのかを特定する必要があります。確実な再現、技術上の判断、検証、パッケージ提供者への引き継ぎのどこでしょうか。未完了の段階ごとに、担当と次の確認日が必要です。すべてを「パッチ待ち」として扱うと、停滞している箇所が見えなくなります。 [1]

二つの研究が示すことと、その限界

パッチ適用に関する研究は、現場の作業を詳しく理解する助けになります。ただし、現在世界中でどれほどの企業が無防備なのかを示すものではありません。数値には、論文の発表年、調査期間、何を数えたのかを併記する必要があります。 [5] [6]

表は左右にスクロールできます。

自社の手順を、引き継ぎの箇所から点検する

私たちの作業整理は、更新カタログではなく、対象システムから始めます。通告が具体的なサービスと担当する役割に結び付いて、初めて実行可能な作業になります。情報が足りなければ、影響の有無は未確認のままです。安易に低リスクへと扱いを変えるべきではありません。

続いて、目標とする状態、機能確認、復旧手順を合意します。修正をまだ適用できない場合、暫定措置には理由と見直し日を記録します。確認されないまま恒久対策になることは避けなければなりません。変更後は、必要な再起動やコンテナーの再展開も含め、実際に動いているインスタンスを検証します。

NIST は、パッチ適用を予防保全として位置付けています。ガイドでは、インストールと有効性の検証に加え、復元やリセット後も確認を続けるよう求めています。後からバックアップを復元した際に、古い状態へ戻る可能性があるためです。 [7]

ホスティング、社内 IT、アプリケーションの責任を分ける

「クラウド上にある」という説明だけでは、担当は決まりません。具体例として、AWS は EC2 について、自社のインフラと、顧客が管理するゲスト OS やインストール済みアプリケーションを区別しています。より抽象化されたサービスでは責任分担が異なります。この例を、確認せずに自社のホスティング契約へ当てはめないでください。

サービスごとに、誰がベンダー通告を評価し、基盤システムを保守し、アプリケーションをテストし、完了を確認するのかを明確にします。業務責任者は、維持すべき機能の判断に参加します。技術運用者は、変更内容とその証跡を示します。作業を供給元が担当する場合は、個別の回答を記録に添付します。一般的な稼働状況ページだけでは、必要な点を確認できないことがあります。 [8]

次の実案件で使える、未記入の管理表

パッチ管理表は Cyberkern 独自の作業補助資料であり、上記の研究で有効性が検証された手順ではありません。一行で、システム、ベンダー通告、担当、対処、完了の証跡を結び付けます。個人の連絡先ではなく、役割やチーム名を使ってください。パスワード、鍵、機密のログ内容は記入しません。

CSV に入っているのは列見出しだけです。完了した作業だけでなく、未解決事項も同じように記録します。インストールを予定した段階では完了にしません。ロールバック後は保護状態を再評価し、以前の検証結果を、確認せずに現在の証跡として扱わないようにします。

未記入のパッチ管理表を CSV でダウンロード

• 対象システムと影響の有無を、追跡可能な根拠とともに記録した。
• 技術上の担当役割または供給元と、意思決定の経路を明確にした。
• 適用するパッケージまたは設定変更と、復旧手順を決めた。
• 暫定措置について、期限と次回の見直しを記録した。
• 変更後の稼働状態と、重要な業務機能を確認した。
• 完了の証跡を添付した。または、未解決事項を次の対応とともに残した。

次の進捗確認で問うべきこと

終了したチケットの件数だけを聞くのではなく、外部から到達可能なシステムのうち影響の有無が未確認のもの、見直し期限を過ぎた暫定措置、有効な修正の証跡がまだない箇所を確認します。担当の確定、修正の有効化、最終確認までの時間を分けて記録すれば、どの引き継ぎで作業が止まっているかを把握できます。

外部セキュリティ評価は、外から確認できるシステムや異常の整理に役立ちます。一方、内部のパッケージ状態、責任の所在、過去に侵害された可能性の判断には追加の証拠が必要です。更新の成功は、インシデント調査の代わりにはなりません。初回のお問い合わせでは、確認したいサービスとご相談内容をお知らせください。機密性の高い運用資料は、後から合意した経路で受け渡せます。

公開状況と緊急性から脆弱性対応の優先順位を決める

外部の攻撃対象領域を把握する