脆弱性管理ツールおすすめ20選を比較｜守りたい対象・SBOM対応・優先順位付けで選ぶ

年に一度の脆弱性診断は受けていても、診断の翌週に公表された脆弱性までは誰も追えていない、という状態は珍しくありません。JVN やベンダーの告知をメールで受け取り、表計算ソフトに転記し、担当者に依頼して、返事が来たら「対応済み」に色を塗ります。管理対象が数十台を超えたあたりから、この運用は回らなくなります。

脆弱性管理ツールは、この「診断のあと」を仕組みで回すためのものです。ただし、いざ選ぼうとすると製品ごとに性格が大きく異なり、サーバーを見るものと自社コードのライブラリを見るものが同じ名前で並んでいます。自社が守りたい対象をそもそもカバーしているのか、検出した後どこまで面倒を見てくれるのかが、製品ページを読んでも見えてきません。

本記事では、脆弱性管理ツール20サービスをタイプ別に比較・解説します。守りたい対象（サーバー・コンテナ・クラウド・自社コードの OSS 依存など）のカバー範囲、SBOM の生成と取り込みへの対応、検出後の優先順位付けをどこまで自動化できるかという3つの軸で横並びに整理しました。あわせて、料金の課金単位、無料・OSS で足りる範囲、SBOM 対応を求める制度が実際に何を求めているかも整理しました。

また、守りたい対象と SBOM の要否から自社に合うタイプを絞り込める「30秒で終わる選定診断ツール」をご用意しています。比較表を読む前の絞り込みにご活用ください。

脆弱性管理ツールとは？SBOM・SCAとの関係

脆弱性管理ツールとは、自社が持つ IT 資産の構成情報を把握し、日々公表される脆弱性情報と突き合わせて、どこにどの脆弱性が残っているかを継続的に可視化する仕組みです。検出して終わりではなく、対応の優先順位づけと進捗の管理までを守備範囲に含む点が、単発の診断ツールと大きく異なります。

ここからは、まず診断との違いを整理し、続いて読者が同時に検討することの多い SBOM・SCA との位置関係まで一気に押さえます。

脆弱性診断（点検）と脆弱性管理（継続運用）の違い

脆弱性診断は、ある時点の IT 資産に攻撃を模したパケットを送るなどして、脆弱性が実在するかを特定する行為です。対して脆弱性管理は、資産の把握から情報収集、リスク評価、対処、そして対応状況の管理までを繰り返し回すプロセスを指します。診断は管理という長いプロセスの中の一工程にあたります。

経済産業省の「ASM 導入ガイダンス」は、脆弱性管理のライフサイクルを6つの工程として示しています。

対象ソフトウェアの把握: サーバ内にインストールされているソフトウェアの情報を把握し、管理する。／脆弱性関連情報の収集: ソフトウェアの最新バージョンや脆弱性情報などを収集する。／適用の判断: 収集した脆弱性関連情報の中に新しいバージョンのソフトウェアや脆弱性、攻撃などの情報を確認したら、新しいバージョンのリリースノートやCVSS、緊急度を確認し、脆弱性への対応の要否を判断する。／計画: 対策が必要な脆弱性に対して、修正作業などを計画する。／検証: 修正作業を本番環境へ適用する前に、検証環境に適用し、本番環境への適用可否を判断する。／適用: 修正作業を実行する。

出典：ASM（Attack Surface Management）導入ガイダンス 表2-1「脆弱性管理のライフサイクル」（経済産業省 商務情報政策局 サイバーセキュリティ課、令和5年5月29日）

この6工程のうち、診断が担うのは主に脆弱性の特定にあたる部分だけです。残りの工程を人手で回し続けるのが難しいからこそ、ツールで自動化する発想が出てきます。診断は確度が高い代わりに実施のたびにコストと調整が発生するため、頻度を上げにくいという性質もあります。

ここまで読んで、継続的な管理よりも「まず一度きちんと診断したい」というほうが自社の課題に近いと感じた場合は、診断サービス側から検討するほうが早く進みます。診断方法ごとの違いや費用相場、依頼先の選び方は以下の記事で解説しています。

脆弱性管理ツールでできること

ツールが肩代わりするのは、大きく4つの作業です。IPA は情報セキュリティ10大脅威の解説書で、システム管理者・製品利用者が取るべき対策として次を挙げています。

・利用している資産の把握、管理体制の整備
・脆弱性情報の収集、脆弱性の悪用状況の収集、脆弱性対策の優先度付け、対策状況の管理、パッチマネジメントの実施
・ソフトウェアの把握や管理においては SBOM（Software Bill of Materials）の導入を検討する

出典：情報セキュリティ10大脅威 2026 解説書［組織編］「4位 システムの脆弱性を悪用した攻撃」p.23（独立行政法人情報処理推進機構、2026年3月）

ここに並ぶ「脆弱性情報の収集」「悪用状況の収集」「優先度付け」「対策状況の管理」が、そのままツールの機能に対応します。具体的には、自社が使っているソフトウェアの一覧を自動で集め、その一覧と脆弱性データベースを突き合わせて影響のあるものだけを抽出し、危険度を判定して並べ替え、誰がいつまでに何を直すかを記録して追跡する、という流れです。

注目したいのは、同じ箇条書きの中に SBOM の導入検討が並んでいる点です。脆弱性管理と SBOM が同じ文脈で語られるのは、ソフトウェアの構成が分からなければ突き合わせようがない、という順序があるためです。

SBOM（ソフトウェア部品表）とは｜SPDX・CycloneDX・SWID の違い

SBOM（エスボム、Software Bill of Materials）は、ソフトウェアがどんな部品でできているかを機械が読める形で並べた一覧です。経済産業省の手引は次のように定義しています。

SBOMとは、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リストである。SBOMには、ソフトウェアに含まれるコンポーネントの名称やバージョン情報、コンポーネントの開発者等の情報が含まれ、OSSだけではなくプロプライエタリソフトウェアに関する情報も含めることができる。これにより、特定のコンポーネントの脆弱性が明らかになったとき、その脆弱性の影響を受けるコンポーネントが含まれているかを即座に認識することができ、脆弱性に対する迅速な対応を行うことができる。

出典：ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0 2.1「SBOMとは」p.9（経済産業省 商務情報政策局 サイバーセキュリティ課、令和6年8月29日）

SBOM を記述する形式は主に3つあり、それぞれ生まれた目的が違います。同じ手引が3形式の性格を次のように整理しています。

形式	標準化	性格（経済産業省手引の記述にもとづく）
SPDX	ISO/IEC 5962:2021（2021年9月に国際標準化）	スニペット、ファイル、パッケージ、コンテナ、OSディストリビューションなど幅広い部品タイプをサポートし、ライセンス情報を一意に特定する識別子のリストが用意されている。知財・ライセンス管理を主目的に標準化された
CycloneDX	ECMA-424（Ecma International。初版2024年6月、第2版2025年12月）	セキュリティ管理を念頭に置いた形式。対象ソフトウェアの情報だけでなく、含まれる既知の脆弱性とその悪用可能性の情報も記述できる
SWID タグ	ISO/IEC 19770-2:2015	ソフトウェアID体系を含むソフトウェア管理の標準。ライフサイクルに沿って SBOM を管理できる特徴がある

実務上は、ライセンス順守を重く見るなら SPDX、脆弱性管理と結びつけたいなら CycloneDX、という選び分けになります。取引先から形式を指定される場合もあるため、ツールを選ぶ際は「どの形式で出力できるか」だけでなく「どの形式を取り込めるか」も確認しておくと、後から困りません。

出典・参考資料（3件）

• 出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 2.4「SBOMフォーマットの例」p.20、7.4.1(2) p.63｜経済産業省（PDF）
• 出典：SPDX 公式サイト｜The Linux Foundation Projects（spdx.dev）
• 出典：ECMA-424 CycloneDX Bill of materials specification｜Ecma International（標準ページ）

SCA（ソフトウェア構成分析）とは｜SASTとの違い

SCA は、自社のアプリケーションが取り込んでいる第三者製の部品やオープンソースを洗い出し、そこに含まれるリスクを特定する手法です。OWASP は、より広い「コンポーネント分析」の一部として次のように位置づけています。

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. […] A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

出典：OWASP Community — Component Analysis（OWASP Foundation）

混同されやすいのが SAST（静的アプリケーションセキュリティテスト）です。SAST が見るのは自社の開発者が書いたコードそのもので、SCA が見るのは外から持ち込んだ部品です。

同じ「コードを解析する」でも対象が違うため、片方を入れればもう片方が不要になる関係ではありません。また、OWASP は SAST の弱点として誤検知の多さを挙げており、導入時の運用負荷はこの点も含めて見ておく必要があります。

自社の開発者が書いたコードそのものを点検するとなると、SAST ツールで自動的に走らせるのか、専門家にソースコードレビューを依頼するのかという別の判断が要ります。ツールと手動の使い分けや費用の目安、外から動かして調べる動的診断との違いは以下の記事で整理しています。

3つはどこが重なり、自社にはどれが必要か

3つの関係は「SBOM が部品表、SCA がその部品表を作って脆弱性と突き合わせる解析、脆弱性管理ツールが資産全体で対応を回す仕組み」と整理できます。OWASP も、部品の正確な一覧が risk identification の要であり、その作成に SBOM が役立つと述べています。SCA と SBOM は、多くの製品で同じ機能の表と裏になっています。

そのうえで、自社がどれを軸にすべきかは置かれた状況で決まります。

• 取引先や規制から SBOM の提出を求められた：自社が出荷する製品・納品物の部品表を作り、公開後も脆弱性を追える仕組みが要ります。SBOM の生成と、外部から受け取った SBOM の取り込みの両方に対応できるかが分かれ目です
• 自社プロダクトのOSS依存を継続的に見たい：SCA が中心になります。対応言語とパッケージマネージャ、そして開発フローに組み込めるかが判断材料です
• 社内のサーバーやネットワーク機器まで含めて把握したい：資産全体を横断して管理するタイプが向きます。SCA だけでは、自社が書いていないミドルウェアやOSの脆弱性は視野に入りません

脆弱性管理ツールのタイプと向いている企業

脆弱性管理ツールは「何を守るのか」と「検出した後どこまで担うのか」で性格が分かれます。この2つで整理すると、製品ページの機能一覧を読み比べる前に候補をかなり絞り込めます。

本記事では5つのタイプに分けました。まず全体像を確認してください。

自社コードのOSS依存まで見て、修正まで導くタイプ

自社が開発しているアプリケーションの依存ライブラリを解析し、脆弱性のあるバージョンを使っていないかを継続的に見張るタイプです。多くの製品が SBOM を生成しながら、「どのバージョンに上げれば直るか」まで提示します。修正内容をプルリクエストとして自動で作る機能を持つものもあります。

自社でプロダクトを開発している企業に向きます。逆に、購入したパッケージソフトやサーバー OS の脆弱性は視野に入らないため、社内 IT の管理だけを目的にする場合には合いません。導入にあたっては、開発フローや CI/CD に組み込むことが前提になるので、開発チームの協力を取り付けられるかも判断材料になります。

IT資産全体をまたいで一元管理するタイプ

サーバー、コンテナ、クラウドの設定、ネットワーク機器といった層をまたいで資産を洗い出し、脆弱性情報と突き合わせるタイプです。優先順位付けの自動化と、対応状況の進捗管理まで備える製品が多く、情報システム部門が全社のリスクを俯瞰する用途に向きます。

