公開：
なぜ今、SBOMなのか？ サプライチェーン攻撃の歴史から紐解く
近年のソフトウェア開発において、オープンソースソフトウェア（OSS）の活用は避けて通れないものとなりました。
一方、その利便性の裏には、開発現場が安全だと信じて利用していた公開ライブラリや正規の更新プロセスを悪用するソフトウェアサプライチェーン攻撃によって、企業経営に深刻な影響が及ぶリスクもあります。こうしたなか、対策の切り札として急速に注目されているのがSBOM（Software Bill of Materials：ソフトウェア部品表）です。
本記事では、サプライチェーン攻撃の歴史や背景を紐解きながら、なぜ今SBOMが求められているのかを解説します。
ソフトウェアは「作る」ものから「組み立てる」ものへ。OSS依存のリスクとは
OSSなどの外部部品をつなぎ合わせるアセンブリ（組み立て）は、ソフトウェア開発のスピードと効率を向上させる手法として広まりました。
一方、内容の把握・修正が難しい「自社管理外のコード」がシステムの大半を占めるブラックボックス化が進むと、セキュリティ上のリスクは高まることになります。まずはOSS依存によるリスクについて詳しく見ていきましょう。
OSSを含むコードベースは全体の96%に及ぶ一方で、利用にはリスクも
2023年にSynopsys社が発表した調査データでは、調査対象となった1,700のコードベースのうち、96%がOSSを含むコードベースであったといいます。
開発者がログ出力や認証といった共通機能を一から自作せずに広く普及しているライブラリを活用することで、本来注力すべきビジネスロジックの開発に集中できる点はOSSを利用する大きなメリットといえます。
一方で、外部部品をそのまま利用することは、その部品が抱える欠陥も丸ごと自社システムに組み込んでしまうことを意味します。自社コードをどれほど厳格にレビューしても、外部部品に脆弱性が残っていれば、システム全体の安全性は確保できません。部品同士の連鎖をすべて把握することが困難な状況に陥っている現場は決して少なくなく、この管理の行き届きづらい領域がサイバー攻撃の格好の標的となっている現状もあります。
「見えない部品」が最大の弱点に。サプライチェーン攻撃の構造とは
サプライチェーン攻撃の手法は年々巧妙になっており、時には開発現場が安全だと信じているルートを介して侵入してくることもあります。具体的には、多くの開発者が利用するOSSの管理権限を奪取したり、ビルド環境に不正アクセスしたりすることで、正規のアップデートプログラムの中に、悪意あるコード（バックドア）を紛れ込ませるような手口が挙げられます。
このような攻撃を受けた場合、開発者側が信頼しているパッケージマネージャーを通じてライブラリを更新するだけで、気づかぬうちに外部からの遠隔操作を許す不正なコードを自社システムへ取り込んでしまうことになります。こうした攻撃は、正規の手順で署名された正しい更新プログラムを装って行われるため外部との通信のみを遮断する従来の境界型防御では、プログラム内部に潜む不正な挙動を見抜くことが極めて困難です。
歴史を変えた3つの重大インシデントとSBOMの台頭
サイバー攻撃の手口が、システムの隙を突くものからソフトウェアの供給網を汚染するものへと変化した背景には、世界を揺るがした3つの事件があります。
ここからは、SBOMがなぜこれほどまでに重視されるようになったのか、その決定打となった歴史的な事例を紹介します。
① SolarWinds事件（2020年）
ネットワーク管理ソフトウェアなどを提供している米国のIT企業・SolarWinds（ソーラーウィンズ）が標的となった「SolarWinds事件」では、攻撃者がソフトウェアのビルドシステムを乗っ取り、正規の署名が付いた「正しい更新ファイル」の中に悪意あるコードを紛れ込ませました。この攻撃により、ネットワーク管理ソフトのアップデートを通じて世界中の政府機関や企業へ一斉にバックドアが配布される事態となりました。
この事件で注目したいのは、ユーザーがセキュリティのために行った「最新版へのアップデート」が、そのまま攻撃を招き入れる門戸となった点です。
出荷後の製品を外から検査するだけでは、内部に仕込まれた不正な挙動を見抜くことはできません。この教訓から、ソフトウェアが作られる過程の透明性の担保と、構成部品を細部まで検証する仕組みの構築が大きな課題として浮き彫りになりました。
② Log4jの脆弱性（2021年）
2021年、Javaのログ出力ライブラリ「Log4j」に致命的な脆弱性が発見された際にはIT業界全体が未曽有のパニックに陥りました。
このライブラリは、単体のツールから巨大なシステム基盤まであらゆる場所に部品として組み込まれていたため、利用する企業が「自社のどのシステムでLog4jが動いているのか」をすぐに把握できていなかったのです。
これを受け、多くのエンジニアは膨大なソースコードを力技でスキャンして影響範囲を特定する作業に追われました。このとき、もしも全部品を即座に検索できるSBOMが手元にあれば、調査は数分で完了し、攻撃者に隙を与える前に修正を終えられていたはずです。
この「システムのどこに何が含まれているか即座に確認できない」という恐怖と混乱こそが、SBOM普及の最大の動機となりました。
③ XZ Utils事件（2024年）
2024年に起きた「XZ Utils事件」は、Linuxなどで広く使われる「XZ Utils」に対し、攻撃者が数年にわたって親切な協力者を装い、開発コミュニティの信頼を勝ち取ったうえでバックドアを仕込んだ事件です。この攻撃では、依存関係の深い階層に、特定の条件下でのみ作動する時限爆弾のようなコードが潜伏していました。
幸いにも一人のエンジニアの機転によって事態が発覚したものの、「有名で信頼されているOSSであっても、中身が常に安全である保証はない」ことを世界に知らしめる事例となりました。また、単発の検査では見抜けない、長期にわたる供給網の汚染に対抗するためには、ソフトウェアの構成を継続的に監視し、透明性を担保し続ける必要があるとの認識を広めるきっかけにもなりました。
「隠れた依存関係」がもたらすビジネスリスクの正体
前述したLog4jの混乱が示したように、現代のセキュリティリスクは開発者が直接選んだライブラリだけではなく、その裏側に隠れた膨大な間接依存の部品にも潜んでいます。こうした複雑な連鎖は、把握漏れが生じやすく、ひとたび脆弱性が発見されれば企業にとって致命的な経営リスクとなります。
ここからは、特に死角となりやすい「ひ孫ライブラリ」の脅威と、調査の遅れが招く実害について具体的に見ていきましょう。
直接の脆弱性だけではない。ひ孫ライブラリ（間接依存）の脅威
開発者が直接導入したライブラリが、さらに別のライブラリを呼び出し、それがまた別の部品を……という連鎖の果てにある「ひ孫ライブラリ」は、存在そのものが意識されにくいため、従来の管理体制では死角になりがちです。攻撃者はこの盲点を突き、多くのソフトウェアが共通して利用する末端のマイナーな部品を狙って悪意あるコードを仕込みます。
一つの小さな部品が侵害されれば、それを間接的に呼び出している世界中のシステムが芋づる式に危険にさらされることになります。自社で直接管理していない「ひ孫」以下の階層まで網羅して可視化できていなければ、自社のセキュリティレベルを正確にコントロールすることは不可能なのです。
インシデント発生時の「初動の遅れ」が招く社会的・経済的損失
脆弱性が公表された際、構成リスト（SBOM）を持たない組織は、全サーバーのソースコードを手動で検索するなどの非効率な作業を強いられます。この調査に数日、数週間と費やしている間も、攻撃者は休まず活動を続け、不正アクセスやデータ漏洩の手を広げていきます。
初動が遅れるほど被害は拡大し、サービス停止による機会損失だけでなく、顧客への説明責任を果たせないことによるブランドイメージの低下など、金銭だけでは測れない深刻なダメージを負うことも珍しくありません。有事の際に即座に影響範囲を特定し、対策を打てる体制があるかどうかは、今や企業の存続に関わる重大な分岐点といっても過言ではないでしょう。
リスクを可視化する「SBOM」が開発の必須要件へ
把握しきれない依存関係や巧妙な攻撃からシステムを守るための現実的な手段となるのが、SBOMによる構成の可視化です。SBOMは単なる部品リストではなく、有事の際に迅速な判断を下し、自社製品の安全性を対外的に証明するための不可欠なツールとして位置づけられています。
ここからは、世界中でSBOMが義務化されつつある背景と、現在の開発現場における役割について具体的に見ていきましょう。
バイデン政権の米国大統領令から始まった「透明性」の義務化
2021年5月、米国のバイデン政権が発令した大統領令（EO14028）は、IT業界のセキュリティ基準を劇的に変えました。この大統領令では、政府に納入するソフトウェアに対してSBOMの提供が義務付けられ、中身の構成が不透明な製品は公的機関から排除される方針が明確に示されました。
また、欧州では「欧州サイバーレジリエンス法（EU CRA）」が2024年に発効されており、2027年12月からはSBOMによるコンポーネント情報の開示が本格的に義務化される見込みです。
この動きは日本国内にも波及しており、経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」を策定・公表するなど、ガイドラインの整備が急速に進んでいます。2026年現在、SBOM対応はグローバルビジネスを継続するための必須条件となりつつあるのです 。
SBOMはソフトウェアの「成分表示」であり「保証書」
そもそも、SBOMとは、ソフトウェアに含まれるすべての部品（ライブラリやモジュール）の名称、バージョン、ライセンス、依存関係などを一覧化したデータを指します。
身近なものでたとえるならば、食品のパッケージに印字されている原材料表示をイメージするとわかりやすいかもしれません。消費者がアレルギー物質を確認するように、ソフトウェアのユーザーにも自社のポリシーに反するコンポーネントが含まれていないかを事前に確認する権利があるのです。
サプライヤーがSBOMを提供することは、自社の製品が適切に管理されていることを客観的に示す安全の保証につながります。設計段階からSBOMの自動生成と更新をプロセスに組み込み、常に最新の構成を提示できるようにしておくことは、現代のエンジニアにとって品質を担保するための新しい作法といえるでしょう。
過去を教訓に、組織のレジリエンスを再構築する
本記事で見てきた通り、サプライチェーン攻撃は信頼しているはずのルートを突くため、従来の対策だけでは防ぎきれません 。
外部部品に頼る現代の開発においては「中身を把握していない」こと自体が最大のリスクになります 。個人や現場の注意喚起に頼るのではなく、SBOM（ソフトウェア部品表）を活用して、全部品を常に可視化・管理できる仕組みを整えることが、組織のレジリエンスを高める唯一の道といえます 。
AGESTでは、歴史的な攻撃手口を知り尽くしたプロの知見を活かし、現場に過度な負荷をかけない持続可能なSBOM運用をトータルで支援しています 。純国産ツール「SBOM Archi」なら、複雑な依存関係の可視化からリスクの優先順位付けまでを自動化し、単なるリスト作成に留まらない実効性のある管理基盤を構築できます 。
強固なセキュリティ体制の構築について検討している方は、ぜひお気軽にご相談ください。
