【ITニュース解説】Reporting AI Supply-Chain Risk With Evidence Levels, Not Inflation

現代のソフトウェア開発において、AI（人工知能）技術の活用が進む中で、AI関連のソフトウェアを開発・利用する際に潜む「サプライチェーンリスク」への注目が高まっている。サプライチェーンリスクとは、ソフトウェアが開発され提供される過程のどこかに悪意のある要素が組み込まれることで、利用する組織全体に被害が及ぶ可能性を指す。このようなリスクが発生した際、状況を正確に把握し適切に報告することが極めて重要だが、セキュリティ報告では具体的な証拠が不十分なまま、漠然と「AIリスク」として語られてしまうことが少なくない。

ここで重要なのは、発見された悪意のある活動の「証拠レベル」を明確にすることだ。例えば、最近発生したApex AcceleratorというAI・Web3ツールを装った悪意のあるパッケージの事例がある。このケースでは、一見するとAI関連の広範なリスクに見えるかもしれないが、実際には証拠の段階ごとにその深刻度が異なっている。単に「パッケージが発見された」という事実と、「実際にデータが盗まれた」という事実では、その後の対応が大きく変わるため、意思決定者にはその違いが明確に伝えられなければならない。

セキュリティの専門家集団であるElastic Security Labsは、このApex Acceleratorキャンペーンを「REF8801」として詳細に分析している。彼らが発見したのは、@apexacc/cliや@apexacc/auditといったパッケージが、悪意のある起動動作、攻撃者によって制御されるモデルルーティング、永続的な悪意のあるサーバーの設置、偽の監査結果の生成、macOS上でのマルウェアの実行、そしてWindows上での情報窃取ツールの仕込みといった活動を行っていたことだ。これらの悪意のあるパッケージは、GHSA（GitHub Advisory Database）やOSV（Open Source Vulnerabilities）といったデータベースにも記録され、その危険性が公にされている。

この種のセキュリティインシデントを報告する際、証拠は以下の4つのレベルに分けて考えることができる。

最初のレベルは「パッケージの存在」だ。これは、あるパッケージの名前とバージョンが、組織が管理するレジストリ、キャッシュ、システムイメージ、またはインベントリの中に記録されていることを意味する。このレベルの証拠は、そのパッケージがどこで使用されたかを調査するきっかけにはなるが、それ自体が悪意のある活動を実行したことを証明するものではない。パッケージが存在したという記録には、そのパッケージの提供元、バージョン、公開者、関連するセキュリティアドバイザリ、そして確認を行った時刻などの情報を含めるべきである。Apex Acceleratorの事例では、GHSAやOSVのような公式なデータベースの情報は、単なる検索結果のタイトルよりもはるかに信頼性の高い情報源となる。

次のレベルは「インストールされたアーティファクト」だ。これは、システムにダウンロードされたファイルやプログラムが、既知の悪意のあるファイルと一致することを示す証拠を指す。具体的には、悪意のあるプログラムを起動するためのランチャーファイルのハッシュ値が一致したり、ダウンロードされた実行ファイルそのものがマルウェアとして識別されたり、セキュリティツールによって隔離された記録が見つかったりするケースだ。このレベルの証拠は、単にパッケージが存在したというレベルよりも強力だ。なぜなら、特定のホスト（コンピューター）上に、パッケージに関連する悪意のあるファイルが実際に置かれていたことを示すからである。調査を行う際には、そのファイルが悪意のあるものと判明した場合でも、すぐに削除するのではなく、そのファイル自体と関連するメタデータ（いつ作成されたか、誰によって作成されたかなど）を保存することが重要だ。また、ファイルのハッシュ値を検証する際には、信頼できるセキュリティ研究機関が公開している情報と照合し、根拠のない要約情報に頼らないように注意が必要である。

三つ目のレベルは「観測された実行」だ。これは、悪意のあるパッケージが実際にシステム上で活動を開始したことを示すプロセスやネットワークの証拠を指す。例えば、パッケージに含まれるスクリプトが悪質なコマンドを実行したり、一時的なファイルが悪意のある内容で書き込まれたり、公開されている攻撃者のサーバー（コマンド＆コントロールサーバー）に接続しようとしたり、システムのプロセスツリーに怪しいプログラムのローダーが出現したりするケースがこれに該当する。このレベルの証拠は、悪意のある実行経路が実際に発生したことを裏付けるものであり、インストールされたアーティファクトの存在よりもさらに深刻な状況を示唆する。しかし、この段階の証拠があっても、必ずしもその後のすべての悪意のある活動が完了したことを証明するわけではない。Apex AcceleratorのWindows版のマルウェアでは、あるサンプルでパッケージングに不具合があり、macOS版のC2（コマンド＆コントロール）サーバーも分析期間中に追加のペイロードを返さなかったケースがある。そのため、報告書は、最初の兆候だけで完全な攻撃の流れを断定するのではなく、実際に得られた証拠に基づいて状況を記述するべきである。