カバー範囲が広い分、価格も資産数に比例して上がりやすく、導入時には対象資産の棚卸しが必要になります。また「全レイヤー対応」と書かれていても、コンテナやクラウド設定が別製品扱いだったり、途中で本体機能から外れていたりすることがあるため、自社が本当に見たい層が標準機能に含まれるかは個別に確認してください。

サーバー・機器の脆弱性情報を日本語で追い切るタイプ

国内向けに脆弱性情報を収集して日本語で提供し、自社の構成に影響するものだけを特定して知らせるタイプです。検出そのものより、情報収集と影響判定、そして対処状況の管理に軸足があります。

海外製ツールの英語の脆弱性情報を担当者が読み解く体制が組めない場合や、JVN やベンダー告知を人手で追っている現状をそのまま置き換えたい場合に効きます。経済産業省の手引も、英語のみで提供されるツールの運用が難しいなら日本語対応ツールの優先度を上げることを選択肢として挙げています。

製品や取引先に出すソフトウェアのSBOMを作って管理するタイプ

出荷する製品や納品物に含まれる部品を洗い出して SBOM を作り、出荷後も脆弱性を追い続けるタイプです。組織やチーム、プロジェクトといった単位で SBOM を管理し、「どの部品がどの製品に入っているか」を横断して追跡できる製品もあります。

取引先や規制から SBOM の提出を求められた企業、製品にソフトウェアを載せるメーカーの製品セキュリティ担当が主な対象です。社内 IT の脆弱性管理とは目的が違うため、両方が必要なら別々に検討することになります。

外部公開資産の見えていない穴を洗い出すタイプ

ASM（Attack Surface Management）と呼ばれる領域で、攻撃者から見える自社の資産を自動で棚卸しし、そこに残るリスクを継続的に評価します。経済産業省は ASM を次のように定義しています。

組織の外部（インターネット）からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス

出典：ASM（Attack Surface Management）導入ガイダンス 2.1「ASMの定義」p.6（経済産業省、令和5年5月29日）

ほかのタイプが「把握済みの資産」を対象にするのに対し、このタイプは未把握の資産を見つける点に価値があります。同ガイダンスも「ASM は未把握の IT 資産を発見する、という点において脆弱性管理や IT 資産管理を補完する取り組み」と位置づけており、置き換えではなく補完の関係です。

ただし外部から見える情報だけを使うため、検出結果は脆弱性が存在する可能性の指摘にとどまる点は理解しておく必要があります。このタイプに当てはまる掲載サービスは1件です。

このほか、自らはスキャンを行わず、ほかのツールが検出した脆弱性を取り込んで担当者・期限・ステータスの管理だけを担う製品もあります。すでに複数の検出ツールが入っているのに対応が回っていない組織には効く選択肢です。

守りたい対象が複数ある場合は、1本でまたげるかを先に見る

ここまで5つのタイプに分けてきましたが、実務では「社内のサーバーも、自社で開発しているアプリのライブラリも、そこに取引先からの SBOM 要求も」というように、対象が複数にまたがるほうが普通です。タイプは排他的な区分ではなく、製品によっては複数のタイプの役割を1本で担います。

またげるかどうかは、比較表の「守れる対象」列を横に読むと判断できます。サーバーやコンテナと、自社コードの OSS 依存の両方に印が付いている製品なら1本で足ります。両方をカバーする製品が要件に合わなければ、資産側と開発側で1本ずつという2本構成になります。SBOM の提出まで必要なら、そこに「SBOM 対応」列の生成と出力の可否を重ねてください。

次の診断は「まず優先して守りたい対象」を1つ選ぶ形式なので、複数ある場合は最も緊急度の高いものを選んだうえで、表示された候補を比較表の「守れる対象」列で追加確認するのが確実です。

自社がどのタイプに当てはまるか迷う場合は、次の診断で3問に答えると候補が絞り込めます。

脆弱性管理ツールの選び方

タイプが絞れたら、同じタイプの中でどれを選ぶかを決めていきます。ここからは、選定時にそのまま比較項目として使える8つの観点を、確認する順に並べて解説します。

守りたい対象をカバーしているか

最初に確認すべきはここです。サーバー OS とミドルウェア、コンテナイメージ、クラウドの設定、自社コードの OSS 依存、ネットワーク機器、出荷製品のバイナリ——このうち自社が守りたいものが標準機能でカバーされているかを、製品ごとに確かめます。

ここで見落としやすいのが、機能が別製品に切り出されているケースです。コンテナやクラウド設定の評価が上位パッケージや別ライセンスに移っている製品、SBOM の出力が同ブランドの別製品の機能である製品が実際にあります。「対応している」という記述を見つけたら、それが検討している製品の標準機能なのか、追加契約が要るのかまで見てください。本記事の比較表では、この点を製品ごとに書き分けています。

参照する脆弱性データベースの範囲と情報の速さ

ツールの検出精度は、どのデータベースを参照しているかにかなり左右されます。主要なデータベースは役割が分かれており、CVE List が脆弱性に識別番号を付け、NVD がそれに評価指標を付与し、JVN iPedia が国内外の情報を日本語で収集・蓄積する、という構造になっています。

The NVD performs enrichment on CVEs that have been published to the CVE List. […] This enrichment results in association impact metrics (Common Vulnerability Scoring System – CVSS), vulnerability types (Common Weakness Enumeration – CWE), and applicability statements (Common Platform Enumeration – CPE), as well as other pertinent metadata. The NVD does not actively perform vulnerability testing

出典：NVD General Information（National Vulnerability Database, NIST）

公開から自社に情報が届くまでの時間差も確認しておきたい点です。JVN iPedia は「脆弱性対策情報が公表されてから一週間程度を目安に公開しています」と自ら説明しています。

ベンダー独自のデータベースを持ち、公開データベースより早く反映すると謳う製品もあるため、自社が求める速さに見合うかを見ます。経済産業省の手引は、データベースの選択をカバレッジ・迅速化・コスト効率の3観点から判断することを勧めています。参照先のデータベース名と反映の早さは、公式サイトに書かれていないことが多いので、資料請求や商談で直接聞く項目として控えておいてください。

出典・参考資料（2件）

• 出典：JVN iPedia とは？｜脆弱性対策情報データベース（IPA・JPCERT/CC）（jvndb.jvn.jp）
• 出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 7.4.1(3)「対象とする脆弱性DBの選択」p.63-64｜経済産業省（PDF）

優先順位付け（トリアージ）をどこまで自動化できるか

導入後にもっとも効いてくるのがこの観点です。検出件数は資産が増えるほど膨らみ、すべてに対応するのは現実的ではありません。日本シーサート協議会の手引書も「大量に報告される脆弱性のすべてに対応するのは非現実的であり、各組織においてどのような脆弱性に対応するかの判断基準が必要となる」と述べています。

出典・参考資料（1件）

• 出典：脆弱性管理の手引書（Ver.1.1）公開版 ■システム管理者 編 p.4｜一般社団法人日本シーサート協議会 脆弱性管理WG（公開資料一覧）

ここで確認したいのは、判定に何を使っているかです。CVSS のスコアだけで並べ替える製品と、悪用の実態を示す指標や自社環境での到達可能性まで加味する製品では、絞り込みの精度が変わります。指標そのものの使い分けは運用の回し方で詳しく扱いますが、選定時には自動で仕分けてくれるのか、判定材料を並べるだけなのかを見分けておくと、導入後の工数見積もりがぶれません。

SBOM の生成・取り込み・出力にどこまで対応するか

SBOM 対応は「対応・非対応」の二択ではありません。自社のソフトウェアから SBOM を作る（生成）、取引先から受け取った SBOM を読み込む（取り込み）、指定された形式で書き出す（出力）の3つは別の機能で、対応状況が食い違う製品が珍しくありません。経済産業省の手引も、この非対称性を指摘しています。

SBOMの作成に関しては、大半のSBOMツールが複数のSBOMフォーマットをサポートしているが、SBOMのインポートに関しては、複数のSBOMフォーマットに対応している製品は多くない。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.2「SBOMツールの選定」p.39-43（経済産業省、令和6年8月29日）

サプライヤーから SBOM を集める立場なら取り込み対応が要り、納品する立場なら指定形式での出力が要ります。どちらの立場になるかを先に決めてから確認してください。

既存の資産管理・チケット・開発フローとの連携

検出した脆弱性を誰かが直すには、その情報が普段使っている場所に届く必要があります。課題管理ツールへのチケット自動起票、チャットへの通知、構成管理データベースとの資産突合、CI/CD への組み込みといった連携が、実際の対応スピードを決めます。

連携先の名前が並んでいるだけで満足せず、双方向なのか一方向なのかも確認しておくと安心です。チケットを起票できても、そちらで完了にしたステータスがツール側に戻らなければ、結局は二重管理になります。この点も製品ページでは分からないことが多いため、自社が使っているツール名を挙げて確認するのが確実です。

対応の進捗を回す機能（担当・期限・ステータス）

検出一覧を出すところまでは多くの製品ができますが、そこから先の作りには差があります。脆弱性ごとに担当者と期限を割り当てられるか、対応済み・対応不要・保留といった状態を記録できるか、対応不要と判断した根拠を残せるか。監査や報告の場面では、この記録が求められます。

日本シーサート協議会の手引書は、対応の実行をモニタリングし続ける重要性と、ダッシュボードの活用まで踏み込んで述べています。管理画面で「今どれだけ残っているか」が一目で分かるかは、経営層への報告のしやすさにも直結します。画面の作りは資料や無料トライアルで実物を見るのが早いので、候補が絞れた段階で触ってみてください。

料金体系が自社の資産の増え方と合うか

課金単位が自社の成長の仕方とずれていると、数年後に費用が想定外に膨らみます。資産数で課金される製品はサーバーを増やすほど、開発者数で課金される製品はチームを増やすほどコストが上がります。どちらが自社にとって読みやすいかを、現在の金額だけでなく3年後の姿で見比べてください。費用の考え方は料金の章で詳しく扱います。

日本語での情報提供と国内サポート

脆弱性管理は日々の運用なので、情報が読めるかどうかが継続性を左右します。管理画面が日本語か、脆弱性の解説や対処方法が日本語で提供されるか、問い合わせ窓口が国内にあるか。これらは製品によって、また同じ製品でも本体と国内代理店で状況が違います。

現状のところ、海外で開発されたSBOMツールがほとんどである。そのため、取扱説明書やREADMEファイルが英語のみで提供されているケースがあるほか、ツール自体も日本語対応していない場合がある。英語のみで提供されているツールの運用が困難である場合には、自組織のSBOM導入の目的やその他の観点を踏まえて検討した上で、日本語対応しているツールの優先度を高めることが考えられる。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.2「SBOMツールの選定」p.39-43（経済産業省、令和6年8月29日）

代理店が日本語サポートを提供している場合、それが本体の標準機能ではなく、代理店の付帯サービスであることもあります。契約先がどちらになるのかを確認しておくと、後の窓口対応で迷いません。

【比較表】脆弱性管理ツール20サービスをタイプ別に比較

ここからは、掲載20サービスをタイプ別に横並びで比較します。守れる対象、SBOM 対応の内訳、優先順位付けの方式、料金と課金単位、日本語での情報提供とサポートの5点を、各社の公式情報で確認できた範囲で記載しました。公式に記載がない項目は、推測で埋めず「公式に記載なし」と明示しています。

