2026年10月、IDCFクラウドのポータルで使われていたオープンソースソフトウェア（OSS）の脆弱性が突かれ、495の企業・自治体に影響が及ぶ不正アクセスが起きました。こうしたニュースを見て、上司から「うちが使っているOSSは大丈夫なのか」と問われ、答えに詰まった開発・情報システム担当の方も多いのではないでしょうか。
自社のサーバやアプリは、Apacheやログ出力ライブラリ、暗号化ライブラリなど数多くのOSSで組み上がっています。その一つに脆弱性が見つかったとき、自社がどれを・どのバージョンで使っているかを把握できていなければ、危険かどうかの判断すらできません。では、何から手をつければよいのでしょうか。
本記事では、OSSの脆弱性が実際にどんな被害を生むのかを過去の事件で確かめたうえで、自社で使うOSSを「洗い出し→継続監視→優先対応」する3ステップを、各段階で何を使ってどう進めるかまで具体的に解説します。脆弱性情報の入手先やSBOM・SCAの位置づけ、自社で手に負えないときに相談できる診断サービスの選び方まで、担当者が明日から動ける形で整理しました。
目次
一括ダウンロードする
OSS脆弱性とは？なぜ生まれ、なぜ今問題なのか
OSS脆弱性とは、オープンソースソフトウェア（誰でも利用・改変できる形で公開されたソフトウェア）に含まれる、攻撃に悪用されうる欠陥のことです。
OpenSSLのような暗号化ライブラリ、Apache HTTP ServerのようなWebサーバなど、現代のシステムはOSSを部品として積み上げて作られています。その一つに欠陥があると、それを組み込んだ自社システムも同じ弱点を抱えることになります。
OSSの普及と依存関係の深さ
OSSが問題になりやすい理由の一つは、依存関係の深さにあります。あるライブラリを1つ導入すると、そのライブラリがさらに別のライブラリを呼び出し、芋づる式に数十〜数百の部品が自社システムに取り込まれます。開発者が明示的に選んだわけではない「間接的な依存（推移的依存）」まで含めると、自社が実際に何を使っているのかを人の記憶だけで把握するのは困難です。
この「見えていない部品」にこそ脆弱性が潜みます。直接インストールした覚えのないライブラリが、実は危険なバージョンのまま本番環境で動いていた、という事態が起こりうるのです。
公開情報ゆえ攻撃に悪用されやすく、保守は利用者の責任
OSSの脆弱性情報は、CVE（共通脆弱性識別子）として誰でも閲覧できる形で公開されます。利用者が修正を適用するための仕組みである一方、攻撃者にとっても「どのソフトのどのバージョンに、どんな穴があるか」を知る手がかりになります。脆弱性が公表された直後に、その穴を狙う攻撃が世界中で一斉に始まることは珍しくありません。
加えて、OSSは原則として無保証で提供され、導入後の保守・更新は利用する側の責任とされています。ベンダー製品のように提供元が自動で面倒を見てくれるわけではないため、「使い始めたら、脆弱性情報を自分で追い、自分で直す」という前提に立つ必要があります。
放置するとどうなるか
脆弱性を放置したシステムは、遠隔からの任意のプログラム実行（サーバを乗っ取られる）、情報の抜き取り、ランサムウェアの侵入口といった実害に直結します。特に、インターネットに公開しているサーバやアプリは、公表済みの脆弱性を自動で探し回る攻撃の対象になりやすく、「気づかないうちに侵入されていた」というケースが後を絶ちません。次章では、実際に起きた被害をいくつか具体的に見ていきます。
OSS脆弱性の実際の被害事例
OSSの脆弱性が、どのくらいの規模の被害につながるのか。まずは代表的な事例を一覧で確認します。いずれも「どのOSSの・どんな脆弱性で・何が起きて・どれだけの規模になったか」を、公的機関や当事者の公表情報にもとづいて整理しています。
| 発生・公表 | 対象OSS | 脆弱性（CVE） | 何が起きたか | 被害規模 |
|---|---|---|---|---|
| 2021年12月 | Apache Log4j2 | CVE-2021-44228（Log4Shell） | 遠隔から任意のコードを実行される（RCE） | CVSS基本値10.0（最大）。悪用が容易で世界中で一斉に攻撃が発生 |
| 2017年3月 | Apache Struts 2 | CVE-2017-5638 | 細工したHTTPヘッダで遠隔からコマンド実行 | Equifax社の情報漏えいの起点に。米国内で少なくとも約1億4,550万人分の個人情報が流出 |
| 2014年4月 | OpenSSL | CVE-2014-0160（Heartbleed） | サーバのメモリから秘密鍵などの機微情報が漏えい | CVSS基本値7.5。TLSを使う広範なサーバが影響対象に |
| 2026年10月 | 認証システムのOSS（具体名・CVEは非公表） | 非公表 | IDCFクラウドポータルの認証システムに第三者が侵入 | 495の企業・自治体に影響。最大71社の登録情報に不正照会 |
CVE情報・深刻度はNVD（NIST）、Equifaxの被害規模は米国GAO報告書、IDCFクラウド事件はIDCフロンティア公式発表にもとづく（各節の出典参照）。
Apache Log4j（Log4Shell）
2021年12月に公表されたLog4jの脆弱性（CVE-2021-44228、通称Log4Shell）は、Javaのログ出力ライブラリLog4j2に存在したものです。ログに記録される文字列を通じて、攻撃者が外部サーバから任意のプログラムを読み込ませ、実行できてしまうという深刻な欠陥でした。深刻度を示すCVSS基本値は最大の10.0と評価されています。
Log4jは膨大な数のJavaアプリケーションに組み込まれていたため、公表直後から世界中で攻撃が観測されました。米CISA（サイバーセキュリティ・インフラセキュリティ庁）の「悪用が確認された脆弱性カタログ（KEV）」にも、ランサムウェアでの悪用が確認された脆弱性として登録されています。
自社が直接Log4jを入れた覚えがなくても、利用中のフレームワークが内部で使っていた、というケースが多発しました。依存関係の深さがもたらす怖さを象徴する事例です。
出典・参考資料（1件）
- 出典：CVE-2021-44228｜NVD（National Vulnerability Database・NIST）（https://nvd.nist.gov/vuln/detail/CVE-2021-44228）
Apache Struts 2（Equifax社の大規模情報漏えい）
2017年3月に公表されたApache Struts 2の脆弱性（CVE-2017-5638）は、細工したHTTPヘッダを送ることで遠隔からコマンドを実行できるというものでした。CVSS基本値は9.8で、公表時点ですでに実環境での悪用が確認されていました。
この脆弱性は、米国の信用情報会社Equifax社の大規模な情報漏えいの起点になったことで知られます。米国政府監査院（GAO）の報告書は、侵入にApache Strutsの脆弱性が利用され、米国内で少なくとも約1億4,550万人分の個人情報にアクセスされたと指摘しています。
The vulnerability involved the Apache Struts Web Framework and would allow an attacker to execute commands on affected systems. … resulted in the attackers accessing personal information of at least 145.5 million consumers in the U.S.
米国政府監査院（GAO）報告書 GAO-18-559（https://www.gao.gov/products/gao-18-559）
その後、米連邦取引委員会（FTC）の和解では、影響を受けた人数は1億4,700万人、被害者救済に最大4億2,500万ドルを充てるとされました。1つのOSSの未修正が、企業の存続を揺るがす規模の損害につながりうることを示す事例です。
出典・参考資料（3件）
- 出典：CVE-2017-5638｜NVD（NIST）（https://nvd.nist.gov/vuln/detail/CVE-2017-5638）
- 出典：GAO-18-559｜米国政府監査院（https://www.gao.gov/products/gao-18-559）
- 出典：Equifax Data Breach Settlement｜米連邦取引委員会（FTC）（https://www.ftc.gov/enforcement/refunds/equifax-data-breach-settlement）
OpenSSL（Heartbleed）
2014年4月に公表されたOpenSSLの脆弱性（CVE-2014-0160、通称Heartbleed）は、通信を暗号化するライブラリOpenSSLのTLS実装に存在しました。細工したパケットを送ることで、サーバのメモリ上にある秘密鍵やパスワードなどの機微な情報を読み取れてしまうという、情報漏えい型の欠陥です。
任意のコード実行ではないためCVSS基本値は7.5で、Log4jほどではありませんが、暗号化通信を担うOpenSSLは広範なサーバで使われており、影響範囲の広さが問題となりました。遠隔からコードを実行されるタイプだけが危険なわけではなく、情報を抜き取られるタイプの脆弱性も重大な被害につながることを示しています。
出典・参考資料（1件）
- 出典：CVE-2014-0160｜NVD（NIST）（https://nvd.nist.gov/vuln/detail/CVE-2014-0160）
IDCFクラウドの不正アクセス（2026年10月・認証システムのOSS脆弱性）
記憶に新しいのが、2026年10月に公表されたIDCフロンティア社の「IDCFクラウド」での不正アクセスです。同社の公式発表（第7報）は、原因を次のように説明しています。
お客さまが仮想サーバーの起動や請求情報の確認などに利用する「IDCFクラウドポータル」の認証システムで使用していたオープンソースソフトウェアの脆弱性を突かれて、第三者が認証システムに侵入していたことが判明しました。
IDCフロンティア「【第7報】不正アクセスに関する調査結果および今後の対応について」（2026年10月27日）（https://www.idcf.jp/news/topics/20261027001）
同社の発表によれば、仮想サーバー内のデータの外部流出はなかったものの、攻撃を受けたリージョンの一部サーバーを利用していた495の企業・自治体に影響が及び、ポータル上で最大71社の登録情報に不正な照会が行われました。原因となった具体的なOSS名やCVE番号は公表されていないため、本記事でも推測で特定はしません。
注目すべきは、同社が再発防止策として「ソフトウェアの構成情報を全社で一元管理し、脆弱性情報との突合を自動化する（SBOM化）」ことや「脆弱性診断の対象範囲をOSSにも広げる」ことを挙げている点です。これはまさに、次章で解説する「洗い出し→監視→優先対応」という対策の方向性と一致しています。
出典・参考資料（1件）
- 出典：【第7報】不正アクセスに関する調査結果および今後の対応について｜IDCフロンティア（https://www.idcf.jp/news/topics/20261027001）
自社OSSの脆弱性を見つけて対処する3ステップ
ここからは、自社が使うOSSの脆弱性に対処する具体的な進め方を解説します。一般的な対策の流れは、大きく「①利用OSSの洗い出し→②脆弱性情報の継続監視→③優先順位づけと対応」の3ステップに整理できます。これは広く受け入れられた実務の型で、各ステップで何を使うかまで押さえれば、明日から着手できます。
ステップ1：利用OSSの洗い出し・可視化（SBOM）
最初に行うのは、自社システムが「何を・どのバージョンで」使っているかの棚卸しです。脆弱性情報が出ても、自社が該当のOSSを使っているかが分からなければ対処のしようがないため、ここが起点になります。
棚卸しの成果物が、ソフトウェアの構成部品を機械可読な形で一覧にしたSBOM（ソフトウェア部品表）です。直接の依存だけでなく、間接的に取り込まれた部品まで含めて把握することが重要で、これを手作業で漏れなく作るのは現実的ではありません。
そこで、依存ライブラリを解析するSCA（ソフトウェア構成分析）ツールやパッケージ管理の仕組みを使って自動生成します。まず手元で試すなら、Trivyやnpm audit（Node.js環境）のような無料ツールで棚卸しを始められます（具体的なツールは後述）。SBOMの中身は次章で詳しく解説します。
ステップ2：脆弱性情報の継続監視・自社構成との突合
次に、新たに公表される脆弱性情報を継続的に追い、ステップ1で作った自社の構成情報（SBOM）と突き合わせていきます。脆弱性は日々新しく公表されるため、一度調べて終わりではなく、継続的な監視の仕組みが必要です。
情報の入手先には、CVEやNVDをはじめとする公式のデータベースがあります（各情報源の役割と公式URLは「脆弱性情報はどこで入手するか」で一覧にしています）。自社が使うOSSのバージョンに該当する脆弱性が公表されていないかを、これらと照合して監視するのが基本です。
ステップ3：リスクの優先順位づけと対応
見つかった脆弱性すべてを一度に直すのは困難です。そこで、どれを先に対応するかの優先順位づけが要になります。判断材料になるのが、深刻度を示すCVSSスコアと、実際に攻撃で悪用されているかという情報です。
CVSSの数値が高いものほど危険度は高いものの、スコアが高くても実際には悪用されていない脆弱性もあります。そこで、米CISAが「悪用が確認された脆弱性カタログ（KEV）」として公開している、現実に攻撃へ使われている脆弱性を優先的に直す、という考え方が有効です。たとえばLog4jやStruts 2の脆弱性はいずれもKEVに登録されており、CVSSが高く、かつ実際に悪用されている典型例でした。
対応の実務は、脆弱性が修正された安全なバージョンへの更新が基本です。すぐに更新できない場合は、該当機能の無効化や通信制限といった緩和策で当面のリスクを下げ、更新の計画を立てます。
SBOMとは何か・なぜ重視されるのか
ステップ1で触れたSBOM（Software Bill of Materials／ソフトウェア部品表）は、近年のOSS脆弱性対策で中心的な役割を担う考え方です。ここでは、その中身となぜ対策の中心になっているのかを整理します。
構成管理と脆弱性突合の関係
SBOMは、米国電気通信情報庁（NTIA）の説明では「ソフトウェアを構成する部品（コンポーネント）の入れ子状の一覧」と定義されています。食品の原材料表示のように、自社のソフトウェアが「どの部品を・どのバージョンで」含んでいるかを機械可読な形で持つものです。
SBOMを整備しておくと、新たな脆弱性が公表されたときに「自社の構成一覧と照らして、該当する部品を使っているか」を自動で突き合わせられます。ステップ1（洗い出し）の成果物であると同時に、ステップ2（監視・突合）を自動化するための土台になる、という関係です。IDCFクラウドの事件で再発防止策にSBOM化が挙がったのも、この突合を全社で自動化する狙いがあります。
標準フォーマット（SPDX・CycloneDX）
SBOMを異なるツール間でやり取りできるよう、標準フォーマットが整備されています。代表的なのが、Linux Foundationがホストし国際標準ISO/IEC 5962として承認されたSPDXと、OWASP Foundationらが策定し国際標準ECMA-424となっているCycloneDXの2つです。
どちらを使うかはツールや取引先の要件によりますが、いずれも「構成情報を標準化された形で出力・交換する」ための共通言語です。SCAツールの多くはこれらの形式でSBOMを出力できます。
出典・参考資料（2件）
- 出典：Software Bill of Materials｜NTIA（https://www.ntia.gov/page/software-bill-materials）
- 参考資料：SPDX（https://spdx.dev/）／CycloneDX（https://cyclonedx.org/）
制度化・導入推進の動き
SBOMは、日本で一般の企業に一律に法的義務が課されているわけではありません。ただし、導入を後押しする動きは広がっています。経済産業省は「ソフトウェア管理に向けたSBOMの導入に関する手引」を公表して導入を推進しており、医療機器など分野によっては個別に構成情報の管理が求められています。
米国では、連邦政府に納入するソフトウェアに対してSBOMの提供が求められるなど、調達要件としての制度化が先行しています。義務化そのものよりも、「取引先や顧客からSBOMの提出を求められる場面が増えていく」という実務上の流れとして捉えておくとよいでしょう。
出典・参考資料（2件）
- 参考資料：ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0｜経済産業省（https://www.meti.go.jp/policy/netsecurity/wg1/SBOMv2.pdf）
- 参考資料：Software Bill of Materials (SBOM)｜米CISA（https://www.cisa.gov/sbom）
脆弱性情報はどこで入手するか（情報源一覧）
ステップ2の継続監視を実行するには、信頼できる脆弱性情報の入手先を押さえておく必要があります。代表的な公式データベースを、運営主体・何に強いか・公式URLとともに一覧にしました。いずれも無料で利用できます。
| 情報源 | 運営主体 | 何に強いか | 公式URL |
|---|---|---|---|
| CVE | MITRE（米CISA後援） | 脆弱性に世界共通の識別番号（CVE-西暦-連番）を付与する仕組み | cve.org |
| NVD | NIST（米国国立標準技術研究所） | CVEに深刻度（CVSS）や影響製品バージョンなどの詳細を付与 | nvd.nist.gov |
| JVN iPedia | IPA（情報処理推進機構） | 日本語での脆弱性対策情報・国内製品の情報 | jvndb.jvn.jp |
| JPCERT/CC | JPCERTコーディネーションセンター | 日本語での重要・緊急な注意喚起（Alert） | jpcert.or.jp |
| CISA KEV | 米CISA | 実際に悪用が確認された脆弱性のカタログ（優先度判断に有用） | cisa.gov |
| OSV | Google（スキーマはOpenSSF） | OSSパッケージ単位（npm・PyPI・Go等）での脆弱性照合 | osv.dev |
CVEで識別番号を把握し、NVDで深刻度を確認、JVN iPediaやJPCERT/CCで日本語の情報を押さえ、CISA KEVで「実際に悪用されているか」を見て優先度を判断する、という使い分けが実務的です。
出典・参考資料（1件）
- 参考資料：CVE（https://www.cve.org/）／NVD（https://nvd.nist.gov/）／JVN iPedia（https://jvndb.jvn.jp/）／JPCERT/CC（https://www.jpcert.or.jp/）／CISA KEV（https://www.cisa.gov/known-exploited-vulnerabilities-catalog）／OSV（https://osv.dev/）
自社の構成（SBOM）と情報源を照合するには
これらの情報源を毎日人手で確認し、自社が使う何十・何百もの部品と一つずつ照合するのは、現実的な作業量ではありません。そこで、ステップ1で作ったSBOMと脆弱性データベース（OSVなど）を自動で突き合わせ、「自社の構成に該当する脆弱性が出たら通知する」仕組みを使うのが一般的です。この自動照合を担うのが、次章で触れるSCA（ソフトウェア構成分析）ツールや脆弱性管理ツールです。
人手の限界と、ツール・サービスの選び方
ここまでの3ステップは考え方としては明快ですが、実際に手作業だけで回し続けるには無理があります。なぜ人手では限界があるのか、どんなツール・サービスで補えるのかを整理します。
なぜ人手だけでは限界か
理由は主に2つあります。1つは、前述の依存関係の深さです。間接的な依存まで含めると部品数は膨大になり、人の目で漏れなく追うのは困難です。もう1つは、脆弱性情報が日々公表され続ける量の多さです。新しい脆弱性が出るたびに、自社の全構成と照合する作業を手作業で継続するのは、担当者の負担として続きません。
この「洗い出し」と「監視・突合」を自動化するのが、SCA（Software Composition Analysis／ソフトウェア構成分析）ツールです。SCAは、プロジェクトの依存ライブラリを解析してSBOMを生成し、脆弱性データベースと自動で突き合わせます。
「脆弱性診断を受けているから大丈夫」という誤解
「脆弱性診断は受けているから大丈夫」と考える方もいますが、ここには注意が必要です。一般的なWebアプリケーション診断は、公開されたサービスに外部からアクセスして挙動を調べる「動的な診断」で、画面やリクエストから観測できる範囲の問題を見つけます。
一方、依存ライブラリに潜むOSSの脆弱性は、外からの挙動には現れないコードの内部に存在するため、外部診断だけでは見落とされやすいという性質があります。依存OSSの問題を押さえるには、ソースコードや依存関係そのものを調べるSCAやソースコード診断が必要になる、という点を理解しておくと、自社に足りない対策が見えてきます。
このうちソースコード診断は、ツールで自動検出するタイプか専門家が目視するタイプかによって費用も進め方も変わります。どのタイプに依頼すればよいかを費用相場とあわせて整理した以下の記事は、依頼先を比べる際の参考になります。
無料で始められるOSSツール
まず手元で試したい場合は、無償で使えるツールから着手できます。代表的なものを挙げます。
- Trivy（Aqua Security）：コンテナイメージ・コードリポジトリ・依存関係などの脆弱性と設定不備をまとめて検出するOSSスキャナ。
- OWASP Dependency-Check：プロジェクトの依存関係を特定し、既知の公開脆弱性があるかをNVDと照合してチェックするSCAツール。
- npm audit：Node.js／npm環境に標準で付属し、依存パッケージの既知脆弱性を報告する監査コマンド。
npm audit fixで自動修正も試せる。
これらは「まず自社の状況を把握する」第一歩として有効です。一方で、対応言語の広さ、検出精度、修正までの支援、継続運用のしやすさといった面では商用のツールや診断サービスに利があり、本格的に運用するなら次の判断軸で検討します。
出典・参考資料（1件）
- 参考資料：Trivy（https://trivy.dev/）／OWASP Dependency-Check（https://owasp.org/www-project-dependency-check/）／npm audit（https://docs.npmjs.com/cli/v10/commands/npm-audit）
SCA・脆弱性診断サービスの選び方の判断軸
ツールやサービスを選ぶ際は、次の観点で自社に合うかを確認するとよいでしょう。いずれも「自社の開発言語・運用体制で、見つけてから直すまでを回せるか」という視点が軸になります。また、CI/CD連携や修正の自動化は、継続運用するSCA・管理ツール（製品）で特に効く観点です。専門家に単発で依頼する委託診断では、対応言語・診断方式・報告後のフォロー・料金が主な判断軸になります。
- 対応言語・範囲：自社が使う開発言語やパッケージ管理の仕組みに対応しているか。コンテナやクラウド設定まで見るかも確認します。
- 脆弱性DBの量と質：NVDだけでなく、独自の情報源やOSS向けDBをどれだけ参照しているか。網羅性が検出漏れを左右します。
- 検出精度（誤検知の少なさ）：誤検知が多いと確認作業に追われます。ツールの自動検出に専門家の目視を加える方式かも判断材料です。
- CI/CD連携・通知：開発の流れ（ビルドやデプロイ）に組み込めるか、新たな脆弱性を自動で通知してくれるか。継続運用のしやすさに直結します。
- 修正までの支援：脆弱性の場所を示すだけでなく、安全なバージョンの提案や修正の自動化まで支援するか。「見つけてから直すまで」の速度を左右します。
これらの観点で、SBOMの作成から脆弱性情報の突合・優先順位づけまでを継続的に担う脆弱性管理ツールを具体的に比べたい場合は、以下の記事で主要な製品を守りたい対象・SBOM対応・優先順位付けの観点から整理しています。
自社ですべてを運用する余力がない場合は、専門家による診断サービスに依頼する選択肢もあります。次章では、自社のソースコードや依存ライブラリの脆弱性を見つける国内のサービスを紹介します。
一括ダウンロードする
自社で手に負えないOSS脆弱性対策を相談できるサービス
依存OSSやソースコードの脆弱性は、外部からの動的診断では見つけにくく、専門的な解析が要ります。ここでは、ソースコードや依存ライブラリの脆弱性を見つける・診断する国内のサービスを紹介します。自動検査のSaaS型と、専門家が診断する委託型があり、自社の体制に合わせて選べます。
選ぶ前に押さえたいのが対象範囲の違いです。依存ライブラリ（OSS）そのものの検査（SCA）まで一貫して行えるのは、下記のうちAikido Securityです。残り5件は主に自社が書いたコードを対象とするソースコード診断で、依存OSSの検査可否は範囲や要問い合わせになります。
依存OSSの管理が主目的ならSCA対応のサービスや前掲の無料SCAツールを、自社コードの作り込みの脆弱性もまとめて見てもらうなら委託診断を、という使い分けが基本です。各サービスの対象は比較表の「主な診断方式」で確認できます。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス | SHIFT SECURITY ソースコード診断 | セキュアブレイン ソースコード診断 | レオンテクノロジー ソースコード診断 | KSK Verification ソースコード診断 |
|---|---|---|---|---|---|---|
| 提供形態 | SaaS（自動スキャン型） | 委託（AI診断＋専門家） | 委託（専門家が診断） | 委託（専門家が診断） | 委託（専門家が診断） | 委託（専門家が診断） |
| 主な診断方式 | SCA・SAST・DAST・クラウド設定などを統合 | 静的（ソースコード）・動的・ペネトレーションテスト | 静的解析＋専門家の目視 | 静的解析（SAST相当）＋専門家の精査 | 診断ツール＋目視（ハイブリッド） | 診断員による目視診断 |
| 対応言語・範囲 | 依存ライブラリ・ソースコード・クラウド・コンテナ・Webアプリを横断 | Webアプリ・API・ソースコード（対応言語は要問い合わせ） | Java・PHP・.NET・Ruby on Rails（ほかは要問い合わせ） | 20以上（Java・C#・Python・PHP・JS・Ruby・Go・Swiftほか） | Java・C/C++・PHP・Rubyほか各種FW | Java・PHP（Spring・Laravelほか） |
| 料金目安 | 月額サブスク型（無料プランあり） | 15万円〜（ソースコード診断） | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） | 要問い合わせ（見積り制） |
| CI/CD連携 | ● | 記載なし | 記載なし | 記載なし | 記載なし | 記載なし |
| 診断後のフォロー | 自動修正（PR作成）まで支援 | 再診断あり（上位プラン） | 要問い合わせ | 速報・報告会・フォローアップ診断 | 重大時は速報・再診断/改修フォロー | 速報・報告会 |
| 詳細情報 | 公式資料を見る | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
各社の診断方式・対応言語・料金は公式情報にもとづく（2026年11月時点）。最新の内容は各サービスの資料・公式サイトでご確認ください。
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコードの診断・依存ライブラリの検査（SCA）・クラウド設定のチェック・コンテナ・稼働中のWebアプリまでを一つの画面でまとめて扱える、オールインワンの脆弱性診断SaaSです。ベルギーのAikido Security社が開発し、日本では株式会社AndGoが窓口として日本語での導入・運用を支援しています。
依存OSSの脆弱性を見つけるSCAを中核機能として備えつつ、単機能ツールを継ぎ足すとアラートがばらばらに増える問題を、統合によって「対応すべきものに絞り込む」設計が特徴です。見つけた脆弱性には、修正案のドラフトからプルリクエストまで自動で作る機能があり、「見つけてから直すまで」を開発の流れに組み込めます。
料金は診断1回ごとではなく、利用人数などに応じた月額のサブスクリプション型で、無償のトライアル環境も用意されています。
アラートを統合して絞り込むというこの設計が生まれた背景について、提供元である株式会社AndGo 代表取締役の原氏は、脆弱性対応の現場で起きがちな悩みをインタビューで次のように語っています。
当社がよくお聞きするのは、「アラートが多すぎて、何が重要か分からなくなって放置が始まる」という悩みです。Aikido Securityは、バラバラだったアラートを統一し、対応すべきアラートを絞れるようにします。結果として、消し込み工数を減少でき、セキュリティ運用を“手に負える状態”に寄せていけます。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、WebアプリケーションやAPIを対象とする委託型の診断サービスです。ソースコードを読み取る静的診断、実際にアクセスする動的診断、仮想的な攻撃を仕掛けるペネトレーションテストの3つの方法を提供します。自社開発のAI診断システム「Red Agent」を専門家が使い、従来比で診断を高速化している点を強みに掲げています。
依存OSSにも関わるソースコード診断は15万円から、動的診断は30万円から、Webのペネトレーションテストは60万円からと、料金の目安を公開しているのも検討しやすい点です。AIによる自動解析で見つけた候補を最終的に人の目で確認するフローを取っており、スピードと精度の両立を図っています。
同社がこうした高速な診断を定期的に提供する形に取り組む背景には、攻撃する側の変化があります。CoWorker株式会社 Sales Managerの一ノ瀬氏は、サービス開発の経緯をインタビューで次のように説明しています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
3. SHIFT SECURITY ソースコード診断（株式会社SHIFT）
SHIFT SECURITY ソースコード診断は、ソフトウェアの品質保証を手がける株式会社SHIFT（旧SHIFT SECURITY）が提供する、ソースコードを対象とした委託型の診断です。静的解析ツールによる検出と、セキュリティエンジニアによる目視確認を組み合わせ、外部からの動的診断では見つけにくいコード内部の脆弱性を洗い出すことを主眼としています。
公式で名指しされている対応言語はJava・PHP・.NET Framework・Ruby on Railsで、その他の言語は個別に要問い合わせです。料金は公開されておらず、診断範囲に応じた見積り制となっています。
4. セキュアブレイン ソースコード診断（株式会社日立システムズ）
セキュアブレイン ソースコード診断は、株式会社日立システムズがセキュアブレインブランドで提供する診断サービスです。稼働中・開発中のアプリケーションのソースコード自体を解析するため、Webサーバへアクセスせず、稼働中システムに影響を与えずに実施できる点を特徴としています。
対応言語はJava・Python・PHPなど20以上と幅広く、脆弱性が見つかった場合はファイル名・行番号まで報告するため、修正作業の工数削減につながります。料金は診断対象の規模に応じた見積り制です。
5. レオンテクノロジー ソースコード診断（株式会社レオンテクノロジー）
レオンテクノロジーのソースコード診断は、診断ツールと目視チェックを併用するハイブリッド方式を採っています。ツールで検出した脆弱性を一つずつ人が確認することで、ツールのみの診断で起きやすい誤検知を抑える狙いがあります。
Java・C/C++・PHP・Rubyなどの言語やフレームワークに対応し、開発途中の部分的な診断にも応じます。診断完了後は約5営業日以内に報告書を提出し、重大な脆弱性は診断中に速報で通知する運用です。費用は診断範囲や期間に応じた見積り制となっています。
6. KSK Verification ソースコード診断（株式会社KSK）
KSK Verification ソースコード診断は、ソフトウェアテスト事業を手がける株式会社KSKが提供する、診断員の目視によるソースコード診断です。脆弱性の検出に加えて、非推奨APIの利用や未使用関数といったコード品質の観点も評価する点に特徴があります。
Java・PHPなどの言語と、Spring・Laravelなどのフレームワークに対応します。危険度の高い脆弱性を即時報告する「速報」オプションや報告会にも対応し、料金は実ステップ数・言語・期間をもとにした見積り制です。
ここで紹介したのは、依存OSSやソースコードの内部を調べる診断が中心です。Webアプリケーションやネットワークなども含めて、脆弱性診断サービス全体を診断方法・費用相場・選び方から比較検討したい場合は、以下の記事もあわせてご覧ください。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
まとめ
OSSの脆弱性は、Log4jやIDCFクラウドの事件が示すように、放置すれば大規模な被害に直結します。一方で、対策の進め方自体は明確です。まず自社が使うOSSを洗い出し（SBOM）、新たな脆弱性情報を継続的に監視して自社構成と突き合わせ、CVSSと実際の悪用状況を見て優先順位をつけて対応する——この3ステップが土台になります。
依存OSSの脆弱性は外部からの診断では見落とされやすいため、SCAやソースコード診断で内部まで調べることが欠かせません。まずは手元の無料ツールで現状把握から始め、本格的な運用や専門家の診断が必要になった段階で、自社の開発言語・体制に合ったツールやサービスを検討してください。
一括ダウンロードする
よくある質問（FAQ）
Q. OSS脆弱性とは何ですか？
A. OSS脆弱性とは、オープンソースソフトウェア（誰でも利用・改変できる形で公開されたソフトウェア）に含まれる、攻撃に悪用されうる欠陥のことです。多くのシステムはOSSを部品として組み上げているため、その一つに欠陥があると、組み込んだ自社システムも同じ弱点を抱えます。脆弱性情報はCVEとして公開され、公表直後に悪用を狙う攻撃が一斉に始まる点が特徴です。
Q. OSS脆弱性対策は無料ツールだけで足りますか？
A. OSS脆弱性対策は、現状把握の第一歩としては無料ツールだけでも始められますが、継続的な運用には商用ツールや診断サービスが必要になる場面が多いです。TrivyやOWASP Dependency-Check、npm auditといった無償ツールで自社の依存ライブラリに既知の脆弱性がないかを確認することは可能です。
一方で、対応言語の広さ、検出精度（誤検知の少なさ）、安全なバージョンの提案など修正までの支援、新たな脆弱性の自動通知といった継続運用の面では、商用のSCAツールや専門家による診断サービスに利があります。まず無料ツールで現状を把握し、本格運用が必要になった段階で有償の選択肢を検討する進め方が現実的です。
Q. OSS脆弱性は人手（手作業）だけで管理できますか？
A. OSS脆弱性の管理を人手だけで継続するのは現実的ではなく、ツールによる自動化が前提になります。理由は2つあり、1つは依存関係の深さです。あるライブラリが別のライブラリを芋づる式に呼び出すため、間接的な依存まで含めると部品数は数十〜数百にのぼり、人の目で漏れなく追うのは困難です。
もう1つは、脆弱性情報が日々公表され続ける量の多さです。新しい脆弱性が出るたびに自社の全構成と照合する作業を手作業で続けるのは負担が大きく、長続きしません。現実的には、SCA（ソフトウェア構成分析）ツールをCI/CDパイプラインに組み込み、コミットやビルドのたびに依存ライブラリを自動で検査する形にすれば、人手を介さずに継続監視できます。
Q. 外部の脆弱性診断を受けていれば、依存OSSの脆弱性も見つかりますか？
A. 外部からの脆弱性診断を受けていても、依存OSSの脆弱性は見落とされやすく、それだけでは不十分です。一般的なWebアプリケーション診断は、公開されたサービスに外部からアクセスして挙動を調べる「動的な診断」で、画面やリクエストから観測できる範囲の問題を見つけます。
依存ライブラリに潜むOSSの脆弱性は、外からの挙動には現れないコードの内部に存在するため、動的診断では検知しづらい性質があります。外部の動的診断（公開面の挙動）・SCA（依存OSS）・ソースコード診断（自社コード）は守備範囲がそれぞれ異なるため、どれか一つで足りるとは考えず、自社の構成に合わせて組み合わせるのが前提になります。
Q. OSS脆弱性対策にSBOMは必須ですか？何から始めればよいですか？
A. SBOMは一般の企業に一律の法的義務が課されているわけではありませんが、対策の起点として整備する価値が高く、まずは利用OSSの洗い出し（SCAツールによる自動生成）から始めるのが実務的です。SBOM（ソフトウェア部品表）は、自社のソフトウェアが「どの部品を・どのバージョンで」含んでいるかを機械可読な形で持つもので、新たな脆弱性が公表されたときに自社構成と自動で突き合わせる土台になります。
手作業で漏れなく作るのは難しいため、SCAツールやパッケージ管理の仕組みで自動生成するのが一般的です。経済産業省も導入の手引を公表して推進しており、取引先や顧客からSBOMの提出を求められる場面も増えています。
Q. SCAツールとソースコード診断は何が違いますか？
A. 両者は対象が異なり、SCAは外部から取り込んだ依存ライブラリ（OSS）に既知の脆弱性がないかを自動で検査する仕組み、ソースコード診断は自社が書いたコード自体の欠陥を調べるものです。SCAはプロジェクトの依存関係を解析してSBOMを生成し、脆弱性データベースと突き合わせて「使っているOSSに公開済みの脆弱性がないか」を見ます。
一方、ソースコード診断は、自社が実装したコードにSQLインジェクションなどの作り込みの欠陥がないかを、静的解析や専門家の目視で調べます。依存OSSと自社コードの双方に脆弱性は潜むため、両者は競合するものではなく補完関係にあります。SCAとソースコード診断の双方を一つの画面で扱える統合型のSaaSもあります。
Q. OSSの脆弱性が見つかったら、どれから対応すればよいですか？
A. 見つかった脆弱性は、深刻度を示すCVSSスコアと、実際に攻撃で悪用されているか（米CISAのKEVカタログ）を組み合わせて優先順位をつけるのが有効です。CVSSの数値が高いものほど危険度は高いものの、スコアが高くても実際には悪用されていない脆弱性もあるため、「現実に攻撃へ使われている脆弱性」を優先的に直す考え方が実務的です。
対応は、脆弱性が修正された安全なバージョンへの更新が基本です。すぐに更新できない場合は、該当機能の無効化や通信制限といった緩和策で当面のリスクを下げ、更新の計画を立てます。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ソースコード診断や依存ライブラリ検査（SCA）に対応した脆弱性診断サービスの最新資料を無料で一括請求できます。対応言語・診断方式・料金を比べて、自社に合うサービスを効率的に選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
