LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

脆弱性の注意喚起は次々に届くのに、自社のどのシステムに関係するのかを調べる人がいない。パッチ（修正プログラム）を適用したいが、事前に動作を確かめる時間が取れない——。情報システム部門の人数が限られた企業では、こうした悩みが起こりがちです。脆弱性対応とは、使っているソフトウェアの脆弱性の情報を集め、自社への影響を判断し、パッチの適用などで直し、関係者に報告するまでの一連の作業を指します。

このうち情報を集める作業や、検証環境で動作を確かめる作業は、外部の専門人材に加わってもらうと進めやすくなります。ただし万能ではなく、どの脆弱性から直すかの判断や、業務を止める日程の合意は、社内でしか決められません。本記事では、情報システム部門やセキュリティの担当者に向けて、脆弱性対応の4つの工程、工程ごとの役割分担、報告と情報の管理の決まり、そして外部人材活用で確認したい点を整理します。

脆弱性対応とは

脆弱性という言葉は、経済産業省の告示「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」が定義しています。告示は脆弱性を「コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所」と定めています。^*2 ウェブアプリケーションでは、守るべき情報を誰でも見られる状態も脆弱性に当たり、設定や運用の誤りも直す対象になります。

脆弱性対応には、ソフトウェアを作る側と使う側の2つの立場があります。IPA（情報処理推進機構）の「情報セキュリティ早期警戒パートナーシップガイドライン」は、ソフトウェア製品を導入・管理する組織を製品利用者と呼び、「一般に、ソフトウエア製品の脆弱性対策を適用する立場にあります」としています。^*3 作る側の体制づくりは別の記事「PSIRT体制構築の進め方と外注のポイント」で扱っているので、本記事では使う側の脆弱性対応を取り上げます。

使う側の進め方は、IPAが2026年3月に公開した「製品利用者向けガイド」にまとまっています。ガイドは企業が行う脆弱性対応を、計画・要件定義、調達、導入、運用、廃棄の5つの段階に分けて示し、パッケージソフトを買う場合も、構築を外部に委託する場合も、運用時の脆弱性対応は必須としています。^*1

なぜ社内だけでは回りにくいのか

IPAの「脆弱性対策の効果的な進め方（実践編）第2版」は、広く使われてきたソフトウェアの脆弱性情報について、「その数は年々増加傾向にある」と述べています。^*4 そのうえで、すべての脆弱性に同じように手をかけるのではなく、攻撃の容易さや攻撃を受けたときの影響を考えて対策するよう勧めています。情報を集めて絞り込み、判断する作業は、止めずに続ける必要があります。

製品利用者向けガイドも、365日24時間の稼働が求められるシステムのように影響が大きい場合や、組織内のリソースが限られている場合は、外部委託や組織間の連携を使って、確実かつ継続的に実施される体制をつくるよう求めています。^*1 ガイドは、社外の人が体制に加わることも想定しています。

担当者が問い合わせ対応や障害対応と兼ねて脆弱性の情報を見ていると、注意喚起が届いても調べる時間が取れず、判断が後回しになりがちです。ガイドは、対処が遅れるとインシデント（情報漏えいやシステム停止などの事故）につながる可能性があると指摘しています。採用で人を増やすまでの間、作業を外部の専門人材に任せる方法もあります。

脆弱性対応の4つの工程

製品利用者向けガイドは、運用時の脆弱性対応を5つの手順に分けています。^*1 公開情報の確認、届いた報告の受付、自社での検査で脆弱性を見つける3つの手順と、対処が必要かどうかを決める認定、修正です。本記事では、これを情報収集・影響判断・パッチ適用に当て、社内外への報告を加えた4つの工程で扱います。

ガイドは、CSIRT（社内のセキュリティ事故に対応するチーム）に置く機能として、脆弱性情報の収集、分析とトリアージ、修正プログラムの適用などを挙げています。トリアージとは、リスクの大きさや事業への影響を評価して、対処の順番を決めることです。4つの工程ごとの分担を並べると、次のようになります。