無料で使える OSS ツールは、料金やサポートを横並びにできないため表には含めず、料金の章でまとめて扱います。

【比較表】自社コードのOSS依存まで見て、修正まで導くタイプ（7サービス）

自社でプロダクトを開発しており、依存ライブラリの脆弱性を開発フローの中で潰したい企業向けの7サービスです。

※2026年8月時点で各社の公式サイト・公式ドキュメントに記載を確認できた情報をまとめています。海外ベンダーの円建て価格は国内代理店が独自に設定しているもので、本体の公開価格とは含まれる条件が異なる場合があります。

【比較表】IT資産全体をまたいで一元管理するタイプ（6サービス）

サーバーからクラウド、ネットワーク機器までを1つの画面で把握したい情報システム部門向けの6サービスです。

※2026年8月時点で各社の公式サイト・公式ドキュメントに記載を確認できた情報をまとめています。別製品・別モジュール扱いの機能、提供が終了した機能は、その旨を書き分けています。

【比較表】サーバー・機器の脆弱性情報を日本語で追い切るタイプ（2サービス）

脆弱性情報の収集と影響判定を日本語で完結させたい企業向けの2サービスです。

※2026年8月時点で各社の公式サイト・公式ドキュメントに記載を確認できた情報をまとめています。

【比較表】製品や取引先に出すソフトウェアのSBOMを作って管理するタイプ（4サービス）

取引先や規制から SBOM の提出を求められている企業、製品にソフトウェアを載せるメーカー向けの4サービスです。また、サーバー側の管理を兼ねる製品では MIRACLE Vul Hammer も SBOM の生成・取り込み・出力に対応するため、社内 IT と出荷製品の両方を見たい場合は日本語で追い切るタイプの表も併せて確認してください。

※2026年8月時点で各社の公式サイト・公式ドキュメントに記載を確認できた情報をまとめています。SBOM 管理を主目的とする製品でも、生成・取り込み・出力の対応状況は製品ごとに異なります。

【比較表】外部公開資産の見えていない穴を洗い出すタイプ（1サービス）

把握できていない公開資産があるかもしれない、という不安から入る企業向けのサービスです。

※2026年8月時点で公式サイトに記載を確認できた情報をまとめています。同社は手動主体の脆弱性診断・ペネトレーションテストも提供していますが、本表は「ネットde診断 ASM」プランのみを対象としています。

脆弱性管理ツール20サービスを個別紹介

比較表で気になったサービスについて、対象範囲や料金、サポート体制をもう少し詳しく見ていきます。

【個別紹介】自社コードのOSS依存まで見て、修正まで導くタイプ（7サービス）

開発フローに組み込んで使う7サービスです。

1. Aikido Security（Aikido Security BV／株式会社AndGo）

ベルギーの Aikido Security BV が開発し、日本では株式会社 AndGo が正規代理店として提供しています。自社コードの OSS 依存を調べる SCA に加え、ソースコード自体の静的解析、コンテナイメージ、IaC（インフラの構成をコードで記述したもの）、クラウド設定の点検までを1つの管理画面に集約する構成です。

SCA 機能は SBOM を CycloneDX・SPDX・CSV の3形式で書き出せます。優先順位付けは、コードとインフラの文脈からアラートを評価する AutoTriage と、脆弱なコードへ実行パスが通っているかを判定する到達可能性解析の組み合わせで、到達しないと判定された検出は自動で優先度が下がります。修正案をプルリクエストとして起票する機能もあります。

本体の公開価格は、2ユーザーまで無料のプランのほか、Basic が月額300ドル（10ユーザー分を含む）、Pro が月額600ドルからです。

日本での提供価格は株式会社 AndGo が月額5万円台からと案内しており、請求書払いにも対応しますが、円建て価格に含まれる条件は公式に記載がないため問い合わせが必要です。日本語での導入・運用支援と、管理画面・ドキュメントの日本語対応は同社が2026年6月に発表しています。

検出した脆弱性が実際に修正されるまでの間にどこで止まるのかについて、日本提供元である株式会社 AndGo の原氏は次のように話しています。

2. Snyk（スニーク）（Snyk Limited）

2015年創業の Snyk Limited が開発する、開発者自身が使うことを前提としたセキュリティプラットフォームです。製品は OSS 依存関係を見る Snyk Open Source、自社コードを見る Snyk Code、コンテナ、IaC に分かれ、IDE や CI/CD に組み込んで開発の早い段階で検査します。日本では2022年2月から日本法人が国内向けの提供を本格化しました。

SBOM はコマンドラインまたは REST API 経由で、CycloneDX v1.4〜1.6と SPDX v2.3の形式に書き出せます。外部で作られた SBOM を取り込む機能については、公式ドキュメントに記載が見当たりません。優先順位付けは0〜1,000の Risk Score で、到達可能性解析・EPSS・CVSS・悪用の成熟度・依存関係の深さなどを合成して算出します。

料金は開発者数に応じた課金で、Free は無料ながら月間のテスト件数に上限があり、Team は年間契約で1開発者あたり月25ドルからです。課金対象の開発者は「過去90日間に非公開リポジトリへコミットした人」と定義され、公開リポジトリへのコミットは数えません。日本語のサイトと問い合わせ窓口は用意されていますが、対応時間や手段までは公式に記載がありません。

3. Black Duck SCA（Black Duck Software, Inc.）

2024年10月に Synopsys のソフトウェアインテグリティ部門が独立して発足した Black Duck Software, Inc.の主力製品で、社名も本製品に由来します。解析対象は依存関係にとどまらず、コピーされたコード片、ソースコードのないコンパイル済みバイナリやファームウェア、コンテナイメージまで広がります。

SBOM は SPDX・CycloneDX 形式での出力に加え、外部で生成された SBOM の取り込みにも対応します。優先順位付けには、公開データベースにない情報を含む独自の脆弱性情報 Black Duck Security Advisories（BDSA）を使います。到達可能性解析も備えますが、公式ブログは現時点で Java プロジェクトのみの対応と明記しています。

同ブログは、動的なコード読み込みや依存性注入では見逃しが生じうるため、到達可能性だけで対応の要否を決めないようにとも注記しています。料金は公式ページが見積もり依頼のみで、金額・課金単位ともに記載がありません。国内では株式会社 SRA、株式会社日立ソリューションズ、富士ソフト株式会社など複数の SIer が取り扱っており、製品自体の日本語対応については公式に記載がありません。

4. Mend.io（Mend Ltd.）

OSS 依存関係の SCA を起点に、自社コードの静的解析、コンテナイメージの検査、依存関係の自動更新、AI 利用のガバナンスまでを1つのプラットフォームにまとめた製品群です。運営はイスラエルと米国に拠点を持つ Mend Ltd.で、2022年5月に WhiteSource から現在の社名へ変更しました。

SBOM は SPDX 2.2・2.3と CycloneDX 1.4・1.5の形式で自動生成でき、Web 画面とコマンドラインの両方から出力できます。VEX（そのソフトウェアが特定の脆弱性の影響を実際に受けるかを伝える標準形式）データの組み込みと、第三者から受け取った SBOM の取り込みにも対応します。

優先順位付けは CVSS 単独ではなく EPSS を組み合わせ、コンテナイメージについては専用エージェントを入れずに、実行時に呼ばれるパッケージを静的解析で推定します。

公開価格は稼働開発者1人あたりの年額で、静的解析と SCA を含む Mend AppSec が最大1,000ドル、依存関係更新の Mend Renovate Enterprise が最大250ドルです。

日本では2026年6月から株式会社ジーグラビティが代理店となり、Mend AppSec を年額20万円（税別）とする円建てライセンスと日本語のアフターサポートを独自に用意しています。2つの価格体系の対応関係は公式に示されていないため、人数条件は問い合わせで確認してください。

5. Sonatype Lifecycle（Sonatype, Inc.）

Apache Maven の開発者らが2001年に立ち上げた Sonatype, Inc.の SCA 製品で、旧称は Nexus Lifecycle です。中核はポリシーによる制御で、18種類の初期ポリシーと30以上のカスタマイズ可能な制約条件を持ち、IDE やソースコード管理と連携して最初のコミット段階でポリシー違反を指摘します。

SBOM は直接・推移的な依存関係を含めて自動生成され、任意形式での取り込みにも対応します。ただし CycloneDX・SPDX での一元管理や、複数チームにまたがる継続的な運用は別製品の Sonatype SBOM Manager が担う区分です。

優先順位付けは独自の脆弱性情報をもとに、到達可能性・破壊的変更の有無・アップグレードの可否を組み合わせて判定し、上げ先がないものには自動で例外（Waiver）が付きます。

料金は公式に定価がなく要問い合わせで、課金はソフトウェア成果物を作成・利用・評価する人数を数えるライセンスユーザー単位の年間契約です。日本語ページや日本語サポートについての記載は公式サイトで確認できず、国内では再販代理店を通じた問い合わせになります。閉域網での運用が求められる場合に向けて、オフライン環境向けの提供形態も用意されています。

6. FOSSA（FOSSA, Inc.）

OSS ライセンスの順守管理を起点に、脆弱性管理と SBOM 管理まで扱うプラットフォームです。パッケージ経由の依存関係のほか、コンテナ、外部から受け取った SBOM、コンパイル済みバイナリ、コードスニペットの一致を横断してスキャンします。一方で自社が書いたコード自体の脆弱性診断は対象外であることを公式ブログで明言しており、その領域は別ツールとの併用が前提になります。

SBOM は SPDX と CycloneDX で生成でき、標準形式での取り込みにも対応します（対応する版数は公式に記載なし）。優先順位付けは、NVD・GitHub Security Advisories・OSV・独自データベースを統合したうえで、CVSS と EPSS に到達可能性解析を組み合わせます。ポリシーエンジンは拒否・フラグ・承認の3アクションで自動的に振り分けます。

本社と直接契約する場合は、無料プラン（プロジェクト5件・開発者10名まで）、プロジェクト単位で月20ドルの Business、要問い合わせの Enterprise に分かれます。

日本では株式会社日立ソリューションズが2020年6月から販売代理店を務めています。価格は開発者1名あたり年額で、Compliance が18万円（35名から）、Compliance + Security が25万円（25名から、いずれも税別）。30日間の無償トライアルも案内されています。最小契約人数が設定されているため、少人数のチームでは条件の確認が要ります。

7. FossID（FossID Aktiebolag／テクマトリックス株式会社）

コードスニペット単位での OSS 検出を前面に掲げた SCA ツールです。開発はスウェーデンの FossID Aktiebolag で、国内の販売とサポートはテクマトリックス株式会社が担います。検出の粒度はコンポーネント全体、ファイル単位、コードスニペット単位の3段階に分かれ、部分的にコピーされたコードの一致まで探せます。

SBOM は SPDX・CycloneDX などの国際フォーマットでのレポート出力に対応します。取り込み機能については日本語の公式ページに記載がなく、国内提供版に含まれるかは確認が要ります。脆弱性は NIST が公開する CVE に基づいて表示され、脆弱性を含むコードスニペットを特定する VulnSnippet Finder は有償オプションという位置づけです。

料金は非公開で、2025年1月から Contributor 単位のライセンス体系に変わったと案内されていますが、Contributor の定義は公式ページに記載がありません。体験版の申し込み導線はあるものの、期間や条件までは確認できません。公式の事例ページには、オリンパス株式会社、ブラザー工業株式会社、株式会社デンソーなどの導入企業が掲載されています（社数の公表はなし）。

