手動運用から自動化へ
開発するシステムだけでは守りきれない
開発会社にとって、自社が開発するシステムの脆弱性管理は身近なテーマです。
当社でも、システムが利用するライブラリやパッケージの一覧であるSBOM（ソフトウェア部品表）をコンテナイメージから作り、継続的に検査しています。
しかし、社員が仕事で使うソフトウェアは開発プロセスの外にあります。
ChromeやZoomなどのアプリケーション、日々利用するSaaSにも脆弱性は見つかるものです。
コードの変更を契機に検査できないため、提供元や外部機関が公表する情報を自ら追うしかありません。
OSも一律ではありません。
組織全体のWindows端末を一括管理する製品はありますが、当社では業務や職種に応じてWindows、macOS、Linuxなどを使い分けています。
一つのOSを前提とした管理だけでは、実態を捉えきれません。
そこで私たちは、社員が利用するアプリケーションやSaaSについて、開発するシステムとは別の管理を始めました。
最初に悩んだのは情報の集め方ではなく、「何を、どこまで見るか」です。
監視対象を資産目録から絞る
何を見るかを決めるために、ISMSの運用で整備していた情報資産目録を使いました。
脆弱性管理のために一から一覧を作るのではなく、すでに把握している情報資産を出発点にした形です。
資産目録から、業務上の重要度が高いソフトウェアを抽出しました。
Chromeなどのブラウザ、WindowsやiOSなどのOS、Zoomなど日常的に使う業務アプリケーションです。
全社で利用され、脆弱性が見つかった場合の影響範囲が広いものを優先しています。
週次の手作業から始めた
私たちは数年前、この対象の脆弱性管理を手作業で始めました。
毎週持ち回りで担当者を決め、JVN（Japan Vulnerability Notes。国内の脆弱性情報データベース）で対象製品を検索し、基準を超える脆弱性があれば定例会で共有する、という運用でした。
担当者を持ち回りにしたのには理由があります。
一人に固定したほうが、検索だけなら効率的です。
しかし、それでは知識や判断の感覚まで一人に偏ります。
全員が順番に情報へ触れる運用を選びました。
運用を続けるうちに、CVSSのスコアだけを頼りにする危うさが気になり始めました。
きっかけは、実際に悪用された脆弱性だけを集めたKEV（Known Exploited Vulnerabilities）を知ったことです。
スコアが高くてもまだ誰も悪用していない脆弱性と、スコアはそこそこでも攻撃にすでに使われている脆弱性があるなら、優先すべきは後者ではないか。
それなら、深刻度の一覧より先にKEVを見るべきではないか。
そう考え出すと、参照すべき情報源はJVNだけでは済みません。
海外の脆弱性情報を広く収録するNVD、今後悪用される確率を示すEPSSも候補に入り、見なければならない範囲は広がっていきました。
検索より判断に困った
情報源を増やしても、担当者の困りごとは軽くなりませんでした。
検索の手間より、拾った情報をどう扱うかで詰まっていたからです。
一つは重複です。
当時の検索は製品名によるキーワード検索に近く、「Microsoft」と「Windows」で同じ脆弱性が別々に出てきます。
製品を識別する共通の名前であるCPE（Common Platform Enumeration）の見方も、まだ知りませんでした。
もう一つは、拾った情報が「自社にとって緊急か」を判断できないことです。
KEVやスコアで並べ替えても、Criticalと評価された脆弱性が自社の使い方で影響するかは分かりません。
担当者はその区別がつかず、怪しいものはすべて詳しい社員に聞くしかありませんでした。
詳しい社員が忙しい週は、確認が止まります。
「影響があるかもしれない」と分かっていながら判断を待つ時間は、担当者にとって強い焦りでした。
特定の人に頼らない仕組みを作りたいという動機は、ここから生まれました。
判断基準を自分たちで決める
仕組みにするには、どの情報源を参照し、どの条件で対応候補とするかを決めなければなりません。
製品名が一致した情報をすべて通知しても、情報の山に埋もれてしまいます。
そこで、CVSSの深刻度に加えて、KEVに載っているかどうかとEPSSの値を判断材料にしました。
KEVに載っている脆弱性は深刻度にかかわらず「緊急」とし、CVSSとEPSSにはそれぞれしきい値を置いて「緊急」「警告」「監視」に振り分けます。
しきい値を下回るものは通知せず、記録だけを残す扱いです。
修正版が出ているかどうかでも基準を分けています。
修正版があれば対応できるので、同じ深刻度でも優先度は高くなります。
修正版がなければ、本当に危険なものだけを拾う設定です。
どの深刻度を扱い、悪用の有無をどう優先度に反映するか。
これは外部の指標が決めてくれるものではなく、自社がどのリスクを受け入れるかという判断です。
手作業の時期に担当者が迷った経験があったからこそ、自動化するときに収集対象と通知条件を具体的に定義できました。
定型作業は機械へ、影響判断は人へ
この基準をもとに、NVD、JVN、KEV、EPSSの4つの情報源を統合し、リスクレベルを付けて通知する仕組みを作りました。
手作業の時期に検索を補助していたスクリプトはありましたが、判断まで担わせるには作り直すしかありません。
情報源ごとに形式も更新頻度も異なるデータを一つの脆弱性として結び付け、対象製品との照合をどの層で行い、基準の変更に耐える形でフィルターをかけるか。
ここに最も時間を使いました。
対象の線引きでも、一度失敗しています。
自動化の途中で、nginxのようなミドルウェアや自社開発システムの部品も同じ仕組みで追おうとしました。
すると対象が増えすぎて、人が確認できる量を超えます。
開発するシステムはSBOMによるイメージスキャンに任せ、この仕組みは資産目録から選んだ業務アプリケーションに絞りました。
この棲み分けで、ようやく自動化の目処が立ちました。
調整で難しいのは、拾いすぎと拾い漏れの釣り合いです。
対象が多すぎれば人が見なくなり、漏れれば仕組みの意味がありません。
通知の対象外にした情報も記録には残し、基準を変えたときにすぐ見直せるようにしています。
自動化したのは、集める、照合する、絞り込むところまでです。
自社の使い方に影響するか、いつ対応するかは、人が担います。
通知だけを自動で流す仕組みは、やがて見られなくなります。
定例会で取り上げる運用を残したのは、脆弱性情報を組織の判断につなげるためです。
間に合った、と思った出来事
2026年に入り、公開される脆弱性情報の数が大きく増えました。
AIを使った脆弱性発見手法の実用化が進み、人が確認すべき件数も増えています。
Googleは2026年7月、Chrome 149と150の2世代で計1,072件のセキュリティバグを修正したと公表しました。
それ以前の23世代分の合計を、2世代で上回った計算です。
Googleは安定版のリリース間隔を2週間に短縮し、セキュリティアップデートを週1回、さらに週2回へ増やす計画を試験しています。
監視対象の一製品だけで、週1回の手作業では追いつかない量です。
このとき、当社の自動化はすでに動いていました。
手作業のまま2026年を迎えていたら、確認そのものが止まっていたと思います。
自動化後に定例会で起きていること
担当者の作業は、検索から評価に変わりました。
リスクレベルの付いた一覧を見て、自社の使い方に影響するかを判断し、定例会で説明します。
検索方法は仕組みの中で統一され、担当者ごとのばらつきは消えました。
詳しい社員に確認する回数も減りました。
基準がシステムに定義されているので、「なぜこれが候補に挙がったか」を担当者自身が説明できます。
もう一つの変化は、脆弱性の話題が定例会や日常の会話に持ち込まれるようになったことです。
大規模な侵害キャンペーンや深刻な脆弱性が報道されると、メンバーがすぐに話題にし、全体に共有される流れができました。
自社に影響がない事例でも、その手口を見て「うちは同じ穴を塞げているか」と指差し確認をする材料になっています。
これは自動化の直接の効果ではなく、全員が順番に脆弱性情報に触れてきた手動運用の時期から続く土台でしょう。
おわりに
脆弱性管理では、仕組みを導入する前に自社で決めることがあります。
何を監視するのか、どの情報を対応候補とするのか、誰が影響を判断するのか。
外部のサービスやアプリケーションは、これらの基準を代わりに決めてはくれません。
私たちの場合、手作業で数年間運用し、担当者が判断に迷った経験が、監視対象の絞り込みと基準の定義になりました。
その基準があったから自動化でき、公開情報が急増した2026年にも確認を止めずに済んでいます。
公開される情報は増え続け、対応に使える時間は短くなります。
自分たちで対象と基準を決め、実際の負担を確かめたうえで仕組みにする。
この順序で、変化に合わせて続けられる脆弱性管理を育てていきます。