オープンソースからOpenAIへ：サードパーティリスクの進化

シリコンバレーの「速く動いて、壊せ」というマントラは、何よりも成長を優先します。残念ながら、このスピードはソフトウェア・サプライチェーンに脆弱性を効率よく持ち込むことにも及びます。オープンソースのソフトウェアライブラリからAI対応のコーディング支援ツールまで、これらのツールは迅速なイノベーションを可能にしますが、同時に脅威アクターが悪用しようと狙う攻撃経路も生み出しています。

サードパーティリスクは常に問題でしたが、常に最優先事項だったわけではありません。過去10年はランサムウェアが見出しとサイバーセキュリティリーダーの関心を支配してきました。近年では、国家支援型の脅威やサイバー戦のリスク拡大が前面に出てきています。しかし、動機や手口にかかわらず、ソフトウェア・サプライチェーンの脆弱性はサイバー攻撃にとって魅力的な標的です。

SolarWindsの侵害は、サードパーティリスクの危険性に対する警鐘となりました。上流のサービスプロバイダーが企業内へ安全なトンネルを持っているなら、自社の防御がどれほど堅牢でも意味がありません。Log4Jの脆弱性であるLog4Shellは、広く採用され企業サービスに実装されているオープンソースのソフトウェアライブラリにおいて、サードパーティリスクがどのように顕在化し得るかを示しました。脅威アクターは、これらの脆弱性が公開されるやいなや、スキャンを開始しました。

最近、脅威アクターはAI対応のコーディング支援ツールと、その事実に反する誤った回答を「幻覚（ハルシネーション）」として生成しがちな傾向に注目しています。ここでの例は、存在しないソフトウェアライブラリです。脅威アクターが幻覚によるソフトウェアライブラリを特定すると、同じ名前で悪意あるバイナリを登録します。開発者は気づかないまま、これらの悪意あるパッケージを自分のコードに組み込んでしまいます。サイバーセキュリティ研究者はこの攻撃を「slopsquatting」と呼んでいます。

その結果、DevOpsとサイバーセキュリティの双方が、これらのリスクを特定し是正することに、より能動的に取り組む必要があります。DevOpsではこれを「シフトレフト」と呼び、サイバーセキュリティでは「ブームの左側（left of boom）」と呼びます。このアプローチの基盤は可視性です。

サードパーティリスクの遺産

サードパーティリスクは決して新しい現象ではありません。サプライチェーン攻撃の例は少なくとも20年前まで遡ります。2003年には、Linuxカーネルにバックドアを挿入しようとした試みが悪名高く知られています。しかし、組織がサードパーティリスクに本腰を入れ始めたのは、2020年のSolarWinds侵害以降でした。

SolarWinds侵害は、ロシアの高度持続的脅威（APT）によって実行された高度なサプライチェーン攻撃でした。侵害されたソフトウェア更新により、18,000の顧客に悪意あるバックドアが配布され、脅威アクターは米国の複数の連邦機関を含む高価値標的へアクセスできるようになりました。

その1年後、Log4Jの脆弱性であるLog4Shellが、大規模なサプライチェーン・セキュリティ危機の原因となりました。Log4JはJavaエコシステムで人気のオープンソースのロギングライブラリで、数億のアプリケーションやデバイスに組み込まれています。こうした脆弱性は、ミッションクリティカルな資産や、パッチ適用が困難または不可能なレガシー技術を含む運用技術（OT）環境では、さらに深刻な問題になります。

多くの組織は、イノベーションを加速しコストを削減できるためオープンソースのソフトウェアライブラリを活用していますが、Log4Jの場合、この利便性はソフトウェアを露出したままにするという代償を伴いました。Log4Shellの公開後数週間、組織は自社ベンダーのどれがLog4Jをソリューションに組み込んでいるのかを特定しようと奔走し、ベンダーは是正計画を展開しながら、すべてが管理下にあることを顧客に保証しなければなりませんでした。

お願いだから、私のノリを壊さないで

「Vibe coding」は、生成AIにおける注目の「キラーアプリ」として台頭しています。GitHubによれば、開発者の97%が過去1年にAIツールを使用しました。しかし、AI生成コードへの過度な依存は、コードベースに脆弱性を持ち込んでいます。

学術研究者は（PDF）、主要なコード生成ツール16種のうち、推奨されたソフトウェアパッケージ全体の19%が存在せず、幻覚によるソフトウェアパッケージの43%は毎回繰り返し提示されることを発見しました。

悪意ある攻撃者は、これらの幻覚によるソフトウェアパッケージを能動的に見つけ出し、同名の悪意あるコードを先回りして登録しています。Python Software Foundationの開発者は、サイバースクワッティングやタイプスクワッティングに似ていることから、この攻撃を「slopsquatting」と名付けました。

例えば、悪意あるソフトウェアパッケージ「ccxt-mexc-futures」は登録され、公開ソフトウェアリポジトリであるPyPlで1,000回以上ダウンロードされました。このケースでは、マルウェアが暗号資産取引に用いられる主要な操作を改変しました。しかし、最近のShai-Huludワームの成功がPyPl全体に複製して広がったことを踏まえると、slopsquattingは将来、注目度の高いワームを開始するための攻撃ベクトルになり得ると考えられます。

企業の外側で、攻撃の前に

これらのサードパーティリスクの例には多くの違いがあります。SolarWinds侵害は、サプライチェーンの完全性という問題を浮き彫りにした、高度に標的化されたサプライチェーン攻撃でした。Log4Jの脆弱性は、当時公開された中で最も広範に及ぶ脆弱性だと考えられ、サプライチェーンの可観測性の必要性を提起しました。slopsquatting攻撃の出現は、AI対応のコーディング支援に対する、より強い監督を求めています。

ここでの共通テーマは、より高い可視性の必要性です。サプライチェーン全体にわたるソフトウェア依存関係の複雑さは、脆弱性やリスクの監視を困難にします。DevOpsは「シフトレフト」して、リスクについてより能動的かつ透明性の高い姿勢を取る必要があります。そうすることで、サイバーセキュリティチームは、悪用される前（すなわち、ブームの左側）にこれらのリスクを特定し是正できます。

組織は、Software Bills of Materials（SBOM）を用いてソフトウェアの来歴を監査し、各依存関係の出所とバージョンを追跡できます。静的アプリケーションセキュリティテスト（SAST）と動的アプリケーションセキュリティテスト（DAST）は、攻撃で悪用され得る脆弱性を特定できます。繰り返しになりますが、このアプローチでは可視性が鍵です。組織は、特定アプリケーションの事業影響を評価するために、包括的な資産インベントリから着手する必要があります。

サイバーセキュリティチームは、異常なシステム挙動や新たな接続といった、行動・攻撃の指標（IOA）も監視できます。このような行動上の異常を特定することは、機械学習がパターン認識と通常状態からの逸脱の検出を得意とするため、AIの理想的なユースケースです。

AI対応のコーディング支援ツールに関しては、開発者は不十分なアカウント認証や入力検証の弱さといったリスクを認識する必要があります。開発者は、MFAのロックアウトや入力サニタイズなど、セキュリティをプロンプトに組み込むべきです。また、これまで以上に、必須の人手レビューとアプリケーションセキュリティテストを含めることが不可欠です。