【個別紹介】IT資産全体をまたいで一元管理するタイプ（6サービス）

層をまたいで資産と脆弱性を突き合わせる6サービスです。

8. yamory（株式会社アシュアード）

ビズリーチを運営する Visional グループの株式会社アシュアードが提供する脆弱性管理クラウドです。ソフトウェアの依存関係からホスト OS、コンテナ、クラウド設定までを1つの画面で管理でき、依存関係の解析は C/C++、Java、Python、Go など14言語に対応します。公式サイトはネットワーク機器を含む全レイヤー対応と説明していますが、対応機器や検知方式の記載は確認できませんでした。

SBOM は構成情報の取り込みと書き出しの双方に対応し、2023年4月から SPDX・CycloneDX 形式で出力できます。両形式の出力を追加費用なく使えるのは CSIRT/PSIRT プランと Enterprise プランで、下位プランでの可否は公式に記載がありません。

優先順位付けは特許を取得したオートトリアージ機能が担い、CVSS の深刻度に、対象システムが外部からアクセスできるかという使用状況と、攻撃コードが出回っているかを掛け合わせて対応順を自動判定します。料金は初期費用・月額とも非公開で要問い合わせです。日本語での導入支援と運用定着支援を専任スタッフが行うと公式 FAQ に記載がありますが、対応時間帯までは公開されていません。

9. FutureVuls（フューチャー株式会社）

オープンソースの脆弱性スキャナ Vuls を開発したフューチャー株式会社が、それを基盤に商用サービスとして仕立てた脆弱性管理ツールです。OS からミドルウェア、アプリケーションのライブラリ、コンテナイメージ、ネットワーク機器、WordPress までを対象とします。

スキャン方式は、サーバー上で動かすローカルスキャン、SSH 経由のリモートスキャン、画面登録だけで済む CPE スキャン（製品名とバージョンの共通識別子を突き合わせる方式）を使い分けられます。

SBOM は CycloneDX・SPDX 形式の取り込みと書き出しに対応し、PSIRT プランでは画面に登録したソフトウェア情報から SBOM を自動生成できます。優先順位付けには CVSS・EPSS・CISA の KEV カタログを用い、CSIRT プランでは米 CISA が推奨する SSVC で対応優先度を Immediate から Defer までの4段階へ自動で振り分けます。

料金は公式に金額の記載がなく要見積もりで、Standard プランは月単位、CSIRT・PSIRT プランは年単位の契約となります。CSIRT・PSIRT プランは最小100ライセンスからの案内のため、小規模で始めたい場合は個別相談が前提です。日本語のマニュアルサイトが公開されており、開発エンジニアが直接サポートすると公式 FAQ に記載があります。

10. Tenable Vulnerability Management（Tenable, Inc.）

Tenable One という統合プラットフォームの中核として提供されるクラウド型の脆弱性管理製品で、開発元は米 Tenable, Inc.、旧称は Tenable.io です。サーバー OS、ネットワーク機器、AWS・Azure・Google Cloud などのクラウドリソースを、エージェント、API 経由のエージェントレス、ネットワークスキャナーの3方式を組み合わせて評価します。

対応範囲には注意が要ります。Web アプリケーション診断は Tenable Web App Scanning、OT 環境（制御システムの領域）は Tenable OT Security という別モジュールで、いずれも個別課金です。SBOM も本体での生成・取り込みは公式に記載がなく、CycloneDX 形式の書き出しは別製品 Tenable Enclave Security の機能とされています。

優先順位付けは、NVD から取得した CVSS に、独自スコアの VPR（同社が悪用実績や脅威情報を加味して算出する優先度）と EPSS を併用します。料金は資産単位の年間サブスクリプションで、オンラインで購入できる100資産・1年契約は3,700米ドルからです。250資産を超える規模は問い合わせとなり、日本円建ての価格は公開されていません。

公式のテクニカルサポートは、全プランで英語でのやり取りが条件と明記されています。日本語の導入支援や運用サポートは国内代理店が別途用意するメニューにあたるため、契約先と費用負担を確かめておく必要があります。

11. Qualys VMDR（Qualys, Inc.）

製品名の VMDR は Vulnerability Management, Detection and Response の略で、資産と脆弱性の検出から優先順位付け、パッチ適用までを1つの基盤で完結させる構成です。提供元は米 Qualys, Inc. で、仮想スキャナ、軽量エージェント、パッシブセンサー、コンテナセンサーを使い分け、オンプレミス・クラウド・コンテナ・モバイルの資産を把握します。

SBOM は Software Composition Analysis（SwCA）機能が担い、OSS コンポーネントを検出し CycloneDX 1.4・1.6 形式で書き出せます。SPDX 形式への対応は公式に記載がありません。優先順位付けは独自スコアの TruRisk で、25以上のリアルタイム脅威インテリジェンスと EPSS を組み合わせ、MITRE ATT&CK とも連携します。

気をつけたいのは契約範囲です。SwCA やコンテナセキュリティ、パッチ管理が VMDR の基本ライセンスに含まれるのか別モジュールなのかは、公式ページで明示されていません。料金も非公開で、国内代理店の株式会社ラックは診断対象 IP アドレス数をもとにした個別見積もりと案内しています。30日間の無料トライアルがあり、日本語サポートは代理店経由が中心です。

12. Rapid7 InsightVM（Rapid7, Inc.）

現在は上位プラットフォーム Rapid7 Exposure Command の構成要素として提供されている、米 Rapid7, Inc. の脆弱性管理製品です。認証情報を使える資産には Insight Agent、そうでない資産にはネットワーク越しのスキャンエンジンという役割分担で、サーバー・ネットワーク機器・エンドポイントを評価します。

対応範囲はここ数年で整理が進みました。コンテナセキュリティとクラウド設定評価は2025年3月5日に InsightVM 単体からの提供が終了し、別製品の InsightCloudSec または Exposure Command 側へ移っています。Web アプリの動的診断も別製品 InsightAppSec の担当で、SBOM は InsightVM 本体での対応を公式に確認できませんでした。

優先順位付けは、従来の Real Risk Score から算出方式を刷新した Active Risk へ2026年2月に統一されました。CVSS を基点に、Metasploit や ExploitDB が示すエクスプロイトの有無、CISA の KEV リスト、AttackerKB の評価などを組み合わせ、0〜1000の幅で採点します。

修復側ではパッチなど対応手順の単位でプロジェクトを組み、Jira や ServiceNow と連携して担当と進捗を追えます。

料金は資産数に応じた課金で金額は非公開、現行の販売は Exposure Command Essentials と Ultimate の2パッケージが中心です。国内ではソフトバンク株式会社のマネージドサービスや代理店経由での提供もあるため、日本語サポートの範囲は契約先で変わります。Rapid7 公式のサポート対応時間・手段は公式サイトに記載がありません。

13. Wiz（Wiz, Inc.）

2026年3月11日に Google による買収が完了したクラウドセキュリティ基盤です。買収後もブランドを維持し、AWS・Microsoft Azure・Oracle Cloud Infrastructure など複数のクラウドへの対応を続ける方針が公式に発表されています。

製品は、開発工程を見る Wiz Code、クラウド環境を見る Wiz Cloud、稼働中の脅威を検出する Wiz Defend の3区分です。クラウド設定、仮想マシン、コンテナと Kubernetes、サーバーレス、自社コードの依存関係までを、API 接続だけで動くエージェントレススキャンで把握します。

リアルタイムの検知が必要な場合は、eBPF（Linux カーネル内で監視処理を動かす仕組み）ベースの Wiz Sensor を追加します。SBOM もエージェントレスで生成でき、SPDX と CycloneDX の両形式で書き出せます。

優先順位付けには Security Graph と呼ぶ仕組みを使い、コード・クラウド・稼働環境の情報をつないだうえで、攻撃経路として成立するものを優先します。料金は非公開で、ワークロード数・開発者数・ログ取り込み量・センサー数に応じて増減するモジュール型のライセンスとだけ示されています。

国内では日本法人の Wiz Cloud Japan K.K. が窓口となり、2024年12月からは東京・大阪リージョンでのテナント作成にも対応しています。ただし製品画面とサポート窓口の日本語対応可否は公式に記載がなく、導入支援は国内のパートナー各社が提供する形です。

【個別紹介】サーバー・機器の脆弱性情報を日本語で追い切るタイプ（2サービス）

日本語での情報提供に強みを持つ2サービスです。

14. SIDfm VM（株式会社サイバーセキュリティクラウド）

SIDfm は1999年にソフテックが始めた脆弱性情報提供サービスで、同社を2022年に吸収合併した株式会社サイバーセキュリティクラウドが現在は運営しています。SIDfm VM はそのブランドのなかで、IT 資産の脆弱性を自動検出し、対応状況をチケットとして管理するところまでを担う製品です。

対象は Red Hat Enterprise Linux や Windows Server などのサーバー OS、Apache Struts といったミドルウェア、Cisco IOS などの機器搭載ソフトウェアです。ネットワーク機器は2025年3月に追加された SSH/SNMP でのエージェントレス検出で拾います。コンテナを独立した対応レイヤーとして挙げた記載は、公式サイトにはありません。

SBOM は取り込み側の対応です。syft・Trivy・Amazon Inspector などで生成した SPDX（2.2〜2.3.1）と CycloneDX（1.1〜1.4）のファイルをホスト単位でインポートし、脆弱性データベースと突き合わせて対応状況を追跡します。SBOM を生成・出力する機能については公式に記載がありません。

優先順位付けは、CVSS に加えてホストの設置場所や攻撃コードの有無を加味する独自指標 SRI を併用し、それぞれにしきい値を設定して自動でトリアージする方式です。通知にはアナリストによる日本語の解説が付き、電話サポートの対応時間は平日9:30〜12:00と13:00〜17:30です。料金は年額60万円（税別）からで、初期費用は公式に記載がなく問い合わせが必要です。

15. MIRACLE Vul Hammer（サイバートラスト株式会社）

公式サイトが前面に置いているのは、複数ベンダー・複数形式の SBOM を1つの基盤にまとめる役割です。MIRACLE LINUX を展開するサイバートラスト株式会社の製品です。2021年にオンプレミス版として提供が始まり、2024年10月に SBOM 統合管理を強化した SaaS 版が加わりました（SaaS 版は申込から最短3営業日で利用開始と案内されています）。

SBOM は生成・取り込み・出力の3方向に対応します。生成形式は SPDX 2.3 と CycloneDX 1.4/1.5/1.6、取り込みは trivy・syft・alma-sbom・FossID など他社ツールの出力ファイルで、生成した SBOM は JSON で書き出せます。ソースコードが手元になくても、Insignary Clarity 連携でバイナリから生成できます。

対応レイヤーは、MIRACLE LINUX・RHEL・AlmaLinux・Rocky Linux・Ubuntu などの Linux と Windows Server 2019/2022 です。Yocto や FreeRTOS といった組込み環境も対象に含まれます。さらにパッケージマネージャ経由で11言語のコンポーネントも対象です。

スキャンは SSH/WinRM で接続するエージェントレス方式が基本で、SBOM 生成とパッケージ更新のときだけエージェントを併用します。

