サプライチェーン攻撃が議論されるのは、通常その全容が明らかになってからです。悪意あるパッケージ、改ざんされたソフトウェアアップデート、不正な拡張機能、信頼されたベンダーを介した侵害——これらが表面化して初めて問題として取り上げられます。しかし、そこに至るずっと前の段階で、早期警告サインは目立たない形で存在しているかもしれません。
地下フォーラムやマーケットプレイスでは、サプライチェーンに関連するリスクが明確なラベルで示されることはほとんどありません。投稿に「サプライチェーン攻撃」という言葉は一切登場しないこともあります。GitHubアクセス、プライベートリポジトリ、ソースコード、APIキー、OAuthトークン、クラウド認証情報、CI/CDデータ、ベンダー関連の流出情報——こうした形で情報が売りに出されているのです。
サプライチェーンリスクが問題となるのは、そのアクセスがどこに位置し、どのような信頼関係に触れているかによります。
Flareの研究者による地下フォーラム投稿の調査では、認識することは非常に難しいものの、インシデントレポートとして公表される前の段階でも、ソフトウェアサプライチェーン攻撃の早期警告サインが地下に存在することが多いと示されています。
ソフトウェアサプライチェーン攻撃とは
ソフトウェアサプライチェーン攻撃は、組織を直接狙うのではなく、その組織が依存している信頼されたツール、ベンダー、ソフトウェアコンポーネント、サービス、またはプロセスを標的にします。ソフトウェアの文脈では、サードパーティプロバイダー、開発者アカウント、ソースコードリポジトリ、パッケージレジストリ、CI/CDパイプライン、アップデートの仕組み、プラグイン、SaaS連携などの侵害が含まれます。
この攻撃の危険性は、攻撃者がデリバリーチェーン内の信頼された要素を一度侵害すれば、正規に見えるアクセス、アップデート、コード、または統合機能を通じて、下流の顧客やユーザー、内部システムへと到達できる可能性がある点にあります。
通常のアクセスがサプライチェーンリスクに変わるとき
Flareの研究者が観察した最も顕著な事例として、GitHubに関連したアクセスを宣伝する投稿（以下のスクリーンショット参照）が挙げられます。その投稿には、開発者アカウント、プライベートリポジトリ、アクセス資料、ソースコードの露出への言及が含まれていました。
一見すると、これは単純なアクセス販売のように見えます。しかしGitHubへのアクセスは、単なるコードへのアクセスにとどまりません。シークレット情報、デプロイスクリプト、パッケージ公開ロジック、クラウド認証情報、内部ドキュメント、そしてCI/CDワークフローが露出する可能性があります。
ここからサプライチェーンの問題が始まります。
攻撃者が開発者のIDやプライベートリポジトリへのアクセスを得た場合、ソフトウェアのビルド方法、使用している依存関係、シークレットの保存場所、アップデートの公開方法などを把握できる可能性があります。場合によっては、そのアクセスを利用して顧客や下流のユーザー、または接続された他のシステムへの攻撃が可能になります。
2026年4月のVercelのインシデントも参考になる事例です。信頼されたサードパーティのAIツールとOAuth接続されたSaaSアクセスを介した侵害が、より広範なセキュリティ上の懸念を生み出しうることを示しています（影響を受けた同社は、顧客の機密データやソースコードへのアクセスはなかったと述べていますが）。
地下フォーラムの投稿を分析するアナリストにとって、重要なのはすでに公表されているインシデントそのものではなく、それが示す露出の種類です。つまり、信頼された統合機能、SaaSアカウント、内部ツール、環境変数、そして権限で接続された開発者プラットフォーム——これらのうち一つのリンクが侵害されれば悪用されうるものです。
だからこそ、OAuthアクセス、SaaSツール、環境変数、開発者プラットフォームに言及している地下フォーラムの投稿は、たとえ最初の主張が限定的で未確認であっても、注意を払う価値があります。
ソースコードは知的財産にとどまらない
Flareの研究者はまた、ベンダーデータやソースコードの露出に関する投稿も調査しています。その中には、後に広範なTeamPCPサプライチェーンキャンペーンに関する公開報告で取り上げられたSportradar AGに関する主張も含まれていました。
Sportradarのケースは、侵害されたTrivyスキャナーに関連しており、データベースパスワード、APIキーとシークレットのペア、Kafka認証情報、監視トークンなど、機密性の高い運用データの露出を伴うものでした。
このケースが直接的な侵害を超えて重要な理由はここにあります。こうしたデータは、ベンダーのシステムがどのように接続されているか、どのサービスや統合機能が信頼されているか、そしてどの認証情報がパートナーや顧客にとってリスクをもたらす可能性があるかを明らかにしてしまいます。
サプライチェーンの調査においては、これらの詳細が重要です。なぜなら、流出の最も危険な部分は、盗まれたデータベースそのものではなく、それによって露出するアクセスパスと信頼関係であることが多いからです。
同様の指摘は、TeamPCPとMistral AIに関する公開報告にも見られます。2026年5月、報告によれば、TeamPCPがMistral AIのリポジトリ数百件を売りに出していたとされています。Mistralは主張の一部を否定しましたが、このケースはそれでもなお、ソースコードの窃取を単なる知的財産の問題としてのみ捉えるべきではない理由を示しています。
リポジトリには、認証情報、ビルドロジック、内部サービス名、デプロイワークフロー、APIドキュメント、あるいは顧客や統合機能への参照が含まれている場合があります。
流出したソースコードが直ちに本番環境へのアクセスをもたらさない場合であっても、攻撃者が環境をマッピングし、将来の攻撃経路を特定するのに役立てられる可能性があります。
パッケージ攻撃が示すアクセスのスケール
同じ分析の観点は、パッケージエコシステムのインシデントにも当てはまります。Shai-Hulud（開発者のシークレットを盗み信頼されたパッケージに感染する自己拡散型のnpmサプライチェーン攻撃）に関する公開報告では、侵害されたnpmメンテナーアカウントと悪意あるパッケージアップデートが、認証情報の窃取、CI/CDシークレットの収集、リポジトリ間での伝播に悪用されたことが明らかになっています。
この事例の重要性は、悪意あるコードそのものだけでなく、信頼されたパッケージ公開の仕組みが悪用されたという点にあります。
Shai-Hulud的な活動やサプライチェーン攻撃の競争に関する議論も観察されています。これらの投稿は被害者の手がかりとしては具体性に欠けるものの、脅威の背景として有用です。攻撃者たちが公開されているパッケージ侵害の手法を注視し、それを再利用・改変・拡張する方法を議論していることが分かります。
LiteLLMのサプライチェーンインシデントも最近の好例です。公開報告では、開発者環境とCI/CD環境を巻き込む広範な侵害経路に関連した、PyPIパッケージへの不正な公開が説明されています。LiteLLMはAIゲートウェイとして使用されているため、このインシデントはサプライチェーンリスクがAIインフラや開発者ツールにも広がっていることを示しています。
開発者環境そのものも、魅力的な標的になりつつあります。悪意あるVS Code拡張機能に関する最近の報告では、信頼された開発ツールがリポジトリや認証情報への侵入経路となりうることが示されました。拡張機能、プラグイン、AIコーディングツールは、ソースコード、ターミナル、トークン、内部ワークフローのすぐそばに位置しており、本番インフラの一部でない場合でも、攻撃者にとって価値ある標的となります。
防御側が得られる教訓
今回レビューした投稿は、すべての地下フォーラムにおけるアクセス販売がサプライチェーン脅威であることを証明するものではありません。しかし、ソースコード、開発者アカウント、SaaSアクセス、APIキー、OAuthトークン、パッケージエコシステム、CI/CD関連のデータに関わる投稿を目にしたとき、セキュリティチームがより深い問いを立てるべき理由を示しています。
重要な問いは「データが流出したか？」だけではありません。「このアクセスは、信頼されたソフトウェアのビルド、デプロイ、アップデート、または統合の方法に影響を与えうるか？」という問いも同様に重要です。
防御側にとって、これはサプライチェーンの監視が脆弱性の開示やパッケージアラートにとどまらないことを意味します。組織は、露出した開発者の認証情報、GitHubやGitLabへのアクセス、パッケージレジストリのトークン、流出したリポジトリ、CI/CDシークレット、クラウドキー、OAuthの許可、そして重要なベンダーやソフトウェアプロバイダーに関わる主張を監視すべきです。
地下監視の価値は、これらの早期シグナルを、サプライチェーンのインシデントとして報告される前に認識することにあります。