社内に残しているのは、どれも自社の事業や業務を知らなければ決められないことです。公開情報を定期的に確認する、検証環境で動作を確かめるといった作業は、手順と判断の基準が決まっていれば社外の人にも任せられます。工程ごとに社内と社外のどちらが受け持つかは、次の図のとおりです。

情報収集と影響判断の分け方

実践編は、情報収集から分析までを3つのステップで示しています。Step1で自組織が使うソフトウェアに関係する情報に絞り込み、Step2でCVSS（脆弱性の深刻度を示す共通の指標）の値や、実際に攻撃に使われているかを確かめ、Step3で自組織のシステムへの被害の大きさを分析します。^*4 Step1とStep2は、公開情報を決まった手順で読む作業なので、外部の専門人材に任せやすい部分です。

Step3について実践編は、脆弱性そのものの危険度が低くても、対象のシステムが重要なサービスを提供していれば、被害の影響が大きくなることがあるとしています。システムが止まったときに困る業務や、扱っている情報の重要度を最もよく知っているのは社内の担当者です。影響の見立ては外部の専門人材に案として書いてもらい、社内で業務の事情を加えて確かめます。

Step1の前提になるのが、表の最初の行に挙げた台帳です。ガイドは「脆弱性対処の第一歩は、自組織が管理すべき対象を正確に把握することです」としています。^*1 台帳が古いと、使っていない製品の情報まで調べてしまい、使っている製品の情報を見落とします。そのうえで、対処が必要なものの認定と優先順位は社内の責任者が決め、判断の基準は、ガイドが整備を勧めるトリアージガイドライン（対処の優先順位の基準を示す文書）に書いておきます。

パッチ適用の進め方

製品利用者向けガイドによれば、利用する企業は、製品を作った会社や委託先に修正プログラムの提供を求め、届くまでの応急の対策も依頼します。修正プログラムが届いたら、本番環境に展開する前に検証環境で適用して、既存のシステムの動作に影響が出ないかを確かめます。適用の範囲とスケジュールは、システムの一時停止を伴う場合もあるため、関係者で協議して合意を得ながら進めます。

このうち検証環境での適用と動作確認、作業手順書の作成は、外部の専門人材に任せやすい作業です。システムを止める日程を利用部門と調整するのは、社内の担当者です。適用が終わったら、台帳の記載も書き換えます。

修正プログラムがまだ出ていないときは、回避方法で影響を減らします。パートナーシップガイドラインは、対策方法を、被害を避けるための回避方法と、脆弱性そのものを直す修正方法に分け、回避方法の例に脆弱性のある機能の無効化やWAF（ウェブサイトへの攻撃を防ぐ仕組み）の導入を挙げています。どちらを選ぶかで業務への影響が変わるため、選択肢と影響は外部の専門人材に並べてもらい、社内で決めます。定期的な適用の運用は「パッチ適用を止めない運用」で扱っています。

報告と情報の管理の決まり

自社のウェブサイトの脆弱性を誰かがIPAに届け出ると、IPAからウェブサイト運営者に通知が届きます。告示は、ウェブサイト運営者に、IPAとの連絡窓口を置くこと、通知された脆弱性を検証して結果を報告すること、脆弱性を確認したら修正してその旨を報告することを求めています。^*2 パートナーシップガイドラインは、検証の結果と修正したことのIPAへの連絡を、通知から3ヶ月以内を目処に行うよう求めています。^*3

同じガイドラインは、ウェブサイトの管理を外部の事業者に委託していても、委託元がウェブサイト運営者になるとしています。外部の専門人材が検証や修正をしても、IPAへ回答するのは自社です。報告書の下書きを頼むときも、誰が内容を確かめ、誰の名前で回答するかを決めておきます。

脆弱性の情報を社外の人に見せるときにも決まりがあります。告示は、脆弱性が修正されるまで情報が漏れないよう管理し、正当な理由がない限り第三者に開示しないよう求めています。^*2 パートナーシップガイドラインは、修正を依頼した外部機関などには、秘密保持契約を結んだうえで情報を連絡することを推奨しています。^*3 外部の専門人材に加わってもらうなら、情報を渡す前に秘密保持の約束を結びます。契約に残す項目は「外部人材活用のセキュリティ対策、契約と記録に残す3つの点」で扱っています。