優先順位付けには CVSS のほか、実際の悪用が確認された脆弱性のリストである KEV と、悪用確率を予測する EPSS を組み合わせます。料金は現行の公式サイトに記載がなく、問い合わせによる見積もりになります。サポートは契約期間中のカスタマーポータル経由の技術サポートで、対応時間帯は公式に記載がありません。

【個別紹介】製品や取引先に出すソフトウェアのSBOMを作って管理するタイプ（4サービス）

SBOM の作成と提出を軸にした4サービスです。

16. SBOM管理システム（株式会社日立ソリューションズ）

取引先やツールごとに形式の異なる SBOM を取り込み、一元管理することを中核に据えたプラットフォームです。株式会社日立ソリューションズが2026年6月24日に提供を開始しました。EU サイバーレジリエンス法（CRA）などの規制対応を訴求点に掲げています。

取り込めるのはSPDX・CycloneDX の標準形式に加え、顧客独自の Excel 様式です（SWID への対応は公式に記載なし）。管理対象は OSS だけでなく COTS 製品（市販の既製ソフトウェア）・プロプライエタリソフトウェアにも及びます。一方、製品自体が SBOM を新規に生成する機能については公式に記載がありません。

取り込んだ構成情報には CPE などの識別子を自動で付与し、脆弱性データベースを継続監視して影響が判明した時点で通知します。検知後は Jira Service Management とのネイティブ連携で担当割当から解決までのステータスを管理でき、ServiceNow や OWASP の Dependency-Track とも連携します。ただし、優先順位付けの計算ロジックは公式に記載がありません。

料金は公式に記載がなく、要問い合わせです。無償トライアルと製品デモを申し込めるほか、SBOM の導入支援・ガイドライン策定支援・作成代行が別メニューとして用意されています。画面と問い合わせは日本語・英語に対応します。ただし同社は他社製の構成分析ツールの国内販売代理店も務めているため、本システム単体の機能と取扱製品の機能は分けて確認する必要があります。

17. SBOM Archi（株式会社AGEST）

株式会社 AGEST が開発・保守する国産の脆弱性リスク管理ツールで、2026年1月5日に提供を開始しました。脆弱性に加えて、OSS のライセンス違反と EOL/EOS（サポート終了）のリスクも同じ画面で扱う設計です。2026年4月にはバージョン2.0がリリースされています。

SBOM は作成と取り込みの両方に対応します。作成はオンプレミスに置くスキャナがサーバーをスキャンする方式で、バージョン2.0では API 経由での SBOM アップロードが加わりました。対応フォーマット（SPDX・CycloneDX・SWID）と対応レイヤーについては、公式に記載がありません。

リスク評価には CVSS に加えて EPSS（悪用される確率を予測する指標）を併用します。レコメンド機能では、仮想の SBOM 上でコンポーネントの入れ替えやバージョンアップを試し、改善効果・影響範囲・対応工数の見積りを確認できます。組織・チーム・プロジェクト単位の管理と、重大な脆弱性の使用箇所を組織横断で追跡する機能も備えます。

料金は情報源によって月額・管理台数ベースと年額・SBOM 登録件数ベースの2系統が示されており、公式サイト上では金額を確認できません。契約経路による違いの可能性があるため、直接の確認が要ります。無料トライアルは2週間です。問い合わせ窓口は電話（平日9:30〜18:00）とフォームで、メニュー・サポートとも日本語で提供されます。

18. SBOM.JP（株式会社ベリサーブ）

ソフトウェアサプライチェーン管理のパッケージとして、株式会社ベリサーブが2024年10月に提供を開始した SaaS です。サプライヤーから提供された SBOM を集約してバージョンと脆弱性を一元管理し、OSS・商用ソフトウェア・独自開発のソースコードを含むソフトウェア資産全体を管理対象としています。

脆弱性情報と自社 SBOM の突き合わせに生成 AI を使う点が特徴です。SBOM に CPE などの詳細が欠けていても、外部の CPE・CVE データベースと照合する工程を生成 AI が補います。2026年7月31日には、LLM が脆弱性関連情報を収集・要約し、影響範囲と対応方針を提示する AI エージェント機能が加わりました。

全機能が API 化されており、基幹系システムとの連携が可能です。一方、対応する SBOM フォーマット、参照する脆弱性データベース、優先順位付けの指標はいずれも公式に記載がなく、自社側で SBOM を新規生成できるかも明示されていません。料金は非公開で要問い合わせ、無料トライアルは申込フォームから受け付けています。

19. Cybellum（Cybellum Technologies LTD）

自動車・医療機器・産業機器といったコネクテッド製品のメーカーに向けて、SBOM 管理から脆弱性管理、規制対応、インシデント対応までを1つに統合した Product Security Platform です。イスラエル・テルアビブに本社を置く Cybellum Technologies LTD が開発しています。

中核技術の Cyber Digital Twins は、ファームウェアのバイナリを自動解析して SBOM を生成します。ソースコードや既存の SBOM が手元にないレガシーな組込製品でも構成を把握でき、ライセンス・OS 設定・API 呼び出し・暗号処理までを検出対象に含みます。SBOM は SPDX・CycloneDX・SWID タグに対応し、形式の異なるものを取り込む際に正規化して統合します。

検出した脆弱性は製品アーキテクチャの文脈で悪用可能性を判定し、VEX レポートとして自動生成します。ただし、スコアリングの具体的なアルゴリズムは公開されていません。対応を掲げる規制は、自動車の UN-R155・ISO/SAE 21434、医療機器の FDA 市販前ガイダンス、重要インフラの EU CRA・IEC 62443 です。

料金は非公開で、デモ予約を経た個別見積もりとなります。日本市場には東京・丸の内の自社オフィスがあり、2025年3月には eSOL TRINITY 株式会社が国内代理店契約の締結を発表しています。公式サイトには日本語表示の切り替えがありますが、日本語サポートの対応時間は公式に記載がありません。

【個別紹介】外部公開資産の見えていない穴を洗い出すタイプ（1サービス）

未把握の公開資産を見つけるサービスです。

20. GMOサイバー攻撃 ネットde診断 ASM（GMOサイバーセキュリティ byイエラエ株式会社）

外部に公開している Web サイトや VPN 機器の脆弱性を、資産の棚卸から継続的に可視化する SaaS 型の ASM ツールです。GMO インターネットグループのセキュリティ専門会社が提供しており、ドメイン・IP アドレス・サブドメインの洗い出しから始まるため、社内で把握できていない公開資産の発見にも使えます。

診断対象はグローバル IP アドレスを持つ外部公開サイトに限られ、プライベート IP や LAN 内のサイトは対象外です。パッシブスキャンとアクティブスキャンの両方に対応し、自動の定期診断に加えて任意のタイミングでも実行できます。検出した脆弱性には自動で優先度が付与され、重大なものはメールで通知されます。ダークウェブ上への認証情報の漏洩監視も機能に含まれます。

料金は自走プランが月額4万円から、伴走プランが月額12万円からの2プランです。レポートは CSV と PDF で出力でき、セキュリティ専門家によるコンサルティング支援も用意されています。SBOM の生成・取り込みと、問い合わせ窓口の対応時間については、公式に記載がありません。

脆弱性管理ツールの料金と、無料・OSSで足りるかの判断

脆弱性管理ツールの価格は公開されていないものが多く、相場という言い方がしにくい領域です。一方で、費用が何に比例して増えるかという構造は共通しているため、そこを押さえれば予算の目安は立てられます。

課金単位のパターン

経済産業省の手引は、SBOM ツールの費用について次のように整理しています。

有償のSBOMツールの場合、ツールのライセンス費用が必要となる。ツールによって料金体系は異なるが、多くのツールが年間のサブスクリプションモデルで提供している。（中略）また、ライセンス費用の算出方法は、開発者数や組織の規模、解析コード量に応じた課金等、ツールによって様々であり、高額であっても会社全体で導入する場合にスケールメリットが出る場合もある。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.2「SBOMツールの選定」p.39-43（経済産業省、令和6年8月29日）

実際の製品を見ると、課金単位は大きく3つに分かれます。管理対象の資産数やホスト数で課金するもの、開発者数やリポジトリ数で課金するもの、機能セットごとの年間サブスクリプションで課金するものです。資産全体を管理するタイプは1つ目、開発フローに組み込むタイプは2つ目が中心になります。

自社にとって読みやすいのはどれかを考えるとき、判断材料になるのは「今後3年で何が増えるか」です。サーバーは横ばいでも開発チームが増える見込みなら、開発者数課金は将来の負担が大きくなります。逆にクラウド移行でインスタンスが増える計画があるなら、資産数課金は上振れしやすくなります。

費用を左右する要素

同じ課金単位でも、次の3点で見積もりは変わります。

• 管理対象の規模：資産数・開発者数がそのまま単価に掛かります。無料枠や最小契約数が設定されている製品もあるため、小規模で始めたい場合は下限を確認してください
• 対象レイヤーの広さ：コンテナやクラウド設定、ネットワーク機器への対応が上位プランや別製品になっている場合、必要な層を揃えると当初見積もりから跳ね上がります
• サポート範囲：日本語サポート、導入支援、専任担当の有無で価格帯が分かれる製品があります。国内代理店経由の場合は、本体ライセンスと代理店サポートの費用が別建てになることもあります

公開価格を出している製品は限られるため、複数社の資料を並べて比べるのが結局は近道です。

公開されている価格はどのくらいか

本記事の掲載20サービスのうち、提供元の公式サイトまたは公式に案内されている国内代理店のページで金額を確認できたのは7サービスです。残る13サービスは要問い合わせで、金額が公開されていません（SBOM Archi のように、販売店の資料で異なる価格体系が示されているものもあります）。公開されている分だけを課金単位ごとに並べると、次のようになります。

※2026年8月時点で各社の公式サイトおよび国内代理店の公開情報から確認できたものです。掲載のない13サービスは公式に金額の記載がありません。実際の費用は構成・規模・契約期間で変わるため、各社にご確認ください。

この分布から読み取れるのは、開発フローに組み込むタイプは開発者1人あたり月25ドル前後から始められる一方、資産数で課金するタイプは100資産で年間数千ドルという桁になる、という違いです。サーバー数十台規模で資産課金の製品を検討するなら年間で数十万円から、開発者単位の製品なら1人あたり月25ドル前後から、が出発点の目安になります。

ただし、この目安は最小構成の話です。コンテナやクラウド設定を別製品で足す場合、日本語サポートを代理店経由で付ける場合、最小契約数の下限に届かず切り上げになる場合は、いずれも上振れします。社内で提示する金額は、必ず自社の構成で見積もりを取ってください。

無料・OSSでできること

OSS の脆弱性スキャナや SBOM 生成ツールは複数あり、基本的な処理は無料でも実行できます。

用途別に代表的なものを挙げます。コンテナイメージや依存ライブラリのスキャンには Trivy や Grype、SBOM の生成には Syft。取り込んだ SBOM の管理と脆弱性の突合には Dependency-Track、Linux サーバーの構成スキャンには Vuls があります。

このうち SBOM の生成を担う Trivy と Syft は SPDX・CycloneDX の両形式に対応し、Dependency-Track は CycloneDX を中心に扱います。

検証環境で使い勝手を確かめたい段階や、まず自社の構成を可視化してみたい段階では、有力な選択肢になります。

