自社のソフトウェアを開発・運用する現場では、ゼロからすべてを書くことはほとんどなく、オープンソースソフトウェア（OSS）や外部のライブラリ、クラウドのサービスを組み合わせて製品を形づくっています。この「部品を組み合わせて作る」仕組みが広がるほど、自分たちが書いたコードは安全でも、取り込んだ部品や、それを組み立てて配布する経路のどこかが攻撃者に狙われるリスクが高まります。
実際に、正規のソフトウェア更新に悪意あるコードが仕込まれた「SolarWinds」事件や、広く使われるログ出力ライブラリの脆弱性「Log4Shell」など、部品や配布経路を経由した攻撃が相次いで表面化してきました。こうした攻撃は、信頼して導入したアップデートやライブラリから入り込むため、従来の「自社が作ったアプリの脆弱性を塞ぐ」対策だけでは防ぎきれません。
「ソフトウェアサプライチェーンセキュリティ」は、この部品の調達から開発、ビルド、配布、運用までの一連の流れ全体を守る考え方です。この記事では、まず通常の脆弱性対策との違いを押さえたうえで、なぜリスクが増えているのか、どんな手口・事例があるのか、そしてSBOM（ソフトウェア部品表）やSCA（ソフトウェア構成分析）といった具体的な対策、国内外の制度、自社で何から始めればよいかまで整理します。
目次
一括ダウンロードする
ソフトウェアサプライチェーンセキュリティとは？通常の脆弱性対策との違い
はじめに、この言葉が何を守る取り組みなのか、そして普段行っているアプリケーションの脆弱性対策と何が違うのかを整理します。ここがはっきりすると、以降のリスクや対策を自社の状況に当てはめて読み進められます。
ソフトウェアサプライチェーンセキュリティとは、ソフトウェアを構成する部品の調達から、開発、ビルド、配布、運用・更新までの一連の流れ全体を、改ざんや脆弱性の混入から守る取り組みを指します。守る対象が「自社が書いたコード」にとどまらず、取り込んだOSSや外部ライブラリ、それらを組み立てるビルド環境やCI/CD、利用者へ届ける配布・アップデートの経路までを含むのが特徴です。
守る対象の範囲
「サプライチェーン」は本来、原材料の調達から製造・流通・販売までの供給網を指す言葉です。ソフトウェアに当てはめると、次のような工程と、そこで扱う要素すべてが守る対象になります。
- 調達・依存: 取り込むOSS、外部ライブラリ、パッケージ、コンテナイメージ、外部APIなどの部品
- 開発・ビルド: ソースコード、ソースコードを管理するリポジトリ、ビルドやデプロイを自動化するCI/CDのパイプライン、ビルド環境
- 配布・運用: 完成物を利用者へ届ける配布サーバーやアップデートの経路、コードへの署名、稼働後の継続的な監視
この範囲の広さが、ソフトウェアサプライチェーンセキュリティを理解するうえで最初のポイントになります。自社のコードが堅牢でも、取り込んだ部品や、それを組み立てて配る経路のどこか一か所が侵害されれば、完成したソフトウェアに攻撃者のコードが紛れ込みます。
通常のアプリケーション脆弱性対策との違い
従来のアプリケーションセキュリティは、主に「自社が書いたコードにバグや設計上の弱点がないか」を点検する取り組みでした。SQLインジェクションやクロスサイトスクリプティングのような、自社開発部分の欠陥を見つけて塞ぐことに重心があります。
一方、ソフトウェアサプライチェーンセキュリティは、守る範囲を「自社が作っていない部分」にまで広げます。信頼して取り込んだOSSに既知の脆弱性が潜んでいないか、依存先のパッケージが乗っ取られていないか、ビルドや配布の経路が改ざんされていないか——攻撃者が自社の外側から間接的に入り込む経路までを、点検の対象に広げます。
両者は対立するものではなく、補い合う関係です。自社コードの脆弱性対策はこれまでどおり続けつつ、そこに「取り込んだ部品と、組み立て・配布の経路」という視点を足したものがソフトウェアサプライチェーンセキュリティだと捉えると整理しやすくなります。
なぜ今ソフトウェアサプライチェーン対策が重要なのか
ここからは、なぜこのリスクが近年とくに大きくなっているのか、その構図を見ていきます。背景を押さえると、対策に投資する理由を社内で説明しやすくなります。
OSS・外部依存の増大
現代のソフトウェア開発では、機能の多くをOSSや外部ライブラリに頼って効率化を図るのが一般的です。その結果、1つの製品が数百から数千の部品に依存することも珍しくなく、そのどれかに脆弱性があれば、製品全体がリスクを抱えることになります。
この傾向は調査データにも表れています。ソフトウェア構成を分析した「2026 Open Source Security and Risk Analysis（OSSRA）」レポートは、17業種にわたる947の商用コードベースを監査しました。その結果、87%が少なくとも1つの脆弱性を含んでいたと報告されています。
脆弱性を含むこと自体が直ちに攻撃を意味するわけではありませんが、放置すれば攻撃の糸口になり得ます。しかも、攻撃側の動きも活発になっています。
ソフトウェア供給網を調査したSonatypeの年次レポート（2024年）は、悪意あるオープンソースパッケージが前年比156%増加し、2019年以降に特定された数は704,102件を超えたと報告しています。取り込む部品が増えるほど、それを狙う攻撃も年々拡大しているのが実情です。
信頼された部品を経由した間接侵入という構図
ソフトウェアサプライチェーン攻撃が厄介なのは、攻撃者が標的の企業を直接狙わず、その企業が信頼して使っている部品やサービスを侵害し、そこを足がかりに間接的に入り込む点にあります。日常的に取り込む更新やライブラリは、疑わずに信頼して導入するのが前提になっているため、そこに悪意あるコードが混ざっていても気づきにくいのです。
さらに、1つの部品が侵害されると、その部品を使うすべての利用者へ一度に影響が広がります。攻撃者から見れば、多くの企業が共通して使うライブラリやツールを1つ侵害するだけで、下流の無数のシステムへ波及させられるため、効率のよい攻撃対象になってしまいます。一点の侵害が広範囲の被害につながるこの構図が、リスクを大きくしている核心です。
日本特有の供給構造の事情
国内では一般に、システム開発を複数の企業が多層的に請け負ったり、開発・運用の一部を外部へ委託したりすることが多く、供給網に関与する当事者が増える傾向があります。
これとは別に、ソフトウェア全般でも取り込む部品は年々増えています。前述のOSSRAレポートによれば、監査対象の商用コードベースの98%がOSSを含み、1アプリケーションあたり平均1,180のOSSコンポーネントが使われていました（世界全体の調査結果）。
開発に関わる企業も、取り込む部品も増えるほど、どこか1社・1部品のセキュリティ水準が低ければ、そこが供給網全体の弱点になりかねません。
委託先や再委託先が取り込む部品・ビルド環境まで自社で把握しきるのは容易ではなく、関係する組織ごとにセキュリティ基準がばらつくことも少なくありません。自社内の対策だけでなく、委託先を含めた供給網全体をどう見渡すかが、国内企業にとって現実的な課題になります。
ソフトウェアサプライチェーン攻撃の仕組みと主な手口
続いて、攻撃が具体的にどのような流れで行われ、どんな手口があるのかを見ていきます。手口を知ることで、自社のどこが狙われうるかを想像しやすくなります。
攻撃の基本的な流れ
ソフトウェアサプライチェーン攻撃の多くは、標的そのものではなく、標的が信頼して使う「上流」を侵害するところから始まります。おおまかには、次のような流れをたどります。
- 侵入経路の特定: 多くの企業が共通して使うライブラリ、パッケージ、開発ツール、更新の配布経路など、侵害すれば波及の大きい「上流」を見つける
- 汚染: その部品や経路に悪意あるコードを仕込む。正規の配布物やアップデートに紛れ込ませ、署名や見た目は正規のまま装う
- 波及: 利用者が汚染された部品や更新を、信頼して自社のシステムへ取り込む。これにより攻撃コードが下流の多数のシステムへ広がる
- 実行: 取り込まれた攻撃コードが各利用者の環境で動き、情報の窃取やさらなる侵入の足がかりづくりなどを行う
主な攻撃手口の分類
攻撃が入り込む経路に注目すると、主な手口は次の3種類に整理できます。後半の「どの手口にどの対策が効くか」でも、この分類を軸に対応づけます。
悪意あるコードの混入
正規のパッケージやアップデートに、攻撃者が悪意あるコードを紛れ込ませる手口です。広く使われるOSSのメンテナ権限を乗っ取る、正規の名前に似せた偽パッケージを公開して取り違えを誘う（タイポスクワッティング）、更新の配布物そのものを改ざんする、といった形があります。
脆弱な依存コンポーネントの取り込み
攻撃者が能動的に仕込むのではなく、既知の脆弱性を抱えたOSSや外部ライブラリを、自社が気づかずに取り込んでしまう手口です。依存関係が何重にも連なると、直接は使っていない「依存先の依存先」に潜む脆弱性まで把握しづらくなり、放置されたまま攻撃の糸口になります。
ビルド・配布経路の汚染
ソースコードやライブラリ自体は正しくても、それらを組み立てるCI/CDやビルド環境、完成物を配る配布サーバーが侵害される手口です。ビルドの過程で攻撃コードが混入すれば、正規の署名が付いた「正しく見える」成果物として利用者に届いてしまい、受け取る側は見破りにくくなります。
これらの手口は、外部の攻撃者だけが引き起こすとは限りません。手口の分類とは別の軸として、開発に関わる内部の担当者や委託先の従業員が、故意または過失で悪意あるコードや脆弱な部品を持ち込むこと（内部者による脅威）もあります。これに対しては、誰がどの変更を加えたかをたどれるよう、アクセス権限の管理と変更履歴の記録をあわせて備えることが欠かせません。
代表的な攻撃事例（SolarWinds・Log4j ほか）
ここでは、実際に起きた代表的な事例を取り上げ、手口と間接的な波及の実態を具体的に見ていきます。いずれも、信頼された部品や経路が侵害されたことで被害が広がった例です。
SolarWinds（SUNBURST）
2020年12月に公表されたSolarWinds事件は、ソフトウェアサプライチェーン攻撃の代表的な事例です。ネットワーク監視製品「Orion」の正規のアップデートに、攻撃者がバックドアを仕込んだコンポーネントを混入させ、「SUNBURST」と呼ばれるマルウェアを配布しました。
セキュリティ企業のFireEye（Mandiant）は発見当時の報告で、SUNBURSTというマルウェアを配布するためにSolarWinds Orionの業務用ソフトウェア更新をトロイの木馬化したサプライチェーン攻撃を発見した、と説明しました。原文は次のとおりです。
FireEye discovered a supply chain attack trojanizing SolarWinds Orion business software updates in order to distribute malware we call SUNBURST.
出典：Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor（2020年12月）｜Mandiant（FireEye）
利用者から見れば、信頼するベンダーが署名した正規のアップデートだったため、疑わずに導入してしまったところに攻撃コードが潜んでいました。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）も、2020年3月から6月の間に公開されたOrionの特定バージョンが悪用されたとして、同年12月に注意喚起を出しています。
Log4j（Log4Shell）
2021年12月に公表された「Log4Shell」（CVE-2021-44228）は、広く使われるJava用ログ出力ライブラリ「Apache Log4j」の脆弱性です。細工したログメッセージを送るだけで、外部から任意のコードを実行できる可能性があり、深刻度を示すCVSS v3.1の基本値は最高の10.0とされました。
Log4jは数え切れないほどのソフトウェアに組み込まれていたため、「どこで使っているか」を把握すること自体が多くの企業にとって難題になりました。自社が直接導入した覚えがなくても、取り込んだ別の製品やライブラリの内部で使われているケースが多く、1つのOSSの脆弱性がいかに広範囲へ波及するかを示した事例です。
出典・参考資料（1件）
OSSを悪用した事例（Codecov・event-stream・PyPI ほか）
OSSや開発ツールの供給元が侵害された事例も繰り返し起きています。手口の幅を知るうえで、代表的なものをいくつか挙げます。
- Codecov（2021年）: CI環境で広く使われるコードカバレッジ計測ツールの「Bash Uploader」スクリプトが改ざんされた事例。公式によると2021年1月31日ごろから改ざんが始まり、同年4月1日に不正アクセスが発覚。改ざんされたスクリプトを通る利用企業のCI環境から、認証情報などが外部へ送られうる状態でした
- event-stream（2018年）: 広く使われるnpmパッケージのメンテナ権限が第三者へ譲渡された後、悪意ある依存パッケージが追加され、暗号資産ウォレット関連を標的とするコードが仕込まれた事例。メンテナ権限の委譲が攻撃の起点になりました
- PyPI上の偽パッケージ（2024年）: 暗号ライブラリ「pycrypto」に名前を似せた偽パッケージが公開された事例。取り違えて取り込むと、最終的にマルウェアが実行される仕組みで、国内のJPCERT/CCが攻撃グループLazarusによるものとして注意喚起しました
出典・参考資料（3件）
ソフトウェアサプライチェーンを守る対策の全体像
ここからは、具体的な対策を全体像として整理します。それぞれの対策が「どの段階で」「どの手口に」効くかを意識すると、自社に必要なものを選びやすくなります。
SBOM（ソフトウェア部品表）
SBOM（Software Bill of Materials）は、ソフトウェアが「どの部品で構成されているか」を一覧にした、いわば製品の部品表です。米国の大統領令14028は、SBOMを「ソフトウェアの構築に使われる各種コンポーネントの詳細と、そのサプライチェーン上の関係を含む正式な記録」と定義しています。原文は次のとおりです。
“Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software.
出典：Executive Order 14028「Improving the Nation’s Cybersecurity」Sec.10(j)（2021年5月）｜govinfo（米国官報）
自社の製品に含まれる部品を一覧化しておくと、新たな脆弱性が公表されたときに「自社のどの製品に影響するか」を素早く確認できます。Log4Shellのように、どこで使っているかの把握自体が難題になる事態への備えになります。SBOMには、国際標準化された「SPDX」（ISO/IEC 5962:2021）や、OWASPが主導する「CycloneDX」（ECMA-424）といった標準フォーマットがあります。
SBOMは、脆弱性の把握だけでなく、OSSの利用条件（ライセンス）の管理にも役立ちます。前述のOSSRAレポートでは、監査対象の68%にライセンス条件の競合が見つかりました。どのOSSをどの条件で使っているかを一覧化しておくことは、法務・コンプライアンス面のリスクを早期に把握する土台にもなります。
出典・参考資料（2件）
SCA・SAST・DASTによる検査
ソフトウェアの弱点を見つける検査には、見る対象の異なる3つの手法があります。これらは役割が重ならないため、組み合わせて使うのが基本です。
- SCA（ソフトウェアコンポジション解析）: 取り込んだOSSや外部ライブラリなど「依存コンポーネント」に既知の脆弱性がないかを調べる手法。サプライチェーンの観点で中心的な役割を担います
- SAST（静的アプリケーションセキュリティテスト）: ソースコードやコンパイル済みコードを解析し、コード自体に潜む弱点を見つける手法
- DAST（動的アプリケーションセキュリティテスト）: 稼働中のアプリケーションを外部から実際に動かして、実行時に表れる脆弱性を検出する手法
サプライチェーン対策では、とりわけ依存コンポーネントを調べるSCAが起点になります。SBOMで部品を一覧化し、SCAでその部品の脆弱性を継続的に突き合わせる、という流れが基本の形です。この突き合わせには、米国の国家脆弱性データベース（NVD）やGoogleが主導するOSS脆弱性データベース「OSV」のような公開情報が使われます。
出典・参考資料（2件）
依存関係の管理・バージョン固定
取り込む部品を無秩序に増やさず、使っている依存関係を把握・管理することも重要です。利用するバージョンを固定（ピン留め）し、意図しない更新で未検証の部品が紛れ込まないようにする、依存先の更新は検査を通してから取り込む、といった運用が基本になります。
直接使う部品だけでなく、その部品がさらに依存する「依存先の依存先」まで見渡すことが、脆弱な依存コンポーネントの取り込みを防ぐうえで欠かせません。SBOMとSCAは、この見通しづらい依存の連なりを可視化する土台になります。
SBOMの作成から依存コンポーネントの脆弱性検査、対応の優先順位づけまでを継続的に回すには、専用の脆弱性管理ツールを使う選択肢もあります。製品ごとの対応範囲やSBOM対応の有無を比較したい場合は、以下の記事も参考になります。
コード署名・チェックサム検証
配布物が改ざんされていないかを確かめる手段が、コード署名とチェックサムの検証です。提供元が正規の署名を付け、受け取る側がその署名やハッシュ値を検証することで、配布の途中で中身がすり替えられていないかを確認できます。
ただしSolarWindsの事例のように、ビルドの段階で攻撃コードが混入すると、正規の署名が付いたまま汚染物が配布されます。署名の検証は有効な対策ですが、それだけに頼らず、後述するビルド環境自体の保護と組み合わせることが前提になります。
CI/CDパイプラインの保護・継続監視・委託先管理
ソースコードを組み立てて配布するCI/CDやビルド環境は、攻撃者にとって魅力的な標的です。ここが侵害されると「正しく見える」汚染物が作られてしまうため、ビルド環境へのアクセス制御、使用するツールやスクリプトの検証、ビルド過程の記録といった保護が必要です。
ビルドの改ざんを検知しやすくする枠組みとしては、成果物の生成過程の記録（来歴）を残し、その信頼性を段階的に高める「SLSA（Supply-chain Levels for Software Artifacts）」という枠組みもあります。OpenSSF（Open Source Security Foundation）が整備しています。
出典・参考資料（1件）
加えて、脆弱性は日々新たに公表されるため、一度点検して終わりにせず、稼働後も継続的に監視する姿勢が欠かせません。自社だけでなく、開発や運用を委託する先が取り込む部品・環境まで含めて、供給網全体でセキュリティ水準を揃える委託先管理も、国内の多層的な開発構造では重要になります。
攻撃手口と対策の対応づけ
ここまでの対策を、先に整理した3つの攻撃手口と対応づけると、自社のどこに何が効くかが見えやすくなります。実際にはこれらを組み合わせて多層的に備えるのが前提ですが、優先順位を考える手がかりになります。
| 攻撃手口 | 悪意あるコードの混入 （偽パッケージ・メンテナ乗っ取り等） | 脆弱な依存コンポーネントの取り込み | ビルド・配布経路の汚染 |
|---|---|---|---|
| 主に効く対策 | 依存関係の管理・バージョン固定、SCAによる継続的な検査、取り込み元の信頼性確認、SBOMによる可視化 | SBOMで部品を一覧化し、SCAで既知の脆弱性と突き合わせて継続監視、脆弱な部品の更新・置き換え | CI/CD・ビルド環境の保護とアクセス制御、コード署名・チェックサム検証、ビルド過程の記録と監視 |
一括ダウンロードする
国内外の制度・ガイドラインの最新動向
ソフトウェアサプライチェーン対策は、各国の制度やガイドラインでも重視され始めています。自社が直接の対象でなくても、取引先や業界の動向として押さえておくと、対応の必要性を判断する材料になります。
海外の動向（米国・EU）
米国では、2021年5月に署名された大統領令14028が、ソフトウェアサプライチェーンの安全確保を掲げ、政府が調達するソフトウェアにSBOMの提供を求める方向を打ち出しました。あわせて、安全な開発の進め方をまとめたNISTの「SSDF（Secure Software Development Framework、SP 800-218 v1.1、2022年2月）」が、実務の指針として参照されています。
EUでは、デジタル要素を持つ製品のセキュリティを定める「サイバーレジリエンス法（CRA）」が2024年12月10日に発効しました。主要な義務の適用は2027年12月からとされ、製造者がサプライチェーン全体でセキュリティに責任を負うことが求められます。EU市場に製品を出す企業が対象となるため、海外展開を視野に入れる場合は確認が必要です。
出典・参考資料（3件）
国内の動向（経済産業省のSBOM導入の手引 ほか）
国内では、経済産業省がソフトウェア管理に向けたSBOMの導入を後押ししています。同省の商務情報政策局サイバーセキュリティ課は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公表しており、最新版のver2.0は2024年8月に公開されています。SBOM導入のメリットや実施のポイント、脆弱性管理のプロセスなどがまとめられています。
SBOMの重要性は国際的にも共有されつつあります。2025年9月には、米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）とNSAが19の国際パートナーとともにSBOMに関する共同ガイダンスを公表し、日本からは経済産業省が共同執筆機関として参加しました。
制度や手引の具体的な解釈・適用範囲は改訂で変わりうるため、実務で対応を検討する際は、最新版の原文を確認することをおすすめします。
出典・参考資料（2件）
何から始めるか：対策の進め方と選択肢
最後に、ここまでの対策を自社でどう進めればよいかを整理します。すべてを一度に揃える必要はなく、優先順位をつけて段階的に取り組むのが現実的です。
対策の進め方
NISTのSSDFなど、安全な開発の考え方に沿うと、まず「自社が何を使っているか」を把握するところから始めるのが基本です。おおまかな段取りは次のとおりです。
- 部品の可視化（SBOMの作成）: 自社の製品やシステムが、どのOSS・ライブラリに依存しているかを一覧化する
- 依存の検査（SCAの導入）: 一覧化した部品に既知の脆弱性がないかを突き合わせ、優先度の高いものから対応する
- 開発工程への組み込み（CI/CDとの連携）: 検査を開発・ビルドの流れに組み込み、新しい部品や更新のたびに自動で点検されるようにする
- 継続的な監視: 脆弱性は日々公表されるため、一度きりで終わらせず、公開後も継続して監視し対応を回す
社内で回す・ツールを入れる・外部に診てもらう
これらの対策を誰がどう担うかには、大きく3つの選択肢があります。自社の体制や開発の進め方に応じて、組み合わせて選ぶのが現実的です。
- 社内で回す: 既存の開発体制のなかで、SBOM作成や依存の検査を内製で進める。開発現場が主体的に動ける組織に向く一方、継続運用の負荷をどう吸収するかが課題になる
- ツールを入れる: SCAやSBOM生成、CI/CDとの連携を担うツールを導入し、検査を自動化する。日々の点検を開発の流れに組み込みたい場合に適する
- 外部に診てもらう: ソースコード診断やペネトレーションテストなどを専門の事業者に委託する。社内に専門人材が不足している場合や、第三者の視点で網羅的に点検したい場合に向く
次の章では、このうち「ツールを入れる」「外部に診てもらう」を実際に担えるサービスの例を紹介します。
ソフトウェアサプライチェーン対策に役立つサービス
ここでは、前章の「ツールを入れる」「外部に診てもらう」という2つのパスを担えるサービスを、それぞれ1つずつ紹介します。まずは両者の違いを一覧で整理します。
| サービス名 | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 対策のパス | ツールを入れる （SaaS・自動検査） | 外部に診てもらう （専門家による受託診断） |
| 診断の進め方 | 管理画面から自社で 継続的に自動スキャン | 専門家に依頼し 診断・報告書を受領 |
| 主な診断対象 | ソースコード・依存ライブラリ クラウド設定・コンテナ 稼働中のWebアプリ | Webアプリケーション API・ソースコード |
| サプライチェーン対策での役割 | SCA・SBOM生成で 依存部品を継続的に可視化 | 静的・動的診断とペネトレーション テストで第三者が網羅点検 |
| 運用イメージ | CI/CDに組み込み 開発工程で日常的に点検 | 四半期・月次など 定期診断も相談可 |
| 料金 | 月額5万円台から （サブスク型・無料プランあり） | 静的診断15万円から Webペネトレ60万円から （いずれも診断1回あたり） |
| 向いている企業 | 自社でサービスを内製する 開発会社・開発部門 | 社内に専門人材が不足 第三者視点で点検したい企業 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード、依存ライブラリ、クラウド設定、コンテナ、稼働中のWebアプリまでを1つの管理画面で検査するSaaSです。SCA（依存関係の検査）やSAST、CSPM（クラウド設定の点検）、DAST、SBOMの生成、マルウェア検出などをまとめて扱えるため、ソフトウェアサプライチェーン対策を開発工程に組み込みたい場合の選択肢になります。
特徴は、分断されがちな複数の診断を統合し、対応すべきアラートを絞り込みやすくしている点です。検出した脆弱性について、修正案のドラフトを作ってプルリクエストまで出せる自動修正の機能もあり、見つけてから直すまでの流れを短くしやすくなっています。日本では株式会社AndGoが窓口となり、日本語での導入・運用のサポートを提供しています。
料金は月額利用料が固定のサブスクリプション型で、日本窓口の案内では年間契約・利用者10人までの参考価格として月額5万円台からとされています（2026年時点、為替により変動）。無料で試せるプランも用意されており、自社でサービスを内製する開発会社・開発部門に向いたツールです。
ツールの導入は、開発の進め方そのものの変化とも結びついています。この点について、日本窓口を務める株式会社AndGoの原氏は次のように述べています。
正直なところ、昔は「セキュリティは運用側が最後に何とかするもの」という前提が強かったと思います。ですが今は攻撃の手口も複雑ですし、作ったあとに1回チェックして終わり、では追いつきません。だから開発の初期からセキュリティを組み込むDevSecOps（開発（Dev）、セキュリティ（Sec）、運用（Ops））が現実解になってきていて、Aikido Securityはその”回し方”を作るためのツールだと考えています。
CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker 脆弱性診断サービスは、WebアプリケーションやAPI、ソースコードを対象に、専門家が診断を行う受託型のサービスです。ソースコードを読み取る静的診断、実際にアクセスして解析する動的診断、仮想的な攻撃を仕掛けて侵入可能性を試すペネトレーションテストの3つの方法を用意しています。社内に専門人材が不足している場合や、第三者の視点で網羅的に点検したい場合の選択肢になります。
自社開発のAI診断システム「Red Agent」を使うことで、従来より高速な診断を実現している点が特徴です。AIで速度を上げつつ、ハルシネーション（AIの誤り）が起きうる箇所は明示し、最終的に人の目で確認するフローを取っています。これにより、従来は年1回程度だった診断を、四半期や月次で回すといった継続的な利用もしやすくなっています。
料金は、静的診断が15万円から、Webアプリケーションのペネトレーションテストが60万円から案内されています（2026年時点、診断対象の規模により変動）。生成AI・LLMの脆弱性診断といった派生サービスもあり、外部委託で供給網の点検を進めたい企業に適しています。
外部に診断を委託する動きが、継続的なものへと変わりつつある背景について、CoWorker株式会社の一ノ瀬氏は、攻撃側の変化を次のように語っています。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
ここで取り上げたのは代表的な2サービスです。外部委託も含めて脆弱性診断サービスをより広く見渡し、診断方法の違いや費用相場、自社に合う選び方まで比較したい場合は、以下のまとめ記事が参考になります。
まとめ
ソフトウェアサプライチェーンセキュリティは、自社が書いたコードだけでなく、取り込んだOSSや外部ライブラリ、それらを組み立て配布する経路までを含めて守る取り組みです。OSSへの依存が広がり、信頼された部品を経由した間接的な攻撃が増えるなかで、従来のアプリケーション脆弱性対策に、この「部品と経路」の視点を足すことが求められています。
対策は、まずSBOMで自社が使う部品を可視化し、SCAで依存の脆弱性を継続的に検査し、それを開発工程に組み込んで監視を続ける、という流れが基本になります。社内で回す・ツールを入れる・外部に診てもらうという選択肢を、自社の体制に合わせて組み合わせていくとよいでしょう。各サービスの診断範囲や料金を比べたい場合は、下記から資料をまとめて取り寄せてご確認ください。
一括ダウンロードする
よくあるご質問（FAQ）
Q. ソフトウェアサプライチェーンセキュリティとは何ですか？
A. ソフトウェアサプライチェーンセキュリティとは、ソフトウェアを構成する部品の調達から、開発・ビルド・配布・運用・更新までの一連の流れ全体を、改ざんや脆弱性の混入から守る取り組みです。
守る対象が自社の書いたコードだけでなく、取り込んだOSSや外部ライブラリ、それらを組み立てるビルド環境・CI/CD、利用者へ届ける配布・アップデートの経路までを含む点が特徴です。自社のコードが堅牢でも、部品や配布経路のどこか一か所が侵害されれば完成物に攻撃者のコードが紛れ込むため、この範囲全体を見渡すことが出発点になります。
Q. OSS（オープンソース）は、使わないほうが安全ですか？
A. OSSは、使わないほうが安全とは言えません。
公開され多くの目で点検される透明性はむしろ安全面の利点になり得る一方、適切な管理を欠くとサプライチェーン攻撃の入口にもなります。現代の開発では機能の多くをOSSに頼るのが一般的で、商用コードベースを監査した調査でも87%が少なくとも1つの脆弱性を含んでいたと報告されています。
使うことを避けるのではなく、SBOMで取り込んだOSSを一覧化し、SCAで既知の脆弱性を継続的に突き合わせて管理することが現実的な対策になります。
Q. クラウドサービスを多く利用している場合、ソフトウェアサプライチェーンはどう守ればよいですか？
A. クラウドを多く利用する場合でも、基本は「どの外部サービス・部品に依存しているかを可視化し、その信頼性と脆弱性を継続的に点検する」ことで変わりません。
利用するクラウドやAPI、コンテナイメージも供給網の一部なので、提供元のセキュリティ対策や設定（アクセス制御・暗号化など）を確認し、定期的な点検を続けることが欠かせません。ソースコードや依存ライブラリの検査に加えて、クラウド設定の点検（CSPM）まで一元的に扱えるツールもあり、守る対象の広がりに合わせて使い分けると管理しやすくなります。
Q. 自社でソフトウェアを開発していない企業にも、ソフトウェアサプライチェーン対策は関係ありますか？
A. 自社でソフトウェアを開発していない企業にも、ソフトウェアサプライチェーン対策は関係します。
外部のSaaSやパッケージ、ライブラリを利用する時点で、その提供元が抱える供給網リスクを間接的に引き受けているためです。Log4Shellの事例のように、自社が直接導入した覚えがなくても取り込んだ製品の内部で使われているケースは多く、「自社がどの製品・サービスを使い、脆弱性が公表されたときどう把握するか」を整理しておくことが備えになります。
委託先・調達先の管理という観点でも、複数企業が多層的に関わる国内の開発・委託構造では重要になります。
Q. SBOM（ソフトウェア部品表）の作成は、法律で義務づけられていますか？
A. 日本では、2026年11月時点でSBOMの作成を一律に義務づける法律はありません。
ただし経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」（ver2.0・2024年8月）を公表して導入を後押ししており、米国では政府が調達するソフトウェアにSBOM提供を求める方向、EUではサイバーレジリエンス法（CRA）が製造者に供給網全体のセキュリティ責任を課すなど、制度面の要請は強まっています。
取引先や海外展開の条件としてSBOMを求められる場面も増えつつあるため、義務の有無にかかわらず準備しておく価値があります。
Q. ソフトウェアサプライチェーン対策は、社内で行うのとツール導入・外部診断のどれを選べばよいですか？
A. 対策の担い方には、社内で回す・ツールを入れる・外部に診てもらうという3つがあり、自社の体制や開発の進め方に応じて組み合わせて選ぶのが現実的です。
開発現場が主体的に動ける組織はSBOM作成や依存の検査を内製で進められますが、継続運用の負荷をどう吸収するかが課題になります。日々の点検を開発の流れに自動で組み込みたい場合はSCA・SBOM生成を担うツールの導入が、社内に専門人材が不足し第三者の視点で網羅的に点検したい場合はソースコード診断やペネトレーションテストの外部委託が向きます。
各サービスの診断範囲や料金は、資料をまとめて取り寄せて比較できます。
脆弱性診断・ソフトウェアサプライチェーン対策サービスの料金・資料を一括チェック
MCB FinTechカタログでは、ソフトウェアサプライチェーン対策に役立つ脆弱性診断ツールや受託診断サービスの最新資料を無料で一括請求できます。診断の範囲や料金、サポート体制をまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
