ソフトウェア・サプライチェーンが世界を飲み込む：いまなら Marc Andreessen は そう言うだろう

Lessons From the Largest Software Supply Chain Incidents

2024/12/11 DarkReading — 2011年の Marc Andreessen の言葉を覚えているだろうか。それは、「ソフトウェアが世界を飲み込んでいる」というフレーズであり、13年以上が経ったいまも、真実味を深め続けている。産業界はソフトウェアにより変革され、世界経済の活性化においてもソフトウェアは不可欠だ。つまり、世界はソフトウェアで動いている。いまの企業に求められるのは、ビジネス環境における苛烈な競争に生き残ることであり、そのために、かつてないスピードで大量のソフトウェアが生み出されている。

イノベーションは素晴らしいものであるが、ソフトウェアの構築と配信の量と速度が増大すると、ソフトウェア・サプライチェーンの問題も発生の頻度を高めてくる。これまでの 10年間において、この問題が何度も起こってきたことを、私たちは見ている。

昨年の今ごろに明らかになったのは、Okta における深刻なセキュリティ侵害の発生である。悪意の人物がサポート管理システムを通じて、顧客の個人データにアクセスするという侵害であるが、そこで浮き彫りにされたのは、サードパーティ・リスクの危険性である。

2020年には、SolarWinds プラットフォームの更新メカニズムが侵害され、悪意のソフトウェアの送信に使用され、18,000件以上の顧客に影響が及んだ。また、2017 年には、ソフトウェアの既知のセキュリティ欠陥を修正しなかった Equifax が、大規模なサイバー侵害に見舞われた。

これまでの 10年間において、数多くの組織がソフトウェア・サプライ チェーン攻撃に頭を悩ませてきており、上記の例はほんの一部に過ぎない。残念なことに、この種の攻撃は減速の兆しを見せることはなく、その正反対に、増加の一途を辿っている。

ソフトウェア・サプライチェーン攻撃に関する調査によると、２日に１回の割合でインシデントが発生しているという。Gartner の予測によると、2025年までに 45% の組織がソフトウェア・サプライチェーン攻撃を経験するという。驚くべきことに、あるレポートでは、過去３年間において、この種の攻撃が 742% も増加しているという、驚異的な結果が示されている。

ソフトウェア・サプライチェーン攻撃の増加は、いくつかの要因の組み合わせに起因している。多くの場合において、それぞれの組織におけるリスクの広範さが、正確に認識されていないという問題がある。ソフトウェアの調達／開発／運用が、CI/CD (Continuous Integration／Continuous Delivery) やクラウドへと移行するにつれて、サプライチェーンの構造が危殆化している。

その一方で、ベンダーが提供するプラットフォームやソフトウェアに、高度なセキュリティ対策が組み込まれた結果として、一般的な攻撃ベクターの悪用が困難になった。しかし、それがトリガーとなり、脅威アクターたちは新しい脆弱性を発見し、より創造的な攻撃を仕掛けるようになってきた。

最近では、コーディング・アシスタントなどの領域において、生成 AI (GenAI) ツールの採用が急増したことで、監視が困難な新たなセキュリティ・ギャップが生じている。それと同時に、攻撃者自身が GenAI を活用して、より高度な攻撃を、より大規模に実施している。

いまの企業にとって必要なことは、ソフトウェア・サプライチェーンの各リンクにおいて、ハイレベルなセキュリティを維持しながら、高品質のソフトウェアを迅速に作成してリリースするという、相反するベクトルの考慮しながら、適切なバランスを早急に見つけ出すことである。

イノベーションを妨げることなく、セキュリティを維持する方法は、以下のとおりである。

ベンダーを継続的に徹底的に審査する (GenAI ツールも同様に)

Okta の侵害から学ぶべきものがあるとすれば、顧客のプライベート・データや機密情報をサードパーティ・ベンダーに任せる際には、その相手を慎重に審査する必要があるということだ。その一方で、開発部門において使用されるサードパーティ・コードについては、ブラック・ボックスであると想定することが多過ぎる。

組織において必要なことは、各ベンダーの SBOM (Software Bill of Material) を確認し、コードに含まれるオープン ソース／サードパーティのコンポーネントを認識し、潜在的な脆弱性を特定することでる。また、ベンダーのセキュリティ実績を評価し、そのポリシー／手順／認定を確認する必要がある。

ベンダーの審査いついて言うなら、契約開始時にチェックして、その後は忘れて良いというものではない。審査のプロセスは、継続性を持つものでなければならない。つまり、組織は、継続的に質問を行い、ベンダーの新しいサービス／ポリシー／コンプライアンス認証などについて、常に把握する必要がある。

注意すべき点として挙げられるのは、GenAI ツールに関しても、サードパーティ・ベンダーと同レベルの、精査する必要があるという点だ。組織にとって必要な可視性は、LLM が機能する様子の把握、および、トレーニングで用いられたデータの内容、モデルにおけるオープン性とクローズド性、収集されるユーザー入力、生成されるコンテンツの利用形態などにまたがるものとなる。

また、LLM が生成するコードの正確性と品質についても評価する必要がある。そして、不正確またはバグのあるコードが生成されるケースを軽減するための、計画について準備しておく必要がある。

オープンソース・プロジェクトを慎重に使用する

迅速な開発とイノベーションにおいて、オープンソース・プロジェクトは不可欠な存在である。しかし、組織におけるオープンソース・コードの使用については、十分に注意する必要がある。公開されダウンロード可能なオープン ソース・プロジェクトに、昨年だけで 245,032 個の悪意のパッケージが含まれていたことを、Sonatype の研究者たちが発見している。

オープンソース・リポジトリは、脅威アクターたちの主要ターゲットであり、単一のパッケージを攻撃することで大混乱を引き起こし、ユーザーである企業と顧客のエコシステム全体に、甚大な被害を引き起こす危険性を秘めている。

組織にとって必要なことは、 OpenSSF Scorecard／System Package Data Exchange (SPDX)／OpenVEX などの、厳格なコンプライアンス・フレームワークに準拠している、オープンソース・プロジェクトのコードだけを使用することである。

それにより、コードを借用する前に、プロジェクトのセキュリティ衛生状態を把握できる。さらに、組織にとって必要なのは、SCA (Software Composition Analysis) の採用であり、また、オープンソースの脆弱性が判明した場合に備えた、善後策としての計画の立案である。

ソフトウェア配信プロセス全体のセキュリティを評価する

ソフトウェア・サプライ チェーンの保護において、万能薬は存在しない。組織が行うべきことは、設計／開発／試験／展開／保守という、ソフトウェア配信プロセスの各ステップにおいて、セキュリティを入念に評価することである。

CI/CD パイプラインの全体を通じて、セキュリティ対策を組み込むことで、開発プロセスの早期において脆弱性を特定／修正し、プロダクション環境での本格的な侵害を防ぐことが可能になる。それを実現するためには、潜在的な問題にフラグを立てる自動セキュリティ・ソリューションや、既知の脆弱性についてコード・スキャンを行う SCA (Source Composition Analysis)、不正アクセスを防止するためのソースコード・アクセス制御の実装が必要となる。

セキュリティの追いかけっこに終わりはない。業界が知識を広げ、セキュリティ強化に懸命に取り組む一方で、攻撃者も同様に、悪質な活動を計画して実行している。

ソフトウェア・サプライチェーンを標的とする活動は増大するため、それ対する防御には、特別な注意を払う必要がある。ベンダーを慎重に審査し、オープンソースを慎重に活用し、ソフトウェア配信プロセス全体を保護することが必須となる。それにより組織は、ソフトウェア・サプライチェーンにおける、イノベーションの推進とセキュリティ維持の、適切なバランスを理解し実現できるだろう。

Marc Andreessen の言葉から、13年が経過したそうです。もう 13年という感じはなく、圧倒的に まだ 13年です。この間に、さまざまなことが起こり、誰もが忙しくしていたと思いますが、こうして Marc Andreessen の言葉を反芻してみると、彼の言っている通りの世界になったと、認めざるを得ません。こんな記事を提供してくれる、Apiiro の Eldan Ben-Haim さんに感謝です。よろしければ、カテゴリ SupplyChain を、ご参照ください。