商用製品にも無料枠があります。本記事の掲載サービスでは、2ユーザーまで無料（Aikido Security）、プロジェクト5件・開発者10名まで無料（FOSSA）、月間のテスト件数に上限を設けた無料プラン（Snyk）といった枠が公開されています。小規模なチームなら、その範囲で運用を始められます。人数が増える見込みがあるなら、上限を超えた後の単価も先に確認しておくと安心です。

商用ツールが必要になるのはどこからか

経済産業省の手引は、無償ツールの限界を具体的に挙げています。

有償のSBOMツールと比較して、無償のSBOMツールの機能・性能は限定的である場合が多く、例えば、再帰的な利用部品が検出できない、読み込み可能なSBOMフォーマットに制限がある、ライセンスの検知漏れが発生する、導入環境が限定される等の課題がある。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.2「SBOMツールの選定」p.39-40（経済産業省、令和6年8月29日）

同じ箇所では、無償ツールは「ツール自体のコストは無料であるものの、環境整備や学習に当たっての情報が不足しており、導入・運用に大きな工数を要する可能性がある」とも指摘されています。判断の目安は、次のどれかに当てはまるかどうかです。

• 間接的に依存している部品（依存の依存）まで漏れなく洗い出す必要がある
• 取引先から特定の形式で SBOM を受け取る、あるいは提出する必要がある
• 誰がいつまでに対応するかを記録し、監査や報告で示す必要がある
• 検出結果の判断を担当者の知識に頼らず、仕組みとして回したい

逆に、対象が限られていて、扱える担当者がいて、記録の要求もないのであれば、無償ツールで始めて必要になってから乗り換える進め方も現実的です。また、無償ツールは活発に開発されており、機能が向上していく可能性がある点も手引が触れています。

脆弱性管理ツールを導入するメリットと、放置した場合のリスク

稟議では「入れると何が良くなるのか」と「入れないと何が起きるのか」の両方が問われます。ここでは、その2つを整理します。

手作業の運用と比べて何が変わるか

ツールを入れると、冒頭で挙げた手作業の運用に対して次の3点が変わります。

• 情報収集が自動になる：脆弱性情報を人が探しに行くのをやめ、自社の構成に影響するものだけが届くようになります
• 影響範囲が即座に分かる：新しい脆弱性が公表されたとき、どのサーバーやどの製品に含まれているかを検索で答えられます。経済産業省の手引が SBOM の効果として挙げているのも、まさにこの即応性です
• 対応漏れが可視化される：誰の担当で、いつまでに、どこまで進んだかが記録として残り、報告のたびに集計し直す必要がなくなります

脆弱性を放置した場合に起きること

IPA の「情報セキュリティ10大脅威 2026」では、「システムの脆弱性を悪用した攻撃」が組織向けの4位に入っています。解説書は放置が危険な理由を次のように説明しています。

昨今、脆弱性の発見から、それを悪用した攻撃が発生するまでの時間が短くなっているため、脆弱性対策情報が公表された際には、早急な対策が必要である。／パッチや回避策が公開され、その適用や回避策を講じるまでの期間における脆弱性を N デイ脆弱性と呼ぶ。ソフトウェアの脆弱性管理が不適切な場合、未対策の期間が長くなり、被害に遭うリスクが大きくなる。／特に、ネットワーク機器 (VPN 機器等)や CMS（プラグインを含む）といったインターネットから直接アクセスできる製品・システムの脆弱性については、攻撃プログラム等が公開された場合に、多くの企業に被害が及ぶおそれがある。

出典：情報セキュリティ10大脅威 2026 解説書［組織編］p.21-23（独立行政法人情報処理推進機構、2026年3月）

この指摘は数字にも表れています。同じ解説書が警察庁の統計を引いて示したランサムウェアの感染経路では、2025年の内訳は VPN 機器経由が66.3%、リモートデスクトップ経由が20.7%で、両者の合計は87.0%に達します。この比率は2022年の80.4%から年々上がっています。インターネットに面した機器の脆弱性を残したままにすることが、そのまま侵入口になっている状況です。

出典・参考資料（1件）

• 出典：情報セキュリティ10大脅威 2026 解説書［組織編］p.34「ランサムウェアの感染経路の割合」（原典：警察庁「サイバー空間をめぐる脅威の情勢等」）｜独立行政法人情報処理推進機構（PDF）

脆弱性管理ツールを導入する前に押さえておく注意点

導入したのに効果が出ない例には共通する原因があります。いずれも選定時に確認しておけば避けられるものです。

誤検知・アラート過多で運用が止まる

導入後につまずきやすいのがこの点です。検出件数が担当者の処理能力を超えると、通知を見なくなり、やがて誰も開かない画面になります。経済産業省の手引も、ツール選定の観点として「OSS の検出や脆弱性情報・ライセンス情報のマッチングに当たって、どの程度の誤検出・検出漏れが生じうるかは一つの重要な指標である」と述べています。

出典・参考資料（1件）

• 出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.2「SBOMツールの選定」｜経済産業省（PDF）

この点について、株式会社 AndGo の原氏は次のように話しています。

選定時には、検出精度そのものに加えて「除外設定ができるか」を確認してください。使っていない機能に含まれる脆弱性や、既に別の手段で緩和済みのものを対象外にできれば、残る件数は現実的な水準に収まります。トライアルで自社環境をスキャンし、実際に出てくる件数を見てから決めるのが確実です。

既存のIT資産管理ツール・EDRとの機能の重なりをどう切り分けるか

すでに資産管理ツールやエンドポイント保護製品を導入している場合、「同じことができるのでは」という指摘が社内から出ます。ここで押さえておきたいのは、脆弱性管理と IT 資産管理が別のレイヤーとして設計されている、という前提です。日本シーサート協議会の手引書は、脆弱性管理を扱う前提を次のように置いています。

本ドキュメントでは脆弱性管理にフォーカスするため、ある程度のIT資産の識別（IT資産管理）がされている前提で脆弱性管理に必要なポイントを記載する。

出典：脆弱性管理の手引書（Ver.1.1）公開版 ■システム管理者 編 p.4（一般社団法人日本シーサート協議会 脆弱性管理WG、2024年10月25日公開）

このように、資産管理は脆弱性管理の土台であって、代わりになるものではありません。とはいえ製品によって守備範囲は違い、資産管理ツールが脆弱性情報との突合まで持つ場合もあります。一般論で線を引くより、次の手順で自社の状況に当てはめて確認するのが確実です。

1. 既存ツールが「資産の一覧を持つ」だけなのか、「脆弱性情報と突き合わせる」ところまでやっているのかを確認する
2. 突合まで行っている場合、対象範囲（OSだけか、ミドルウェアやOSS依存まで見るか）を確認する
3. 不足している範囲を洗い出し、その範囲を埋められる製品に絞って各社に「既存ツールとの併用時にどう役割分担するか」を質問する

対象資産の棚卸しが済んでいないと精度が出ない

脆弱性管理ツールは、把握できている資産に対して働きます。台帳から漏れているサーバーや、部門が個別に契約したクラウド環境は、そもそもスキャンの対象になりません。導入前に資産の棚卸しをどこまで進められるかが、初期の検出精度を決めます。

棚卸しが追いつかない場合の補い方として、外部から見える資産を自動で発見する ASM を併用する選択肢があります。同じ手引書も、外部ツールやサービスの活用によって現時点での設定や脆弱性の把握を補完できると位置づけています。

限られた予算の中で ASM と脆弱性診断のどちらから手を付けるかは迷うところです。両者が何をどこまで見るのかの違いと、自社の状況に応じた着手順の考え方は以下の記事で詳しく扱っています。

導入して終わりにしないための運用の回し方

ツールを入れても「情報は出るが誰も直さない」状態に陥ることがあります。そうならない運用像を、導入前に描いておきましょう。

収集 → 評価 → 対処 → 進捗管理の4ステップ

運用の骨格は4つの工程です。まず自社の構成に関わる脆弱性情報を集め、次に危険度と自社への影響を評価して対応するかどうかを決め、決めたものに手を打ち、最後に対応状況を記録して追跡します。IPA が挙げる対策の並び（脆弱性情報の収集、悪用状況の収集、優先度付け、対策状況の管理、パッチマネジメント）とも対応します。

この4つを1周させて終わりにせず、回し続けることが管理の本体です。日本シーサート協議会の手引書は、対応完了までに脅威の発生可能性や想定被害が変わることもあるため、定期的にリスクを再評価する必要があると述べています。

検出件数が多すぎるときの優先順位の付け方

優先順位づけの出発点は CVSS ですが、CVSS だけで判断すべきではないことは、規格を管理している FIRST 自身が明言しています。

The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.

出典：Common Vulnerability Scoring System version 4.0: User Guide「CVSS Base Score (CVSS-B) Measures Severity, not Risk」（FIRST.Org, Inc.）

CVSS の基本値が示すのは、その脆弱性が本来どれだけ深刻かという性質であって、自社が今どれだけ危ないかではありません。そこを補うために使われるのが、次の3つです。

• EPSS：公開済みの CVE が今後30日間に実際に悪用される確率を、機械学習で推定して0〜1の値で毎日公開する仕組みです。「攻撃されやすさ一般」ではなく、期間と対象が限定された確率である点が重要です
• KEV カタログ：米国 CISA が公開する、悪用が確認された脆弱性の一覧です。ここに載っているものは「理論上危ない」ではなく「実際に使われた」ものなので、対応の優先度が跳ね上がります
• SSVC：立場ごとに条件分岐をたどって対応区分を決める意思決定の枠組みです。スコアを出すのではなく、即対応・通常保守より優先・通常保守・対応保留のいずれかに振り分けます

経済産業省の手引も、CVSS を補完する位置づけでこれらを紹介しています。

VEXの取得が難しい場合には、米国CISAが提供する悪用が確認された脆弱性情報のカタログKEVC(Known Exploited Vulnerabilities Catalog)を活用することが想定される。また、CVSSは、比較的広く利用されているものの、脆弱性の実際の悪用状況が考慮されていないため、CVSSを補完する脆弱性の評価指標として、FIRST（Forum of Incident Response and Security Teams）が主導して策定されたEPSS（Exploit Prediction Scoring System）を利用することも考えられる。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 7.4.2 p.77-78（経済産業省、令和6年8月29日）

大切なのは、これらが CVSS を置き換えるものではないという点です。日本シーサート協議会の手引書もその旨をはっきり注意しています。ツールを選ぶときは、どの指標をどう組み合わせて自動で仕分けているかを確認し、自社の判断基準と噛み合うかを見てください。

出典・参考資料（3件）

• 出典：Exploit Prediction Scoring System (EPSS)｜FIRST（first.org/epss）
• 出典：SSVC — A Stakeholder-Specific Vulnerability Categorization｜CERT/CC, Carnegie Mellon University SEI（certcc.github.io/SSVC）
• 出典：脆弱性管理の手引書（Ver.1.1）公開版 ■システム管理者 編 p.25｜一般社団法人日本シーサート協議会（公開資料一覧）

対応が止まらないための体制と運用スキルの確保

ツールが出した結果を動かすのは人と組織です。日本シーサート協議会の手引書は、継続的に回すために必要な要素を4点挙げています。

・組織における脆弱性管理の位置づけ、判断基準、緊急時の態勢に関する経営層の合意 ・必要なスキルセットの整理と人材の育成 ・脆弱性管理に必要な手順の整理 ・脆弱性管理に必要なツール（連絡手段、管理・効率化ツール）の整備

出典：脆弱性管理の手引書（Ver.1.1）公開版 ■システム管理者 編 p.29（一般社団法人日本シーサート協議会 脆弱性管理WG）

