Drupalの脆弱性情報、コアと追加モジュールを分けて確認する

Drupalの脆弱性情報、コアと追加モジュールを分けて確認する。この記事は2026年10月21日に確認できた公式情報を起点に、Drupalの脆弱性情報、コアと追加モジュールを分けて確認するという疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

コア脆弱性の把握と影響範囲の特定

脆弱性概要と対象バージョンの確認

まずは、JPCERT/CC の週報と Drupal の公式セキュリティアドバイザリに記載されている脆弱性情報が、実際に自社で利用している Drupal 本体や導入しているモジュールに該当するかどうかを確認します。

そのために必要なのは、現在稼働中の Drupal のバージョンと、アドバイザリで示されている対象バージョンの一覧を照らし合わせることです。照合の結果、対象外と判断できる場合はその旨を、対象になる可能性がある場合は次の対策検討に進む旨を担当者に伝えてください。

担当者に確認すべき具体的な質問は次のとおりです。
・現在運用している Drupal 本体のバージョンは何ですか。
・使用している主要なモジュールのバージョンと、脆弱性情報に記載されている対象モジュールが一致しているかどうか。
・バージョン情報の根拠となる記録（設定ファイルや管理画面の情報など）はどこに保管されていますか。

これらの情報が揃えば、対象か否かの判断根拠が明確になり、次の対応ステップを検討する際の資料として活用できます。

影響を受ける機能と業務リスクの評価

対象バージョンが判明したら、脆弱性が影響する具体的機能を公式情報から抽出します。たとえば認証処理や入力バリデーション、ファイルアップロードといった、外部から直接操作されるポイントが多い場合は、情報漏洩や改ざんのリスクが高まります。

業務リスクは、影響範囲（内部利用のみか外部公開か）と重要度（顧客データ取り扱いの有無）で定量化し、リスクマトリックスに落とし込みます。リスクが中以上と評価された項目は、早急なパッチ適用や代替策の検討対象として優先順位を付けます。

担当者への確認項目と報告フォーマット

システム管理者に依頼する際は、以下の項目をチェックリスト化したテンプレートを用意します。① 現行バージョンとパッチ適用状況、② 脆弱性対象機能の有無、③ 本番とは別の検証環境でのテスト結果、④ 本番適用予定日。報告は、表形式の文書（PDF または Excel）で提出させ、変更履歴やテストログの添付を求めます。

提出された情報は、リスク評価シートに転記し、経営層への報告資料に組み込むことで、意思決定に必要な根拠を明確にします。

追加モジュールの脆弱性チェック手順

インストールモジュール一覧の抽出方法

Drupal の管理画面からインストール済みモジュールを確認できることは事実ですが、コマンドラインで取得した情報をそのまま脆弱性データベースと照合できるかは、実際に使用している環境やデータベースの形式によって異なります。

したがって、まずは社内で利用している脆弱性情報の取得方法や更新頻度を確認し、CSV 形式のデータがそのまま比較対象になるかどうかを担当者に確認してください。

次に、抽出したモジュール情報に機密情報が含まれないようにするための具体的な手順を確認します。たとえば、モジュール名やバージョン以外に不要な設定項目が出力されていないか、出力結果をどのように加工して共有資料にまとめるかを担当者に質問します。

「出力結果に個人情報や内部コードが混ざっていないか」「共有用の表に必要な項目は何か」など、確認すべきポイントを整理して依頼すると、不要な情報漏えいを防ぎつつ、脆弱性対応に必要な情報だけを正確に把握できます。

脆弱性対象モジュールの優先度付け

モジュールごとの優先度は、① 業務への直接影響度（例：会員認証や決済機能に関わるか）、② 公開範囲（外部ユーザーが利用できるか）、③ 脆弱性の深刻度（CVSS が公表されている場合はスコア）で評価します。評価結果は「高・中・低」の三段階に分類し、表の右端に記入します。

高リスクと判定されたモジュールは、パッチ適用や代替モジュール検討を最優先で進める旨を担当者に指示します。

担当者への質問例と確認フロー

モジュール管理者に対しては、次の質問を用意します。① 現在使用中のバージョンは何か、② 公式から提供されているパッチは適用済みか、③ 本番とは別の検証環境でテストした結果はどうか、④ 本番環境への適用スケジュールはいつか。

回答は、上記チェックリスト形式で受け取り、未回答項目があれば追跡メールで確認します。全項目が揃ったら、リスク評価シートに反映し、次の修正版適用フェーズへ移行します。

修正版適用と検収の実施手順

