国家サイバー統括室（NCO）は 2026 年 11 月 5 日、事業者向けに不正アクセスへの対策をまとめた資料を公表しました。この記事は、企業の IT・セキュリティ担当者と管理職の方に向けて、脆弱性管理に関わる部分を 4 つのステップに整理し、FutureVuls での進め方を図で説明します。急いでいる方は、次の 3 点と各節の図だけご覧ください。
FutureVuls は、サーバやアプリの部品の一覧を公表済みの脆弱性と毎日照合し、見つかったものの担当者・期限・対応状況を記録するサービスです。機能の説明は 2026 年 11 月 8 日時点のものです。
3 つの資料は、原因を同じ方向に見ています。既知の脆弱性の放置や設定の不備など、基本的な対策の不足です。
濃い色の 2 項目（1-(1) 部品の把握と脆弱性の解消、3-(2) OSS・ライブラリの管理）は、部品と既知の脆弱性の管理です。薄い色の 2 項目は、その一部を支えます。
灰色の 4 項目には、それぞれ別の手段が要ります。たとえば、NICT が注意を呼びかけたアプリの解析からバックエンドのサーバを狙う手口は、資料が 2-(2) で API の認可と認証情報の問題として扱っており、FutureVuls では防げません。
1-(3) の「継続的な診断と監視」に色を付けていないのは、FutureVuls の「監視」と意味が違うからです。FutureVuls は部品を毎日最新の脆弱性情報と照合し直しますが、これは 1-(1) を続けることです。「去年登録したライブラリに今日公表された CVE が該当する」ことは教えますが、「深夜に見慣れない IP からログインがあった」「自社の API が他社のトークンを受け付ける」ことは分かりません。後者には、SIEM や EDR、外部からの脆弱性診断が要ります。
パッケージ案が主な施策の先頭に挙げる AI を使った脆弱性診断も、別の作業です。診断は攻撃者の立場でシステムを調べて弱い所を探し、FutureVuls は部品の一覧と公表済みの脆弱性を照合します。FutureVuls のタスクはスキャンの検知から自動で作られ、手動では登録できません。診断の結果は、診断の報告として別に管理します。
濃い色の 2 項目でやることは、この 4 ステップにまとまります。大事なのは、ステップ 4 からステップ 2 へ戻る線です。部品の一覧を作っただけでは、この輪は回りません。ここからは順に見ていきます。
例は PHP2Shell です。2026 年 10 月に公表された PHP の 2 件の脆弱性（CVE-2026-109618、CVE-2026-109619）の通称です。IPA の注意喚起は、利用中の製品への影響を確認し、最新版へ更新するよう案内しました。公表の翌朝に「どのサーバに PHP のどのバージョンがあるか」と聞かれて、すぐ答えられるかどうかが問われます。
FutureVuls に部品の一覧を登録する方法は次のとおりです。
| 対象 | 登録の方法 |
|---|---|
| サーバ | cron で定期実行するスキャナ、ペースト |
| コンテナ | Docker イメージのスキャン |
| アプリの依存ライブラリ | lockfile の読み取り |
| ミドルウェア、ネットワーク機器など | CPE（製品とバージョンの識別子）の登録 |
| AWS | Amazon Inspector との連携 |
| 受け取ったファイル | SBOM インポート |
SBOM インポートの形式は CycloneDX 1.4〜1.7 と SPDX 2.2・2.3 です。SPDX 3 には対応していません。一覧は、一度登録して更新しなければ古いままです。PHP を更新しても一覧を変えなければ、FutureVuls は古いバージョンのまま照合します。
資料の注記が言っているのは、この差です。FutureVuls では次の仕組みで照合し直します。
すでに検知している脆弱性が KEV に載ると、KEV を確認した時点でタスクに「悪用されている」と反映されます。あわせて次のスキャンを待たずに照合し直し、SSVC の結果や対応期限を更新します。この更新の目安は 1 時間以内で、対象のサーバが多いと翌朝までかかることがあります。まだ検知していない脆弱性は、次のスキャンで反映されます。パッケージ案の日本版 KEV は、この 3 つには含まれません。国内の情報をもとに急ぎたい脆弱性は、スペシャル警戒タグで組織として優先度と期限を指定できます。通知は設定が必要で、プランによっては初期状態で OFF です。
図は説明用の例で、実在の会社の話ではありません。悪用が確認され、攻撃を自動で繰り返すのは難しいと判定された脆弱性を、FutureVuls の既定の決定木にあてはめました。CVSS スコアだけで並べると、4 台は同じ順番です。社内のサーバでも、止まると基幹業務が困るなら定期メンテナンスを待たないので、社内だから後回しでよいわけではありません。
資料の対策例 3 は、悪用の状況、インターネットから狙えるか、システムの重要度などで基準を前もって作ることを挙げ、参考資料に SSVC を示しています。FutureVuls の SSVC の入力は次の 4 つです（既定の決定木は SSVC v2.1 の Deployer Tree で、資料が挙げる CISA のものとは段階の名前が違います）。
| 入力 | 誰が決めるか |
|---|---|
| 悪用されているか（Exploitation） | FutureVuls が自動で |
| 攻撃を自動化できるか（Automatable） | FutureVuls が自動で |
| 外部からアクセスできるか（Exposure） | 利用者が設定 |
| 止まると何が困るか（Human Impact） | 利用者が設定 |
タスクごとに、結果とその理由を確かめられます。
利用者が選ぶ 2 つの値は、グループごとに設定し、サーバごとに変えたいときはロールで上書きします。既定値があるので設定しなくても計算されますが、実際と違っていれば順番もずれます。外部からアクセスできるかどうかは、管理者の棚卸しと外部からの調査（ASM）を突き合わせて判断します（資料の 1-(2) 対策例 1）。AWS なら Amazon Inspector で調べる手順もあります。調べた結果は自動では入らないので、担当者が値を選びます。Linux をスキャナでスキャンしていれば、OS パッケージのタスクで、関係するプロセスが動いているか、ポートを開いているかも確かめられます。
期限: トリガー&アクションという設定で、SSVC の結果に応じた対応期限を自動で付けられます。Immediate なら 3 日後、というのはヘルプの例で、日数は組織が決めます。手動で付けた期限は上書きされません。タスクのステータスや優先度も同じ設定で自動で変えられ、決定木は組織に合わせて変更できます。
タスクは「1 サーバ × 1 脆弱性」の単位で、スキャンの検知から自動で作られます。主担当者・対応期限・コメントを残せて、期限を過ぎると「期限切れ」タブと Daily / Weekly Report でわかります。検知されなくなると自動で PATCH_APPLIED に変わり、再び検知されると NEW に戻ります。
直す作業も助けます。対応するサーバと OS の、修正版が出ている OS パッケージなら、アップデートコマンドや Ansible Playbook を表示できます。RHEL・Amazon Linux・Debian・Ubuntu の EC2 なら、AWS の SSM 連携を設定すると、パッケージの更新も実行できます。
気をつけたいのは緩和策です。 WAF のルールなどで緩和策を入れてタスクを WORKAROUND にすると、脆弱性は残っているのに「対応済」タブへ移り、「期限切れ」タブにも出ません。資料の対策例 4 は、恒久的な対処が終わるまで確かめ続けることを挙げています。やり方は 2 つあります。
WORKAROUND のタスクもスキャンのたびに SSVC を計算し直します。トリガー&アクションを設定しておけば、緩和策のあとで脆弱性が KEV に載って Immediate や Out-of-Cycle に変わったときに、タスクを NEW に戻せます。緩和策が効いているかの確認と、ログで侵入の跡を探す作業は、FutureVuls の外で行います。
資料の 3-(2) 対策例 2 は、委託開発で SBOM の提出を契約に入れ、検収で確かめ、納品後も監視することを挙げています。FutureVuls のヘルプに委託先向けの手順は無いので、図は機能を使った運用の提案です。
図の右端が、見落としやすい点です。パッケージ案も、契約で脆弱性対応の担当が明確に決まっていない場合が多く、緊急時に支障が出ていると指摘しています。たとえば（説明用の例です）、深刻な脆弱性が公表された夜に、発注者は「委託先が調べるはず」と考え、委託先は「依頼を待つ」と考えていれば、どちらも動きません。
提出の条件には PURL（部品の種類・名前・バージョンを表す識別子）を入れておきます。 FutureVuls は部品の識別子を手がかりに照合するので、識別子が無い部品は一覧に載るだけで照合されません（インポート仕様）。
| SBOM の部品の書き方 | 照合されるか |
|---|---|
検知に対応した種類の PURL（例 pkg:npm/lodash@4.17.21） |
される |
| 有効な CPE あり（製品名などが入ったもの） | される |
| 名前とバージョンだけ（例 lodash 4.17.21） | されない（手で割り当てるまで） |
検知に対応していない PURL だけ（generic、conda など） |
されない |
受け取るときに知っておくとよい仕様は、ほかに 3 つあります。
改修のたびに SBOM を更新しても、変更のないソフトウェアの検知結果・タグ・手動で割り当てた CPE は保持されます（2026 年 10 月のリリース前に API やペーストで登録・更新したサーバ SBOM は、リリース後の初回更新だけ、OS パッケージに手動で割り当てた CPE とタグが引き継がれません）。取り込んだ SBOM の部品は、スキャンした部品と同じように扱われます。次の節の EOL 検知も使えます。悪意のあるパッケージの検知と OSS ライセンスの表示は、PURL の付いた部品が対象です。設計書との突き合わせとライセンス違反の判断は人の作業です。
資料の 3-(2) 対策例 1 は、組み込まれた OSS のバージョンと EOL の状況を普段から把握することを挙げています。ここが、FutureVuls が独自に作り込んできた部分です。
調べる対象は、お客様の環境で実際に見つかった部品です。npm・Maven・PyPI などのパッケージの識別子（PURL）が付いた OSS は分析の対象に入り、新しく見つかったものから順に処理します。PURL の無い部品や、対応していない種類の PURL は、この分析の対象外です。見つかって間もない部品は判定まで時間がかかり、調べても判定できないものもあります。OS や CPE で登録した製品の EOL は、下の公開の一覧で調べます。
独自に作り込んだ理由は、OSS の終わりが脆弱性データベースに載らないからです。作者が「もう保守しない」と README に書いても、CVE は増えません。CVE と照合するだけの仕組みでは、そのライブラリは何も問題が無いように見えます。当社の調査では、国内 74 組織の本番環境で動く OSS 16,627 件のうち、分類できなかった 1,199 件を除いた 48.5% が、開発停滞か保守終了（予定を含む）でした（人の最後のコミットが半年以内か、などの条件で数えた値です）。
公開の一覧に載る製品: サプライチェーンリスクは、スキャンで得た部品を endoflife.date（400 製品超）や OS ベンダーの情報と照合します。延長サポートを契約していれば、その期限を使えます。収録されていない商用製品や自社製品は、非公開 EOL 情報として API で登録できます。
提供元が終了を宣言した OSS: 大半の OSS は、公開の一覧に載っていません。そこで FutureVuls は、npm の deprecated、PyPI の Inactive、Packagist の abandoned、Maven の relocation といったレジストリの宣言に加えて、README や文書に書かれた宣言まで調べ、独自の判定カタログを作っています（仕組みの説明）。たとえば npm の inflight は、確定 EOL としてチケットになります。後継が分かっていれば、aws-java-sdk-elasticinference に対する AWS SDK for Java 2.x のように表示します。
README の文章は、キーワードで拾うだけでは誤ります。そこで次の順で判定しています。
LLM の判定をそのまま結果にはしません。公式の配布サイトや GitHub の一次情報を確かめ、機械の検査で矛盾を調べ、最後に人が確認します。判定は見直しを続けていて、更新はスキャンを通じて自動で反映されます。
宣言は無いが、実質的に止まっている OSS: ここで使うのが、当社が開発して公開している OSS の uzomuzo です。手法は FIRST VulnCon 2026 でも発表しました。たとえば npm の dicer は、公式な廃止宣言もリポジトリのアーカイブも無いのに、深刻度 High の未修正の脆弱性を抱えたまま、人のコミットが 3 年以上止まっています。CVE の照合では「1 件」と数えるだけのものを、uzomuzo は実質 EOL と判定します。
実質 EOL は、提供元の宣言が無いのでチケットにはせず、ソフトウェアヘルスに出します。ここには Scorecard（OSS のセキュリティ上のリスクを自動で点検する指標）やメンテナンス状況、推奨される対応を、LLM が担当者の立場ごとに要約して表示します。組織全体の確定 EOL と実質 EOL は、グループセットでまとめて検索できます。
チケットになった EOL は、脆弱性のタスクと同じように担当者・期限・コメントを残せます。同じ画面で、悪意のあるパッケージ（マリシャスパッケージ）も OSV の情報と照合して管理します。Linux の OS パッケージは OS と同じ期限なので原則として個別のチケットになりませんが、RHEL の Application Streams は別に管理します。
資料の 1-(3) は、防御側でも AI の活用の検討を挙げています。FutureVuls で AI を使っているのは次の場面です。どれも、最後の判断は人が一次情報を見て行う前提です。
| 場面 | AI がすること |
|---|---|
| 脆弱性の詳細 | 脆弱性と脅威情報を要約する |
| ソフトウェアヘルス | OSS の状況を立場ごとに要約する |
| EOL の判定 | README の宣言を読んで判定する |
| MCP Server 連携 | AI エージェントから情報を参照する（読み取りのみ） |
| 機能 | 使えるプラン |
|---|---|
| 定期自動スキャン（全サーバ） | CSIRT |
| 定期自動スキャン（一部のサーバ） | Standard* |
| KEV 追加時の再照合（SBOM・スキャナなど） | CSIRT、PSIRT |
| SSVC、対応期限の自動設定 | CSIRT、PSIRT（PSIRT は有効化が必要） |
| グループセット（複数システムの横断） | CSIRT、PSIRT |
| サプライチェーンリスク（EOL のチケット） | CSIRT |
| スペシャル警戒タグ、決定木の変更 | CSIRT |
※Standardプランについて、2026/11/09現在は個別でのご案内のみとなります
Standard プランの定期自動スキャンの対象は、擬似サーバ、Inspector 連携、コンテナレジストリ連携で追加したサーバです。前回のスキャン結果が無いサーバと、Amazon Inspector SBOM のインポートを有効にしたグループで Inspector が検知した脆弱性は、KEV 追加時の照合し直しの対象外です。SSVC の結果や期限の更新は、次のスキャンや取り込みで反映されます。プランごとの機能詳細は料金プランをご覧ください。
照合と、検知したものの記録は FutureVuls で自動にできます。インターネットからアクセスできるか、止まるとどの業務が困るかの判断、緩和策の確認、担当の取り決めは人の仕事として残ります。
まず明日、「PHP のどのバージョンがどのサーバにあるか」にすぐ答えられるか試してみてください。PHP を使っていなければ、業務で使う主なソフトの 1 つで構いません。
自社の脆弱性管理で FutureVuls が支えられる範囲や、利用するプランを確認したい方は、お問い合わせください。
また、FutureVulsを活用してSBOM運用を行っている株式会社東芝様の事例も公開しています。
いいえ。SBOM は作った時点の部品の一覧なので、最新の脆弱性情報と照合し続け、見つかった脆弱性を直し終わるまで追う必要があります。
FutureVuls は、保存した部品の一覧を原則として 1 日 1 回照合し直します。全サーバが対象なのは CSIRT プランで、登録の方法によって対象が変わります。
8 項目のうち、主に 1-(1) 部品の把握と脆弱性の解消と、3-(2) OSS・ライブラリの管理を支えます。2-(1) と 2-(3) は、既知の脆弱性の照合に限って一部を支えます。
ログ監視や侵害の検知、API の設計の点検、診断やペネトレーションテストは、別の手段が要ります。
SSVC と対応期限の自動設定は、CSIRT・PSIRT プランで使えます（PSIRT は有効化が必要です）。
FutureVuls の SSVC は、悪用状況、攻撃を自動化できるか、外部からアクセスできるか、止まると何が困るかの 4 つから優先度を決めます。
後の 2 つは利用者が設定します。結果に応じた対応期限はトリガー&アクションで自動で付けられ、日数は組織が決めます。
はい。FutureVuls は、公開の EOL 一覧に加えて、レジストリと README の終了宣言を調べ、実質的に開発が止まった OSS も uzomuzo で判定します。
確定 EOL はサプライチェーンリスクのチケットに（CSIRT プラン）、実質 EOL はソフトウェアヘルスに表示します。uzomuzo の分析には、対応する種類の PURL が要ります。
PURL が無くても、OS や CPE の情報から公開の一覧で EOL を検知できる場合があります。判定に時間がかかる部品や、判定できない部品もあります。