とくに効いてくるのが判断基準の合意です。「CVSS 7.0以上は2週間以内」「KEV 掲載は即日」といった基準を事前に決めておけば、脆弱性が出るたびに関係者で議論する必要がなくなります。あわせて、対応しないと判断したものの根拠を残す運用を決めておくと、監査の場面で説明できます。

スキルセットを整理するとき必ず論点になるのが、どこまでを自社の手で回し、どこから外部に任せるかの線引きです。診断の側も項目によって内製できる範囲が分かれ、自動化ツールを CI/CD に組み込めば継続的に回せる部分もあります。可否の目安と組み込みの手順は以下の記事にまとめています。

人手の脆弱性診断をどこで挟むか

管理ツールを入れたら診断が不要になるわけではありません。両者は確度と対象が違うためです。

ASMでは、通常のアクセスの範囲で得られた情報をもとに、IT資産に含まれている可能性のある脆弱性情報を提示する。しかし、あくまで可能性のレベルであり、脆弱性を特定しているわけではない。一方で、脆弱性診断では、対象となるIT資産に攻撃を模したパケットを送信し、その応答を評価して脆弱性を特定する。よって、一般的には脆弱性診断のほうが脆弱性特定の確度は高い。

出典：ASM（Attack Surface Management）導入ガイダンス 2.4「ASMと脆弱性診断の違い」p.10（経済産業省、令和5年5月29日）

この確度の差を踏まえると、現実的な組み合わせは次のようになります。日常はツールで継続的に監視し、確度の高い検証が要る局面で人手の診断を挟む形です。

• 大きな改修や新サービスの公開前：構成が変わった直後は、既知の脆弱性の有無より実装上の欠陥のほうが問題になります
• 取引先や監査で診断結果の提出を求められたとき：ツールの検出一覧では要件を満たさない場合があります
• 年次など定期の棚卸し：ツールが拾えない設計・設定上の問題を洗い出す機会になります

ただし診断は、調査用のパケットが監視装置のアラートを鳴らしたり対象システムの動作に影響したりすることがあります。実施のタイミングは関係部署と調整してください。

もっとも、「日常はツール、要所は人手」というこの線引きは固定されたものではありません。AI の利用が広がるとどう変わるかについて、株式会社 AndGo の原氏は次のような見通しを語っています。

SBOM対応が求められる制度と、条文が実際に求めていること

SBOM への対応を検討する理由の多くは、取引先や制度からの要求です。ただし、どの制度が何を求めているかは、条文まで読むと「SBOM を作る・出す」と書いてあるものと、そこまでは書いていないものに分かれます。制度ごとに、条文が実際に求めていることを整理します。

経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0」

国内でまず参照されるのがこの手引です。2024年8月に ver2.0 が策定され、SBOM の定義から導入の進め方、ツール選定の観点、運用フェーズの実務までを扱っています。

注意したいのは、この手引が誰に向けたものかという点です。

本手引では、ソフトウェアサプライヤーにおける開発・設計部門や製品セキュリティ担当部門（PSIRT等）等のソフトウェアセキュリティに関わる部門と、経営層を主な対象としている。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 1.3「主な対象読者」p.4（経済産業省、令和6年8月29日）

主な想定はソフトウェアを供給する側です。ただし同じ節で、ソフトウェアを調達して利用する企業でも一部活用可能であると述べられており、SBOM を「求められる側」として読む使い方も想定されています。自社がどちらの立場で SBOM に向き合うのかを整理してから読むと、必要な章が絞れます。

SBOM に求められる最小要素

「SBOM を作る」と言ったとき、何が入っていれば SBOM と呼べるのかを定めたのが、米国商務省電気通信情報局（NTIA）が2021年7月に公表した最小要素の定義です。これは同年5月の米大統領令14028を受けて作られました。定義は3つのカテゴリーからなります。

Data Fields — Document baseline information about each component that should be tracked: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.

Automation Support — Support automation, including via automatic generation and machine-readability to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.

Practices and Processes — Define the operations of SBOM requests, generation and use including: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

出典：The Minimum Elements For a Software Bill of Materials (SBOM) p.3（The United States Department of Commerce / NTIA、2021年7月12日）

経済産業省の手引はこれを「データフィールド」「自動化サポート」「プラクティスとプロセス」と訳し、それぞれ「各コンポーネントに関する基本情報を明確化すること」「SBOM の自動生成や可読性等の自動化をサポートすること」「SBOM の要求、生成、利用に関する運用方法を定義すること」と説明しています。

実務で効いてくるのは3つ目です。ファイルを1回出力すれば済む話ではなく、更新の頻度や、どの深さまで部品をたどるか、記載できなかった部分をどう扱うかまで決めておく必要がある、という要求になっています。深さについて NTIA は、最低でもすべての最上位の依存関係を、間接的な依存関係を再帰的に追える程度の詳細さで記載すべきとしています。

大統領令14028そのものは、米国政府に納入するソフトウェアについて SBOM の提供を求める枠組みを定めたものです。購入者への SBOM 提供、あるいは公開ウェブサイトでの掲載を、政府調達に関わるガイダンスに含めるよう指示する構造になっています。日本企業に直接適用されるものではありませんが、米国政府向けの製品を扱う場合は関係します。

業種・取引先から求められる規制と適用時期

業種によっては、取引先や規制当局から具体的な要求が来ます。ここで注意が必要なのは、「SBOM が義務化された」と紹介されている制度の中に、条文を読むと SBOM という語が出てこないものがある点です。制度ごとの対象・適用時期と、条文が実際に求めていることを一覧にしました。

制度	対象	適用時期	条文が実際に求めていること
EU サイバーレジリエンス法（規則 (EU) 2024/2847）	EU 市場に出す、デジタル要素を持つ製品の製造者	2027年12月11日から適用（一部の条項は2026年6月・9月から）	脆弱性とコンポーネントを特定・文書化すること。その手段として、少なくとも製品の最上位の依存関係を対象とする SBOM を、広く使われる機械可読な形式で作成することが明記されている
PCI DSS v4.0 要件6.3.2	自社のために開発した、または自社開発ソフトウェアに組み込まれた第三者コンポーネント	2025年3月31日まではベストプラクティス、以降は必須	脆弱性管理とパッチ管理を進めるためのソフトウェア構成インベントリを維持すること。条文に SBOM の語はなく、SBOM はこれを実現する手段の一つという位置づけ
UN-R155 / UN-R156（車両のサイバーセキュリティ／ソフトウェアアップデート）	型式認証を受ける車両	国内では2022年7月から適用	条文に SBOM の要件は規定されていない。ただし UN-R155 が参照する ISO/SAE 21434 が、サポート終了まで構成情報を取得できることを要求事項とし、その例として SBOM を挙げている

車載分野については、経済産業省の手引が「当該規則において SBOM に係る要件は規定されていない」と明記しています。同じ箇所では、米国 NHTSA のガイダンス案に「OEM に対し、ECU や各車両に使用されるソフトウェアコンポーネントに関する SBOM の作成・維持を求める要件が含まれて」いることも紹介されており、今後推奨されていく見通しだとされています。

自社に対応が要るかどうかは、次のどれかに当てはまるかで見当が付きます。EU 市場にデジタル要素を持つ製品を出しているか。自社開発のソフトウェアでカード会員データを扱っているか。車両の型式認証に関わる部品やソフトウェアを供給しているか。米国で医療機器の市販前申請を行うか。米国政府に納入するソフトウェアがあるか。

いずれにも当てはまらない場合、制度を理由に SBOM の作成を急ぐ必要は現時点ではありません。取引先からの個別の要求があるかどうかを確認してください。

医療機器はもう一つの例外です。米国の連邦食品医薬品化粧品法524B 条は、ネットワークに接続する「サイバーデバイス」の市販前申請にあたり、SBOM の提出を法文で求めています。

provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components

出典：21 U.S. Code §360n–2(b)(3)（連邦食品医薬品化粧品法524B条(b)(3)）

まとめると、ここで挙げた制度のうち条文で SBOM の作成・提出が明記されているのは、EU CRA と米国の医療機器規制です。決済と車載は「構成情報を管理できていること」が求められ、SBOM はそれを満たす有力な手段という関係になります。

手引も「SBOM の提供が義務付けられているソフトウェアは限定的である」としたうえで、対象ソフトウェアに関する要求事項を随時情報収集し、求められる場合には具体的な要求事項を整理することを勧めています。自社が本当に SBOM を求められる立場なのかは、取引先との契約や納入先の要件から確認するのが確実です。

出典・参考資料（6件）

• 出典：Regulation (EU) 2024/2847（Cyber Resilience Act）Article 3(39), Annex I Part II(1), Article 71｜EUR-Lex（官報全文）
• 出典：PCI DSS v4.0 要件6.3.2（PCI Security Standards Council, PCI DSS v4.0 SAQ A-EP, April 2022 所収）（PDF）
• 出典：UN Regulation No 155 [2021/387] / No 156 [2021/388]｜EUR-Lex（R155）
• 出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0 4.1 p.38、8.4.1 p.96｜経済産業省（PDF）
• 出典：21 U.S. Code §360n–2（連邦食品医薬品化粧品法524B条）｜Cornell Law School Legal Information Institute（条文）
• 出典：Executive Order 14028「Improving the Nation’s Cybersecurity」Sec.4(e)(vii), Sec.4(f), Sec.4(k)｜Federal Register（全文）

まとめ

脆弱性管理ツールを選ぶときの出発点は、機能一覧の読み比べではなく「自社が何を守りたいのか」の確定です。自社プロダクトの依存ライブラリなのか、社内のサーバーやネットワーク機器なのか、出荷する製品に載せたソフトウェアなのか。ここが決まれば候補は5つのタイプのどれかに収まり、比較すべき製品は数点に絞られます。

タイプが決まったら、対応レイヤーが標準機能に含まれるか、SBOM の生成と取り込みのどちらが必要か、優先順位付けをどこまで自動でやってくれるか、料金の課金単位が自社の成長と合うか、日本語で運用を続けられるかを確かめます。とくに優先順位付けは、導入後に運用が続くかどうかを左右します。CVSS だけで並べ替える製品と、悪用の実態や自社環境まで加味する製品では、担当者が向き合う件数が変わってきます。

典型的な状況ごとに、どのタイプの表から見ればよいかを整理します。自社で開発しているアプリはなく社内のサーバーを守りたいなら、IT 資産全体をまたぐタイプの表と、日本語で情報を追い切るタイプの表。自社プロダクトの依存ライブラリが主な心配なら、OSS 依存を見て修正まで導くタイプの表です。

その両方を1本で済ませたいなら、IT 資産全体をまたぐタイプの中から「守れる対象」列に自社コードの OSS 依存まで入っている製品を探します。取引先から SBOM を求められているなら、SBOM を作って管理するタイプの表に加えて、「SBOM 対応」列で生成と出力の両方に印が付いている製品を横断で拾ってください。

SBOM については、本記事で扱った制度のうち条文で作成・提出が明記されているのは EU サイバーレジリエンス法と米国の医療機器規制で、決済や車載の制度が求めているのは構成情報を管理できていることでした。取引先からの要求が制度によるものか契約によるものかを確かめると、対応の範囲と急ぎ具合を過不足なく決められます。

