【数字で見る】あなたのコードも狙われている？急増するソフトウェアサプライチェーン攻撃の現実と対策
公開日
Sonatype社の2024年のレポートでは、悪意のあるオープンソースパッケージが新たに512,847件記録され、これは前年比で156%もの増加であることが報告されました。xz-utilsへのバックドア混入事件のように、世界中のサーバーで利用される基本的なライブラリが、たった一人の攻撃者の長期的な工作によって乗っ取られる。これは、もはや対岸の火事ではありません。あなたの会社のソフトウェアも、こうした脅威と無関係ではないのです。
本記事では、2025年5月発表の最新研究「Research Directions in Software Supply Chain Security」で示された具体的な数値を交えながら、ソフトウェアサプライチェーンセキュリティの深刻な現実と、その対策の最前線を明らかにします。この記事を読めば、なぜ今この問題が重要なのか、そして私たちはどこへ向かうべきなのかが見えてくるはずです。
ソフトウェアサプライチェーンへの3つの攻撃経路
ソフトウェアサプライチェーンへの攻撃は、大きく分けて3つの経路から行われると研究では指摘されています。それは「コードの依存関係」「ビルドインフラ」、そして「人間」です。
図表1 ソフトウェアサプライチェーンの攻撃ベクター
- 攻撃ベクター1：コードの依存関係 (Dependencies): 外部ライブラリに脆弱性や悪意のあるコードが注入される経路。
- 攻撃ベクター2：ビルドインフラ (Build Infrastructure): ソースコードを製品化するプロセスが侵害される経路。
- 攻撃ベクター3：人間 (Humans): 開発者自身がソーシャルエンジニアリングなどの標的となる経路。
これらの脅威が、どれほど具体的で、私たちの身近に迫っているのか。数字と共に見ていきましょう。
攻撃ベクター1：コードの依存関係｜あなたのコードの「77%」はオープンソース
Synopsys社の2024年のレポートによると、商用のコードベースの実に96%がオープンソースソフトウェアを含み、コード全体の平均77%がオープンソースで構成されているという報告があります。これは、現代の開発がオープンソースへの「依存」なしには成り立たないことを示していますが、同時に、サプライチェーン攻撃の最大の標的となっていることも意味します。
なぜ依存関係が最大の弱点になるのか？
Log4jのような意図せず作り込まれた脆弱性や、タイポスクワッティング（typosquatting）のような意図的な悪意あるコードの混入など、依存関係に潜むリスクは多岐にわたります。一度サプライチェーンに組み込まれると、そのコンポーネントを利用する多数のプロジェクトへとリスクが連鎖的に拡散します。
【実態①】Mavenでは63%が古いまま：見過ごされる依存関係の更新
脆弱性対策の基本は、依存関係を常に最新の状態に保つことです。しかし、本記事の基となる論文でも指摘されているように、主要なパッケージ管理システムにおいて多くの依存関係が古いまま放置されています。Stringerらの研究によれば、npmで32.2%、PyPIで45.8%、そしてMavenでは実に63.0%もの依存関係が古いバージョンのままでした。更新による互換性の問題を恐れるあまり、既知の脆弱性が放置されている危険な状態が常態化しているのです。
【実態②】人気ライブラリの3,000個が放棄：信頼がリスクに変わる瞬間
さらに衝撃的なのは、たとえ人気のあるライブラリであっても、安全とは限らないという事実です。カーネギーメロン大学のMillerらの研究では、npmエコシステムにおいて、月間10,000ダウンロード以上を誇る人気の依存関係のうち、3,000個がすでに「放棄（abandoned）」された状態にあることが分かっています。メンテナーが不在となったライブラリは、脆弱性が修正されずに放置され、攻撃者による乗っ取りの格好の標的となります。
攻撃ベクター2：ビルドインフラ｜再現できるビルドは、わずか「20%」
たとえソースコードが安全でも、それを最終製品へと変換するビルドプロセスが侵害されれば、すべてが台無しになります。SolarWinds社の事件は、正規のビルドプロセスに悪意あるコードが注入され、正規の署名付きでマルウェアが配布された典型例です。
理想と現実のギャップ：なぜ再現可能なビルドは難しいのか
この種の攻撃への強力な対策の一つが「再現可能なビルド（Reproducible Builds）」です。これは、誰が、いつビルドしても、寸分違わず同じバイナリが生成されることを保証するものです。これにより、第三者がビルド結果を検証し、不正な改ざんがないかを確認できます。しかし、この理想の実現は容易ではありません。本論文の著者らが産業界と政府機関向けに開催したサミットでの議論によれば、現状で 完全にビット単位で一致するビルドは、わずか20% に過ぎないとされています。ビルド環境のわずかな違いが結果に影響を与えてしまうためです。
対策の切り札：SLSA, in-toto, Sigstoreが目指す「信頼の証明」
この課題に対し、SLSA（Supply-chain Levels for Software Artifacts）やin-toto、Sigstoreといった技術が開発されています。これらは、ソフトウェアが「いつ、誰が、どのようにビルドしたか」という来歴（provenance）を記録・検証し、電子署名によってその信頼性を保証することで、ビルドプロセスの透明性と完全性を高めようとする取り組みです。
攻撃ベクター3：人間｜メンテナーの「60%」が無給という現実
技術的な防御をいくら固めても、サプライチェーンの最終的な担い手は「人間」です。そして、xz-utils事件が示したように、人間こそが最も巧みに狙われる脆弱なポイントになり得ます。
xz-utils事件が浮き彫りにした「人的脆弱性」
この事件では、攻撃者が長期間にわたってコミュニティに貢献して信頼を築き、疲弊したメンテナーから巧みにプロジェクトの管理権限を譲り受けました。この背景には、オープンソースエコシステムが抱える構造的な問題があります。
Tidelift社の2024年のレポートでは、オープンソースのメンテナーの60%が無給で活動しており、多くが善意と情熱だけで重要なインフラを支えているという現実が報告されています。このような善意に依存する構造は、攻撃者にとって悪用しやすい脆弱性となっているのです。
「ガードレール」で開発者を守るという発想
対策は、個人の注意深さに頼るだけでは不十分です。組織として、開発者が安全なプロセスから逸脱しにくいように「ガードレール」を設けたり、脆弱性修正を自動化して負担を軽減したりするなど、文化と仕組みの両面から開発者を支えるアプローチが求められています。
未来の論点① SBOM｜期待と現実のギャップ
SBOM（ソフトウェア部品表）は、ソフトウェアの構成要素をリスト化し、透明性を高めるための重要なツールです。しかし、本論文の基となる研究活動の中でも、多くのSBOMが「生成」はされても、リスク分析などのために有効に「利用」されていないという課題が指摘されています。コンプライアンス目的だけでなく、実用的なセキュリティ対策としてSBOMを活用するフェーズへの移行が急務です。
未来の論点② LLM｜コード生成の40%に脆弱性、新たなリスクと可能性
AI、特に大規模言語モデル（LLM）は、サプライチェーンセキュリティに大きな変革をもたらしますが、その影響は一様ではありません。
生産性向上への期待：レビューコメントの7.5%を自動解決
LLMは、脆弱性の修正案を提示するなど、開発者の負担を軽減する大きな可能性を秘めています。本論文の著者らが関わる近年の業界サミットでは、LLMがレビュアーからのコメントの7.5%を自動的に解決できたと報告されています。
新たな脆弱性の源泉：GitHub Copilotが生成したコードの40%に潜む脆弱性
一方で、LLMが生成するコードの安全性には大きな懸念があります。ニューヨーク大学などの研究チームによる調査では、GitHub Copilotが生成したプログラムの40%にセキュリティ上の脆弱性が含まれていたことが示されました。LLMは、それ自体が新たな脆弱性の源泉となりうる、サプライチェーンの新たな構成要素なのです。
まとめ：数字が示す現実と向き合い、次の一歩を踏み出すために
悪意のあるパッケージの156%増加、コードの77%を占めるオープンソース、放置される数千の人気ライブラリ、そしてメンテナーの 60% が無給という現実。この記事で紹介した数字は、ソフトウェアサプライチェーンセキュリティが、もはや専門家だけのものではなく、すべての開発者と組織が向き合うべき喫緊の課題であることを示しています。
特定のツールを導入するだけで解決する問題ではありません。自社のソフトウェアがどのような「依存関係」の上に成り立っているのかを把握し、「ビルドインフラ」の安全性を確保し、そして最も重要な「人間」という要素を支える文化を育むこと。数字が示す厳しい現実から目をそらさず、今日からできる一歩を踏み出すことが求められています。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: