2025年のセキュリティを考える：OSS とソフトウェア・サプライチェーンに注目すべきだ

Cyber Insights 2025: Open Source and Software Supply Chain Security

2025/01/15 SecurityWeek — RapidFort の CEO である Mehran Farimani は、「これまでの 10年間を経て、Open Source Software (OSS) は主要な脅威ベクターとなった。その理由は、500万を超える OSS パッケージが提供されているという、きわめて単純な数字にある」と説明する。Endor Labs の Chief Security Advisor である Chris Hughes は、「これまでの 10年間で、OSS の採用は飛躍的に増加しており、減速の兆候は見られない。現時点において OSS は、最新のコードベースの約 90% に存在し、それらのコードベースの 70～80% を占めている」と指摘する。

Lineaje の CISO and SVP である Nick Mistry は、「大半の企業はサードパーティと連携し、その平均は 11社となる。その 11社のサードパーティのうち、98% が侵害を経験している。ある調査によると、平均して 250件の未知の出所を持つコンポーネントが、すべてのアプリケーションに潜んでおり、ソフトウェア・サプライチェーンにおける深刻な露出ポイントを生み出している。そのリスクが、今後の数年にわたって高まる可能性がある」と述べている。

Rapid7 の SVP and Chief Scientist である Raj Samani は、「2021年以降において、サプライチェーン攻撃は 431% も増加しており、2025 年においても、OSS 領域の脆弱性により、さまざまな組織が危険にさらされることは明らかだ。想定すべきは、多くの組織がダイレクトに標的にされるのではなく、サプライヤー／パートナー／サードパーティなどの依存関係を介して侵害される可能性である」と述べている。

OSS は One-to-Any の機会を提供する。つまり、１つの OSS パッケージが侵害されると、複数の企業において侵害が発生する可能性が生じる。サイバー犯罪はビジネスであるため、犯罪者にとっては、労力に対する見返りが重要となる。１つのターゲットを侵害して、複数の被害者につながることが、言うまでもなく効率的である。OSS の数学は機会の大きさを示し、サプライチェーン侵害の数学は、OSS を標的とする犯罪の成功率を示している。

2025年においても、このベクターは、犯罪者たちにより標的にされ続けるだろう。唯一の注目すべき点は、その成功率である。つまり、新たな機会を通じて増加するのか、攻撃と防御の関係が均衡して横ばいになるのか、あるいは、業界や規制の取り組みにより減少するのかという点である。

サプライチェーンに対する OSS の脅威

OSS 開発者には、SBOM を作成する必要はない。その一方で、連邦政府機関や重要インフラ業界などは、SBOM を要求する必要がある。一般的な民間業界におっては、SBOM を要求する必要はないが、DORA などの規制では、OSS に対するテストが求められている。したがって、OSS SBOM が提供されるなら、メリットが生じる。

OSS SBOM は推奨され、有益なものであるが、保証されるものではない。それらの、すべての要因が、大多数の企業で作成／使用されている、大半のアプリケーションを構成する大量のコードにおけるガバナンスと可視性の欠如につながっている。

Tigera の Manager of Security Engineering である Anthony Tam は、「OSS プロジェクトの、保守と更新のレベルは多様である。多くの OSS ライブラリは、メンテナーの空き時間や、個人的な時間により、生み出されているが、更新や変更の頻度が低くなる可能性がある。したがって、ユーザーのプロジェクトにとって、リスクとなる可能性がある。また、ソフトウェア・ベンダーにおいても、OSS ライブラリを用いた製品の構築が繰り返される。したがって、そこでも、OSS はソフトウェア・サプライチェーンのセキュリティのリスクとなり得る」と、コメントしている。

Endor Labs の Product Manager である Jamie Scott は、「OSS は $9 trillion の公共資源であり、革新を劇的に加速させた。つまり、OSS を使用しないという選択は、競争上の不利な立場に立つ選択となり得る。しかし、OSS には共同責任モデルは存在しない。したがって、それを使用すれば、それを所有することになり、リスクも取り込むことになる」と付け加えている。

Endor Labs の Chris Hughes は、「OSS のオープンな性質は、善人にも悪人にも簡単に理解できるものだが、悪人の方が多くの労力を費やしているように思える。悪意の行為者たちは、どれだけ広く OSS が採用されているのか、そして、どれだけエコシステムが不透明で脆弱であるのかを知っている。その一方で、OSS を使用する組織のガバナンスは不十分であり、ここでも透明性が欠如している。その結果として、製品やサービスを購入する消費者は、それらを動かす OSS について、ほとんど情報を得られないでいる」と述べている。

Jamie Scott は、「OSS エコシステムの性質そのものが、サプライチェーン攻撃で大きな役割を果たしてしまう原因となっている。ここでの疑問は、すでに私たちは矢面に立っているのかという点と、それが 2025年まで続くのかという点である。普通に考えれば、それが続くという印象である。つまり、常に OSS は、ソフトウェア・サプライチェーンにとっての脅威であり続ける」と指摘している。

Chris Hughes は、「今後においても、このガバナンスの欠如を悪用する攻撃者は、XZ Utils の場合のように、ソーシャル・エンジニアリングと技術的な攻撃を組み合わせて、広く使用されている OSS コンポーネントを侵害するだろう」と述べている。

イリノイ大学の Amir Barati Farimani は、「外国の組織が OSS エコシステムを悪用し、悪意のコードを注入するケースが増えているため、状況は悪化するだろう。Polyfill インシデントを考えてみてほしい」と指摘している。

Bugcrowd の VP of Operations and Hacker Success である Michael Skelton は、「Log4j／Heartbleed／Shellshock などの深刻な脆弱性は、本質的に予測できないものだった。したがって、たとえば 2025年のタイムフレームを特定することは困難だが、重大なイベントは発生するだろう。多段階の依存関係を持つ、OSS に大きく依存し続ける限り、回避は不可能に思える。したがって、これまでと同じような脆弱性が表面化し、大きな影響を及ぼす可能性がある」と指摘している。

Rapid7 の Raj Samani は、「Log4j のような危機が回避される可能性はあるが、ソフトウェア・サプライチェーン内の弱点を悪用するために、脅威グループが投入している膨大なリソースと高度な技術を認識する必要がある。これらのグループは、常に洗練し続けており、今後の１年において、サプライチェーンの脆弱性に対する集中が、さらに強まるだろう。相互接続されたサプライチェーンに組み込まれ広範に利用される、OSS の脆弱性を悪用する攻撃者が増えているため、組織にとって必要なことは、厳しい脅威に備えることである」と述べている。

AI と OSS

2025 年にサイバーセキュリティを、大きく混乱させるのは人工知能である。率直に言って、どのような事態が展開するのかは分からないが、OSS セキュリティに影響が生じることは確かである。

Chris Hughes は、「OSS 対する AI の脅威という側面は確かに存在する、たとえば、開発者が Co-Pilot や Gen-AI ツールを用いてコードを作成する際に、安全が確保されないライブラリやコンポーネントを使用する可能性が生じる。また、適切なコード・レビューを行わない開発者が、gen-AI が生成するコードを、本質的に信頼してしまう状況などが挙げられる」と述べている。

Jamie Scott は、「脅威アクターにとって、AI と OSS レジストリは、魅力的な悪意の OSS コード作成を支援する。また、企業の開発者が信頼するものにより、サプライチェーンにおける脅威が生み出される可能性がある。ChatGPT などの Gen-AI プラットフォームは、これまで以上にコード生成で使用されている。このトレンドを悪用する最新の攻撃ベクターは、AI パッケージ幻覚攻撃と呼ばれている」と指摘する。

この種の攻撃は、LLM を用いる脅威アクターが、新規かつ妥当なパッケージ名で “幻覚” させ、それを登録するところから始まる。続いて攻撃者は、LLM を用いてコードを生成し、依存関係も提示するが、そこには悪意のコードも追加される。その結果として、npm や PyPI などの OSS レジストリに、きわめて妥当だが、微妙に悪意のあるパッケージが取り込まれていく。

Jamie Scott は、「これらの幻覚名を用いる攻撃者は、悪意のパッケージを公開できるようになり、それらが AI により推奨され、疑いを持たない企業の開発者は、それらを使用するように誘導されていく。多くの Gen-AI コーディング・ユーザーは、作成されたコードの正当性を検証せずに、Gen-AI コードを採用していく。したがって、”信頼するが検証する” という発想を、AI により作成されたソフトウェアに対しても当てはめるべきなのだ。AI システムにより推奨されるパッケージを検証するよう、新世代の開発者をトレーニングする必要がある」と指摘している。

Michael Skelton は、「OSS に対して Gen-AI がもたらす新たな脅威には、微妙な脆弱性を挿入する、AI 駆動型コード合成の可能性などがある。さらに、OSS コード・ベースにおける脆弱性の検出と、悪用パターンの特定が、AI モデルにより高速化される可能性がある」と、付け加えている。

Anthony Tam は、「Hugging Face などのプラットフォームからダウンロードできる、大規模で増え続ける OSS AI モデルのコレクションもある。それらの OSS AI には、コミュニティ主導で開発されるという点で、他の OSSのと同様にリスクがある。そこで考えるべきことは、AI を介した悪意の OSS パッケージの混入ではなく、OSS AI モデル自体を侵害する手口である。従来の OSS サプライチェーンの脅威と、よく似た概念ではあるが、まったく異なる脅威となる」と指摘している。

OSS ベクターを防御する試み

2025年において、OSS とサプライチェーンを防御する上で、将来的な成功を見極める価値のある領域は、SBOM と、新たな Tea プロトコルである。

SBOM

2021年5月に連邦政府は、国家サイバーセキュリティの改善に関する、バイデン大統領令 (EO14028) の一環として、Software Bills of Materials (SBOMs) の使用を推進し始めた。

OSS に SBOM を取り込むという義務があるわけではないが、連邦政府機関においては、OSS を使用する前に SBOM を要求することが事実上義務付けられている。この大統領令には、「利用可能な一般に提供される OSS コンポーネントを用いて、多くの開発者が製品を作成している。SBOM を用いるビルダーであれば、それらのコンポーネントが最新であることの確認と、新たな脆弱性への迅速な対応が可能になる」と記載されている。

連邦政府のプロジェクトに対して、ソフトウェア・ライブラリを提供する OSS 開発者は、SBOM の提供も必要になる。その一方で、大統領令が発布されて約４年が経過している、OSS とサプライチェーンのセキュリティに対する、現状と未来における SBOM の価値については、多様な意見が溢れている。

Tigera の Manager of Security Engineering である Anthony Tam は、「現在においても SBOM は機能しており、将来においては、さらに改善されるはずだ。SBOM は、ソフトウェア・ベンダーと OSS ユーザーに使用されライブラリと。そのライブラリで発見された脆弱性に対する可視性を提供する。したがって、OSS の役に立っている。時間の経過にしたがって、さらに SBOM は効果的なものになるだろう」と述べている。

Kusari の CTO である Michael Lieberman も、「将来における SBOM は、さらに有益になると期待している。SBOM は、OSS に役立ち始めている。SBOM の生成が容易になり、すでに利用されている “npm sbom” などのツールとの統合が進むと、OSS での採用が拡大するだろう。 npm Ver 9 で導入された “npm sbom” コマンドは、Node.js プロジェクトの全ての依存関係のリストを取り込んだ SBOM を、自動的に生成する」と述べている。

その一方で Chris Hughes は、慎重論を唱えている。彼は、「それらは機能しているのだろうか？まあ、ある程度は機能しているのだろう。本当の問題は、商用製品のプロバイダーが、自社製品内の OSS を透明化するために、SBOM を広く採用／使用するようになるかどうかだが、おそらく NO である」と示唆している。

彼は、「その背景として、SBOM の使用に関する継続的な懸念が、原因となっている可能性がある。さまざまなツール間で生成される SBOM の形式や品質に差異がある。また、 SaaS などのソフトウェアを扱う場合にも、SBOM には課題が残される」と付け加えている。