そして、最も深刻な四つ目のレベルは「データ収集または外部送信」だ。これは、情報窃取ツールが悪意のある目的でデータを収集したり、そのデータを外部の攻撃者へ送信したりしたという明確な証拠を指す。例えば、機密情報を含むアーカイブファイルがシステム上で作成されたり、不正なファイルアクセスが行われたり、外部ネットワークへのデータアップロードが確認されたり、攻撃者が利用するTelegramなどのチャットサービスでの活動が検出されたり、またはシステム監視ツール（テレメトリ）から一致する情報が発見されたりするような場合だ。このレベルの証拠がない限り、チームは情報窃取ツールの能力から「潜在的な情報漏洩のリスクがある」と記述することはできるが、「データが盗まれたことが確認された」と断定するべきではない。この区別は非常に重要である。なぜなら、潜在的な情報漏洩のリスクは、封じ込めとレビューを必要とするのに対し、確認された情報漏洩は、法的な通知義務や経営層への異なるレベルでの報告、そしてより抜本的な対応が求められるからである。

インシデント報告においては、外部の調査結果や統計データも考慮する必要があるが、その扱いには細心の注意が必要だ。例えば、「npm」というパッケージ管理システムに関連する製品の活動を検索した結果、多数の観測があったとしても、また、攻撃者が使用したとされる特定のドメインへの接続を検索した結果、少数の観測があったとしても、これらの数字が直接「被害を受けた組織の数」を意味するわけではない。これらの数字は、影響を受けた組織を確立するものではなく、補足情報として扱うべきだ。そのため、これらの数字を「被害者」といった見出しの下に掲載する報告書は、たとえ数字自体は技術的に正確であっても、誤解を招く可能性が高い。

正直で正確な報告書を作成するためには、構造が重要である。まず、発生したイベントと、その情報を最初に特定した主要な情報源を明確に記述する。次に、パッケージの存在に関する証拠、特定のプラットフォームでの実行に関する証拠、ネットワーク活動の兆候、そして外部からの観測結果を順に述べる。その上で、確認された発見事項と、可能性のある情報漏洩や未解決の問題を明確に区別する。最後に、どのシステムを検査すべきか、どの資格情報を変更すべきか、どの永続化メカニズム（マルウェアがシステムに常駐し続けるための仕掛け）を削除すべきかといった、具体的な決定事項を示す。報告書全体を通して、一貫した用語を使用することが重要だ。「パッケージ」は常に「パッケージ」であり、「資産の観測」は「資産の観測」である。「被害者」という言葉は、実際に害を受けたという証拠がある個人や組織に対してのみ用いるべきである。もし証拠が最初の3つのレベルまでしか裏付けていないのであれば、その事実を正直に記述する必要がある。

このような明確な証拠レベルに基づくアプローチは、防御側にとって大きな助けとなる。セキュリティチームは、インシデントの状況を過度に誇張することなく、その深刻度に応じて優先順位をつけて対応することができる。例えば、実際の発見に基づいて、パッケージの検索、エンドポイントの検査、AIモデルと関連設定の確認、そして資格情報の変更といった一連の対策を順序立てて実行できる。また、もし外部の統計で多数の関連活動が報告されていても、自社内での証拠レベルが低い場合、なぜ会社全体にわたる情報漏洩通知を発動する必要がないのかを、経営層や関係者に明確に説明できるようになる。

Apex Acceleratorの事例は、AIサプライチェーンリスクが、多くの場合、単に新しいデータパスを伴う一般的なソフトウェアサプライチェーンリスクであるという強い警告を改めて示している。パッケージの経路、エンドポイントでの挙動、アカウント情報などの露出、そして攻撃者が使用する外部インフラはすべて調査の対象となる。そして、これらの各側面について、それぞれに固有の証拠を収集し、そのレベルを適切に評価することが、現代のデジタルセキュリティにおいて不可欠な姿勢なのである。