社内の報告の流れも決めておきます。製品利用者向けガイドは、脆弱性の連絡が広報部門や投資家向けの窓口に届く場合もあるとして、そのときの対応を定めて周知するよう求めています。外部の専門人材が作業中に新しい脆弱性に気づいたときの連絡先も、同じ流れに入れておきます。

外部人材活用で確認しておきたい点

製品利用者向けガイドは、ガイドの内容が責任分界点（どこまでを誰が受け持つかの境目）を定めるものではないとし、契約内容やSLA（サービスの品質を約束する取り決め）を確かめたうえで役割を分担するよう述べています。外部の専門人材に加わってもらうときも、どの作業を任せ、何を成果として受け取り、誰が承認するかを、作業を始める前に書面にしておきます。

任せる作業は、表の右の列のように作業名で書きます。「毎週月曜に、台帳に載っている製品の脆弱性情報を確認し、関係するものを一覧にして出す」「深刻度の高いものには影響の見立ての案を添える」といった書き方です。「脆弱性対応の支援」とだけ書くと、影響判断まで任せたつもりになり、社内で決めることが決まらないまま進みます。

渡す情報と権限も決めます。情報収集には台帳が、パッチの検証には検証環境が要ります。本番環境での作業まで任せるかは作業ごとに決め、使えるアカウントは任せた作業に必要なシステムに限っておきます。個人データに触れる場面があるなら「業務委託エンジニアの情報セキュリティ、個人データを任せる前の確認」も参考になります。決めた役割は社内の規程に書き、手順書や記録は自社の管理する場所に残してもらいます。

まとめ：脆弱性対応で確かめておきたい3つの点

外部人材活用で脆弱性対応を進めるうえで、確かめておきたい点は3つに整理できます。第一に、4つの工程に分け、外部の専門人材に任せる作業を作業名で書くこと。第二に、脆弱性の認定と優先順位、システムを止める日程の合意は社内の責任者が受け持ち、判断の基準を文書にしておくこと。第三に、情報を渡す前に秘密保持の約束を結び、IPAや社内への報告を誰が行うかを決めておくことです。この3点を踏まえておけば、「外部の人が調べてくれていたのに、パッチを当てるかどうかを誰も決めていなかった」という事態を避けやすくなります。セキュリティ対策の体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「製品開発者向け・製品利用者向けガイド」（製品利用者向けガイド）（https://www.ipa.go.jp/security/guide/vuln/for_dev_user.html）。出典：IPA「製品利用者向けガイド」（2026年3月 第1版、2026年6月 第1版第2刷）。脆弱性管理の全体像、1章 人材・プロセス・技術の整備、3章 CSIRTの機能、5章 IT資産管理、7章 運用時の脆弱性対処、用語集を参照（2026年9月確認）
2. *2　参考：経済産業省「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」（https://www.meti.go.jp/policy/netsecurity/vul_notification.pdf）。出典：平成29年経済産業省告示第19号（最終改正 令和6年経済産業省告示第93号）。第1 3 定義、第3 ウェブアプリケーションに係る脆弱性関連情報に関する取扱い（1 手続の概要、2⑶ ウェブサイト運営者）を参照（2026年9月確認）
3. *3　参考：IPA「情報セキュリティ早期警戒パートナーシップガイドライン」（https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html）。出典：IPA「情報セキュリティ早期警戒パートナーシップガイドライン」。Ⅱ 用語の定義と前提（対策方法・製品利用者）、Ⅴ 4 ウェブサイト運営者の対応、付録1 用語の解説を参照（2026年9月確認）
4. *4　参考：IPA「脆弱性対策の効果的な進め方（実践編）第2版」（https://www.ipa.go.jp/security/reports/technicalwatch/hjuojm0000006nd2-att/000071660.pdf）。出典：IPAテクニカルウォッチ「脆弱性対策の効果的な進め方（実践編）第2版」（2019年2月）。はじめに、2.2 効果的な脆弱性対策の進め方、2.2.1 収集から分析までの流れを参照（2026年9月確認）

Tweet