修正版取得と適用手順の概要

まず、Drupal の公式サイトに掲載されているセキュリティ情報を確認したうえで、対象となる修正版がどのバージョンかを担当者に教えてもらう必要があります。修正版の入手先やリリースノートの所在は、公式ページに記載されているはずですが、実際にどこで入手できるかは担当者に確認してください。これにより、誤ったバージョンを取得してしまうリスクを防げます。

次に、修正版を適用する前に行うべき作業や手順は、システムの構成や運用方針によって異なります。担当者には、以下の点を具体的に質問してください。
・修正版を適用する環境（本番・ステージングなど）と、その環境でのバックアップの取得方法は？
・適用後に実施すべき確認項目（例：キャッシュのクリアやデータベースの更新）が公式に推奨されているか、あるいは社内で決められた手順はあるか。

これらの質問を通じて、実際に必要な作業とその根拠を明確にし、不要な手順や過剰な権限での作業を避けることができます。担当者の回答をもとに、作業計画を立てるとよいでしょう。

検収項目と合格基準の設定方法

検収の項目は、実際に導入したシステムの利用目的やリスクに合わせて決める必要があります。機能が期待通りに動くかどうかは、主要な操作フローを中心に確認しますが、エラー件数だけで合格とするのは過度に単純です。セキュリティ面でも、脆弱性スキャナの結果だけで判断せず、過去に報告された脆弱性がすべて修正されているかを開発担当に確認することが重要です。

また、パフォーマンスは利用状況に応じた基準を設定すべきで、固定の数値で合格とするのは適切ではありません。

担当者に確認すべきポイントは次のとおりです。
・主要な操作フロー（例：認証やコンテンツ作成）が修正前後で同様に機能するか、具体的にどの手順で確認したか。
・過去に指摘された脆弱性について、修正済みであることを示す証拠（パッチ適用履歴や開発者のコメント）があるか。
・パフォーマンス評価の基準は、実際の利用シーンを踏まえてどのように設定したか。その根拠となるデータや判断材料は何か。

これらの質問を通じて、検収基準が現実に即したものかどうかを判断し、必要に応じて基準や手順を見直す材料としてください。

完了確認と成果物の保管指示

修正版適用が完了したら、以下の成果物をまとめて提出させます：①適用手順の実施ログ（コマンド実行履歴やエラーメッセージ）②検収チェックリストとテスト結果レポート③バックアップ取得時のメディア情報と復元手順書。

これらは、社内の情報資産管理システムの「セキュリティ対策」フォルダに保存し、アクセス権はシステム管理者と情報セキュリティ担当者に限定します。保存期間は社内規程に従い、定期的なレビューと不要になった際の安全な廃棄を実施してください。

例外ケースと失敗時の対処フロー

適用不可モジュールの例外判定基準

カスタムモジュールやサードパーティ製モジュールで、公式の修正版が提供されていない場合は、まずそのモジュールが業務上必須かどうかを評価します。必須であれば、開発提供元にパッチ提供を依頼し、代替策（機能停止や別モジュールへの置換）を検討します。

非必須であれば、利用停止の意思決定を経営層に報告し、リスク評価書を添付して例外として承認を得ます。例外判定の根拠は、モジュールの利用頻度、外部公開範囲、過去の脆弱性実績を基にしたチェックリストで明示します。

適用失敗時のロールバック手順

パッチ適用中にエラーが発生した場合は、直ちに本番とは別の検証環境のスナップショットから復元し、元の状態に戻します。復元手順は、取得したバックアップファイルの場所と復元コマンドを記載した手順書に従い、データベースとファイルシステムの両方を対象とします。

復元後は、失敗原因をログ解析で特定し、再適用の可否を判断します。再適用が不可能と判断された場合は、例外判定フローへ移行し、関係者に報告します。全工程は、担当者が作業記録としてタイムスタンプ付きで残すことが必須です。

再発防止のための担当者レビュー項目

失敗事例を踏まえて、次回以降の対応で見落としがないようにレビュー項目を整理します。具体的には、①修正版取得元の URL とバージョン確認、②本番とは別の検証環境でのバックアップ取得手順、③適用前後のテストケース網羅性、④エラーログの自動収集設定、⑤例外モジュールのリスト更新、⑥レビュー会議での承認完了の了承です。

これらをチェックリスト化し、担当者が作業完了時に必ず記入することで、プロセスの抜け漏れを防止します。レビューは、月次のセキュリティミーティングで全員が共有し、改善策を議論する場とします。