Michael Skelton は、「この業界においては、徐々にではあるが、OSS SBOM の問題が解決され始めているという、一般的な感覚と期待がある。GitHub などのプラットフォーム内での、依存関係グラフと SBOM エクスポートのネイティブ・サポートにより、OSS にとって SBOM は効果的な存在になっている。これらのツールは、チームにおける SBOM 管理を合理化し、依存関係や脆弱性の追跡を容易にするため、SBOM の採用を促進している。より多くの組織が、SBOM をワークフローに統合するにつれて、さらに SBOM は効果的になると期待できる」と述べている。

Exabeam の CPO である Steve Wilson は、「サイバーセキュリティには、常に “But” が付きまとうが、SBOM は立ち止まれない。現時点において、OSS AI モデルという別種の OSS がある。2025年の SBOM の採用は、従来からのソフトウェア以上に拡大する」とコメントしている。

彼は、「AI／ML アプリケーションにより、より高度な BOM フレームワークの需要が高まる。最新の LLM アプリケーションの複雑さに対処するためには、CycloneDX により定義される ML-BOM のような概念が、急速に進化する必要がある。これらのモデルは、動的で不透明なサプライチェーンに依存しており、それぞれの ML コンポーネント／データセット／アルゴリズムにより、固有の脆弱性が生じる可能性がある」と述べている。

さらに Steve Wilson は、「政府機関や防衛機関が、この複雑さを効果的に管理するためには、継続的な更新／複雑な依存関係に加えて、AI／ML システムの出所を追跡するための、拡張された ML-BOM 標準が必要になる。これまでのように、エコシステム全体における相互運用性の実現は、引き続き重要なテーマである。しかし、自動化と新たな規制標準の組み合わせは、ますます複雑化する AI サプライチェーン全体での、コンプライアンスとセキュリティを維持する上で、極めて重要な役割を果たすだろう」と指摘している。

Chris Hughes は、「この概念は AI BOM とも呼ばれている。AI BOM は、AI の複雑さに対応する、少し独特なものである。具体的に言うと、コードだけではなく、モデル／トレーニングデータ／事前トレーニングなどの、AI サプライチェーン全体を取り込むものとなる。市販されている AI のサービスやプラットフォームを使用する、消費者や顧客にとって、それらは透明なものではない。とは言え、採用／使用／形式／完全性／品質の点で、AI BOM は SBOM と同様の課題に直面するだろう」と指摘している。

tea プロトコル

tea プロトコルとは、OSS エコシステムの持続可能性 (およびセキュリティ) を強化するための試みである。ブロックチェーン技術と TEA トークン (ERC-20 トークン) により開発者をサポートし、脆弱性報告に対して報酬を与える。その結果として、円滑な資金の調達による OSS の品質の維持と、安全な開発手法の促進による OSS セキュリティを向上させる。

tea の Web サイトでは、「tea は、ソフトウェア・サプライチェーンの、持続可能性と整合性の向上を目指す分散型テクノロジ・フレームワークである。tea の使命は、OSS のコントリビュータが、自らが生み出す価値の獲得を可能にするものだ」と説明されている。

tea は新しいものであり、2021 年に概念化が始まり、2024年3月初旬に登場している。また、Homebrew オープンソース・パッケージ・マネージャーを開発した Max Howell により推進されているが、2024年初旬から注目されている。

その系譜は堅実だが、現時点での進捗状況は不明である。Sonatype の Security Researcher である Ax Sharma は、「ブロックチェーンによる報酬を、開発者に対して提供する tea のような新しいプロトコルには、いくつかの懸念を抱いている。オープンソース・レジストリを悪用する一部のユーザーに対して、自己への報酬のためのメカニズムを試すよう駆り立てるものだ」とコメントしている。

彼は、「オープンソース・レジストリに暗号窃取や偽パッケージを氾濫させる傾向は、2025年においては、さらに強まる可能性がある。この種の大規模な悪意の公開活動は、レジストリの正当な利用を妨害し、その機能を抑制する恐れがあるため、世界中の開発者に潜在的なリスクをもたらすことになる」と指摘している。

