脆弱性のニュースを見たら、自社が対象か誰に確認する？情シス兼任の担当者が最初に動く5ステップ

2026年11月1日

「〇〇に深刻な脆弱性」というニュースを見かけても、自社のシステムが対象なのか、誰に聞けば分かるのかが分からない。情シス兼任の担当者から、よく聞かれる悩みです。

「脆弱性のニュースを見たけど、自社のシステムが対象かどうか、誰に確認すればいいのか分からない…」

先に結論をお伝えします。確認先は、まず「そのシステムを作った・保守している開発会社」です。ただし、聞く前に「何を使っているか」を3点だけメモしておくと、返事が1日で届きやすくなります。自分で脆弱性の中身を調べる必要はありません。担当者の仕事は、ニュースと自社のシステムをつなぐ「問い合わせ」を、正しい相手に、正しい形で出すことです。

この記事では、脆弱性（＝ソフトウェアの欠陥のうち、攻撃に悪用されうるもの）のニュースを見たときの動き方を、5つのステップと、そのまま使える問い合わせ文・チェックリストにまとめました。

脆弱性ニュースで「自社が対象か」が分かりにくい3つの理由

ニュースを読んでも判断できないのは、担当者の知識不足ではありません。仕組みとして分かりにくい理由が3つあります。

理由1：ニュースは「製品名とバージョン」で書かれている

脆弱性の情報は、「製品名＋バージョン」で対象が書かれます。一方、発注者が把握しているのは「受注管理システム」「会員サイト」のような、業務の名前です。この2つが結びついていないと、対象かどうかを照合できません。

理由2：システムの中身を知っているのは、作った会社と保守している会社

システムは、OS（＝パソコンやサーバーの基本ソフト）、Webサーバー、フレームワーク（＝開発の土台になる部品群）、ライブラリ（＝便利な機能の部品）など、多くの部品の組み合わせです。どの部品のどの版を使っているかは、実際に構築した開発会社でないと分からないことが少なくありません。

理由3：複数の会社に分けて頼んでいると、窓口が見えなくなる

サイトは制作会社、サーバーは別の会社、保守はさらに別の会社、というように分けて頼んでいると、「誰に聞くのか」自体が曖昧になります。これは担当者の責任ではなく、構成を一覧にしていない場合に起きやすい状態です。

自社のシステムの一覧を作る考え方は、次の記事で解説しています。

あわせて読みたい

脆弱性ニュースが出ても自社が該当するか分からない？IT資産台帳の作り方と開発会社・機器業者の連絡先整理脆弱性ニュースが出ても自社が該当するか分からない発注者へ。IT資産台帳のひな形と作り方、開発会社・機器業者への頼み方、連絡先の整理表、ニュースが出たときの照合手順を解説します。

自社が対象か確認する5ステップ

ステップ1：ニュースから「製品名・バージョン・対策の有無」を3行で控える

ニュース記事そのものを開発会社に転送するより、次の3点を控えて送るほうが、確認が早く進みます。

対象の製品名（例：Webサーバーソフト、CMS、VPN機器など）
対象のバージョン（「〇〇以前」と書かれていることが多い）
対策の有無（修正版が出ているか、回避策があるか）

公的な脆弱性情報は、IPAとJPCERT/CCが共同で運営する脆弱性情報ポータル「JVN」で公開されています。製品名で検索できる「JVN iPedia」というデータベースもあり、ニュースの元になった情報を確認する入口になります。

📰 出典：JVN（Japan Vulnerability Notes）

📰 出典：JVN iPedia 脆弱性対策情報データベース

ステップ2：自社のシステムを「製品名」で言えるかを確かめる

次に、自社で使っているシステムについて、分かる範囲で次の表を埋めます。空欄があってもかまいません。空欄こそが、開発会社に聞くべき項目です。

項目	例	分からないとき
システムの名前（業務での呼び名）	受注管理、会員サイト	社内の利用者に聞く
作った会社・保守している会社	契約書の発注先	契約書・請求書を見る
動いている場所	自社サーバー、クラウド（AWS など）	請求書の発行元を見る
主な技術（分かれば）	WordPress、Laravel、Windows Server	開発会社に聞く

ステップ3：一次窓口は「保守している開発会社」に決める

脆弱性の影響の調査は、システムの中身を知る会社に依頼するのが基本です。保守契約がある場合、影響調査が保守費に含まれるのか、別料金なのかは契約によって異なります。ここは契約書を確認し、不明なら次のステップで聞いてしまいましょう。

保守契約がない場合や、作った会社と連絡が取れない場合は、サーバーを提供している会社（レンタルサーバーやクラウドの事業者）に、まず「うちの契約で影響を受ける部分はあるか」を聞く方法があります。

ステップ4：問い合わせ文を送る

次の文面は、そのまま使えます。〈〉の部分を差し替えてください。

> 〈製品名〉の〈バージョン〉以前に脆弱性が公表されたとのニュースを見ました。（参考：〈ニュースまたは JVN のURL〉） > 弊社の〈システム名〉が影響を受けるか、次の点を〈回答希望日〉までに教えてください。 > 1. 該当する製品・バージョンを使っているか > 2. 使っている場合、実際に攻撃を受けうる状態か（外部に公開されているか） > 3. 対策の内容と、実施する場合の作業時間・費用の目安

「実際に攻撃を受けうる状態か」を聞くのがポイントです。同じ製品を使っていても、インターネットに公開していなければ緊急度が変わることがあるためです。ただし、これを自社で判断するのではなく、開発会社の見立てを聞くようにしましょう。

ステップ5：回答を「記録」して、次回の手間を減らす

回答は、メールの履歴に埋もれさせず、ステップ2の表に書き足しておきます。次に別のニュースが出たとき、表を見れば誰に何を聞くかがすぐ分かります。

やりがちな失敗

ニュースの URL だけを送る：どの部分を確認してほしいのかが伝わらず、返事が遅くなります。製品名とバージョンを添えましょう。
全部のニュースに反応する：発注者が見かけるニュースの大半は、自社に関係しません。表に載っていない製品の話は、様子見でかまいません。
「対象外でした」の一言で終わらせる：なぜ対象外なのか（その製品を使っていないのか、修正済みなのか）を、一文でよいので記録しておくと、後から効きます。
開発会社を責める言い方で聞く：脆弱性は、どんなに丁寧に作ったソフトにも見つかるものです。「確認をお願いしたい」という協力の姿勢で聞くほうが、早く正確な答えが返ります。