各社の料金や対応範囲は公開されていないものも多く、条件を伝えたうえで見積もりを取るのが確実です。気になるものはまとめて資料を取り寄せて、社内での比較検討にお役立てください。

よくある質問（FAQ）

Q. 脆弱性管理ツールとは何ですか？

A. 脆弱性管理ツールとは、自社の IT 資産の構成情報を把握し、日々公表される脆弱性情報と突き合わせて、どこにどの脆弱性が残っているかを継続的に可視化し、対応の優先順位づけと進捗の管理まで回す仕組みです。

IPA が「情報セキュリティ10大脅威 2026 解説書［組織編］」でシステム管理者・製品利用者の対策として挙げる「脆弱性情報の収集」「脆弱性の悪用状況の収集」「脆弱性対策の優先度付け」「対策状況の管理」が、そのままツールの機能に対応します。ただし守る対象は製品ごとに異なり、サーバーや機器を見るもの、自社コードの OSS を見るもの、出荷製品の SBOM を管理するものに分かれます。

Q. 脆弱性管理ツールと脆弱性診断は何が違い、両方必要ですか？

A. 脆弱性管理ツールと脆弱性診断は担う工程が違うため、片方が他方を置き換える関係にはなく、併用が前提になります。診断はある時点の IT 資産に攻撃を模したパケットを送るなどして脆弱性を特定する行為で、管理は資産の把握から情報収集、評価、対処、進捗管理までを繰り返すプロセスです（経済産業省「ASM 導入ガイダンス」表2-1）。

現実的な組み合わせは、日常をツールで継続的に監視し、大きな改修や新サービスの公開前、取引先や監査から診断結果の提出を求められたとき、年次の棚卸しといった確度が要る局面で人手の診断を挟む形です。

Q. 脆弱性管理ツールとSBOM管理ツール、SCAツールは何が違いますか？

A. 3つは「SBOM が部品表、SCA がその部品表を作って脆弱性と突き合わせる解析、脆弱性管理ツールが資産全体で対応を回す仕組み」という関係にあります。

SBOM は、経済産業省の手引が「ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リスト」と定義するものです。SCA は、OWASP が「第三者製・オープンソースのコンポーネント利用によるリスクを特定するプロセス」の一部として位置づける手法にあたります。

実際の製品では SCA と SBOM 生成が同じ機能の表と裏になっていることが多く、名乗っているカテゴリだけでは中身が判断できません。製品名のカテゴリではなく、自社が守りたい対象（自社コードの OSS 依存か、サーバーやネットワーク機器か、出荷製品に載せたソフトウェアか）から絞り込むのが確実です。

Q. すでにIT資産管理ツールやEDRを導入していても、脆弱性管理ツールは必要ですか？

A. 脆弱性管理ツールが要るかどうかは、既存ツールがどこまでを担っているかを棚卸ししたうえでないと判断できません。前提として、日本シーサート協議会の「脆弱性管理の手引書」は「ある程度の IT 資産の識別（IT 資産管理）がされている前提で」脆弱性管理を扱うとしており、資産管理は脆弱性管理の土台であって代わりになるものではありません。

そのうえで守備範囲は製品ごとに違うため、一般論で線を引かず、既存ツールが「資産の一覧を持つだけ」なのか「脆弱性情報との突合まで行う」のかを切り分け、不足する範囲だけを各社に伝えて役割分担を質問してください。重複する範囲が分かれば、そこを外した構成で見積もりを取れるため、費用の抑制にもつながります。

Q. 無料・OSSの脆弱性管理ツールだけで足りますか？

A. 無料・OSS のツールでもコンテナイメージや依存ライブラリのスキャン、SPDX・CycloneDX 形式での SBOM 出力といった基本的な処理は実行できますが、取引先への提出や監査対応が絡む段階では商用製品が必要になります。

経済産業省の手引は無償ツールの課題として「再帰的な利用部品が検出できない、読み込み可能な SBOM フォーマットに制限がある、ライセンスの検知漏れが発生する、導入環境が限定される」を挙げ、環境整備や学習に大きな工数を要する可能性も指摘しています。

間接的に依存している部品まで漏れなく洗い出す、指定された形式で SBOM を受け渡す、誰がいつまでに対応するかを記録して監査で示す。このいずれかが必要になった時点で乗り換えを検討する、という進め方が現実的です。

Q. 中小企業でも脆弱性管理ツールは必要ですか？

A. 脆弱性管理ツールが要るかどうかは企業規模ではなく、守るべき資産の数と種類を人手で追い切れるかで決まります。脆弱性情報をメールで受け取って表計算ソフトに転記する運用は、管理対象が数十台を超えたあたりから、抜けても気づけない状態になります。

コストの制約が強い場合の始め方について、経済産業省の手引は参照する脆弱性データベースの選び方として「コスト制約の強い中小企業は、費用、簡易ツールの利用を優先して DB を選択し、リスク低減の要求が高い企業は、カバレッジ拡大や対応の迅速化に対応した DB を優先的に選択する」と整理しています。商用製品にも無料枠を設けているものがあるため、対象を絞って始め、必要になった範囲だけ広げる進め方が取れます。

Q. 脆弱性管理ツールの料金はどのくらいかかりますか？

A. 脆弱性管理ツールの料金は価格を公開している製品が限られ、課金単位は「管理対象の資産数・ホスト数」「開発者数・リポジトリ数」「機能セットごとの年間サブスクリプション」の3つに大きく分かれます。経済産業省の手引も、多くのツールが年間のサブスクリプションモデルで提供され、算出方法は「開発者数や組織の規模、解析コード量に応じた課金等、ツールによって様々」だと整理しています。

本記事の掲載20サービスのうち金額を公開しているのは7件で、開発者1人あたり月25ドル前後から、資産数課金なら100資産で年間数千ドルという水準に分布します（公開されている価格の一覧）。

金額が非公開の製品から見積もりを取るときは、対象資産数（または開発者数）、見たいレイヤー、SBOM の生成・取り込み・出力のどれが要るか、日本語サポートの要否を整理して伝えると、条件のそろった比較ができます。コンテナやクラウド設定への対応が上位プランや別製品になっている場合は必要な層を足した状態の総額で比べてください。

Q. 海外製の脆弱性管理ツールでも日本語で運用できますか？

A. 海外製ツールを日本語で運用できるかは製品ごとに異なり、同じ製品でも本体と国内代理店で状況が変わります。経済産業省の手引は「取扱説明書や README ファイルが英語のみで提供されているケースがあるほか、ツール自体も日本語対応していない場合がある」としたうえで、英語のみの運用が困難なら日本語対応ツールの優先度を高めることを選択肢に挙げています。

確認したいのは、管理画面が日本語か、脆弱性の解説や対処方法が日本語で提供されるか、問い合わせ窓口が国内にあるかの3点です。代理店が日本語サポートを提供している場合、それが本体の標準機能ではなく代理店の付帯サービスであることもあるため、契約先がどちらになるかも合わせて確認しておくと、運用開始後の窓口対応で迷いません。

Q. 取引先からSBOMの提出を求められたら、どう進めればよいですか？

A. SBOM の提出を求められたときは、まず要求元に「どの形式で、どの深さまで、どの頻度で」提出するのかを確認することから始めます。SBOM は形式（SPDX / CycloneDX / SWID タグ）によって想定された用途が違い、ツールごとに出力できる形式も異なるためです。

NTIA が定めた最小要素は、記載項目（データフィールド）と機械可読性（自動化サポート）だけでなく、作成頻度・深さ・既知の未知・共有方法・アクセス管理・誤りの許容といった運用の取り決め（プラクティスとプロセス）まで含みます。

ファイルを1回出力すれば終わりではないため、生成を継続できるツールを選び、出荷後も部品の脆弱性を追える体制まで含めて設計してください。また、経済産業省の手引は「SBOM の提供が義務付けられているソフトウェアは限定的である」としているため、要求の根拠が取引先との契約なのか制度なのかを確かめておくと、対応範囲を過不足なく決められます。

Q. 脆弱性管理ツールの検出件数が多すぎるときは、どう捌けばよいですか？

A. 検出件数が処理能力を超えたときは、すべてに対応しようとせず、自社の判断基準を先に決めて絞り込みます。日本シーサート協議会の手引書も「大量に報告される脆弱性のすべてに対応するのは非現実的であり、各組織においてどのような脆弱性に対応するかの判断基準が必要となる」と述べています。

絞り込みの材料は CVSS だけではありません。CVSS の基本値は深刻度を測る指標であり、リスクの評価に単独で使うべきではないと FIRST 自身が明言しています。実務では、公開済みの CVE が今後30日間に悪用される確率を示す EPSS、悪用が確認された脆弱性の一覧である KEV カタログ、立場ごとに対応区分を決める SSVC を組み合わせるのが一般的です。

あわせて、使っていない機能や別の手段で緩和済みのものを対象外にできる除外設定があるかを確認すると、残る件数が現実的な水準に収まります。

Q. 脆弱性管理ツールを導入する前に、社内で準備しておくことはありますか？

A. 導入前に効くのは、対象資産の棚卸しと、対応の判断基準を関係者で合意しておくことの2つです。台帳から漏れているサーバーや部門が個別に契約したクラウド環境はそもそもスキャンの対象にならないため、棚卸しの進み具合が初期の検出精度をそのまま決めます。

日本シーサート協議会の手引書は、脆弱性管理を継続的に回すために「組織における脆弱性管理の位置づけ、判断基準、緊急時の態勢に関する経営層の合意」「必要なスキルセットの整理と人材の育成」「手順の整理」「ツールの整備」の4点を挙げています。

「CVSS 7.0以上は2週間以内」といった基準を先に決めておけば、脆弱性が出るたびに関係者で議論せずに済みます。加えて、トライアルで自社環境をスキャンし、実際に出てくる件数を見てから契約規模を決めると、運用開始後に行き詰まりにくくなります。

Q. 脆弱性管理ツールの説明に出てくる VEX とは何ですか？

A. VEX（Vulnerability Exploitability eXchange）とは、あるソフトウェアが特定の脆弱性の影響を実際に受けるかどうかを伝えるための情報です。NTIA の文書は、その脆弱性の影響を受けるか否かを伝えることが VEX の中核であり、対応が不要と判断される場合は「影響を受けない（not affected）」という状態を示すと説明しています。

部品表に載っている脆弱性のすべてが自社のリスクになるわけではないため、VEX は検出件数を絞り込む手段として期待されています。ただし経済産業省の手引は、優先付けに使う VEX 情報について「ベンダーなどから提供されることが期待されるが、現状では提供されるケースが限られている」としており、VEX 対応の有無だけを決め手に製品を選べる段階ではありません。

出典・参考資料（3件）

• 出典：ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0（4.2「SBOMツールの選定」、7.4.2「脆弱性管理」、8.4「関連する制度・規制」ほか）｜経済産業省（PDF）
• 出典：The Minimum Elements For a Software Bill of Materials (SBOM)｜NTIA, U.S. Department of Commerce（PDF）
• 出典：情報セキュリティ10大脅威 2026 解説書［組織編］｜独立行政法人情報処理推進機構（PDF）

脆弱性管理ツールの料金・対応範囲を一括チェック

MCB FinTech カタログでは、脆弱性管理ツールの最新資料をワンクリックで一括入手できます。対応レイヤーや SBOM 対応、料金体系を各社の資料で比べたい方は、こちらからまとめて資料請求してください。

MCB FinTechカタログに掲載しませんか？

FinTech カタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。