2025 年の OSS とソフトウェアサプライチェーン

すでに、多くの人々が認識しているように、OSS は大規模かつ流動的な脅威でもある。その一方で、コンテンツは絶えず変化／拡大し、ソフトウェア業界にとっての価値は莫大なものである。その証拠として、2000年代の初頭において、EU は内部での使用を公式に推奨し始めてきた。

しかし、OSS の使用が増えるにつれて、OSS による脅威も増えている。つまり、センタライズする機関が存在しなければ、ガバナンスを課して監視する方法も存在しないということだ。このような構造の中で、いくつかの試みが展開されたが、その成功には疑問が残る。したがって、今後においても、OSS による破壊的な侵害を阻止する努力は、継続されるべきだろう。

Nick Mistry は、「何をすべきかを、当局が定義できず指定できない場合において、定義できないことの未達成に対して制裁が課されるという、愚行が繰り返されてきた。それと同様に、2025年には、ソフトウェア・サプライチェーン・セキュリティに関する規制とコンプライアンスが、さらに強化されることが示唆される。バイデン大統領令 (EO14028) により、さらに SBOM の強制実装が推進されるという展開もあり得る」と述べている。

彼は、「すでに陸軍などの部門では SBOM が義務付けられており、さらに多くの部門でも義務付けられると予想されている。AI の急速な導入に伴い、AI サプライチェーンのセキュリティ保護に関して、AI セキュリティに関するガードレールが増えることも予想される」と付け加えている。

ここで問題となるのは、米国内の各州における自治権と党派的な圧力により、全国的な規制に混乱が生じることだ。したがって、従来からの分野ごとの包括的な規制に関しては、たとえば GDPR などの規制を EU が策定し、それを受けるかたちで CCPA／CPRA などが、米国の各州において構築されるという形態が取られてきた。

このプロセスは、今後も続くと予想される。具体的に言うと、EU における NIS2／DORA／ECRA により、商業組織に対して OSS を取り込んだかたちでのセキュリティと透明性が要求され、米国では SBOM を通じて OSS セキュリティが奨励され、CISA の Secure by Design イニシアチブが推進されるだろう。

ただし、この種の規制が強化されると、意図しない結果が生じる可能性もある。WSO2 の VP Strategy である Jonathan Marsh は、「OSS のセキュリティに対する懸念から、世界中で脊髄反射的な規制が発生する可能性もある。それにより、コンプライアンスにおけるコストと責任が、スポンサーであるはずの企業にプレッシャーをかけ、”純粋な” OSS への取り組みが失速する恐れが生じる。その代わりとして、”公正な” ソース・ライセンスが選択され、製品の収益源を強化しながら、リスクを軽減するというシナリオが考えられていくだろう」と警告している。

彼は、「その結果として、セキュリティ基準が不十分／不明な、一部の製品が姿を消すことになるが、副作用も生じる。つまり、マーケットで生き残れる、質の高いエンタープライズグレード OSS の選択肢が狭まることになる」と指摘している。

2025年には、OSS サプライチェーンの問題を解決するための、継続的な試みが推進されると思われるが、それが今年に解決されることはないだろう。SBOM の信頼性は低く、規制がサイバー・セキュリティを向上させるかもしれないが、侵害を防ぐことは不可能だ。率直に言って、今後において、少なくとも当面においては、困難な状況が続くと捉え、それに備える必要がある。

有識者へのインタビューを、テーマごとに編集して、わかりやすく解説してくれる、SecurityWeek の力作ですね。翻訳にも、それなりの時間がかかりましたが、こういう記事は、日本語にして読みたいと思っています。SBOM のところでは、こんなにも、いろんな動きがあるのかと、ちょっと驚きました。よろしければ、2024/12/11 の「ソフトウェア・サプライチェーンが世界を飲み込む：いまなら Marc Andreessen はそう言うだろう」も、ご参照ください。