ビルド チェーンが汚染されていても、プロダクトはクリーンである可能性があります。
それが、現代のソフトウェア サプライ チェーンの事件から得られた厳しい教訓です。企業は慎重にコードを書き、人気のあるパッケージを使用し、署名された出所に依存しながらも、通常のツールへの正当に見えるルートを通じて悪意のあるコードを受け取る可能性があります。
2026 年 5 月、Hacker News は、Mini Shai-Hulud キャンペーンに関連した TanStack サプライチェーン攻撃が 2 台の OpenAI 従業員デバイスに到達し、macOS のアップデートを強制したと報告しました。 OpenAI、TanStack、StepSecurity、Snyk などからの公開レポートでは、開発者のマシン、CI/CD ワークフロー、npm パッケージ、およびダウンストリームの消費者をターゲットとした認証情報に焦点を当てたマルウェア キャンペーンについて説明しています。
この記事では、公開レポートとベンダーのガイダンスを使用します。これには、影響を受ける企業に関する個人情報は含まれません。
すべての製品チームにとっての教訓は直接的です。ビルド システムは運用の一部です。開発者のデバイスは攻撃対象領域の一部です。パッケージの出所は役に立ちますが、実行時の動作レビュー、秘密の衛生状態、および応答の証拠に代わるものではありません。
公的報道が語ること
2026 年 5 月 15 日、Hacker News は、OpenAI が、企業環境内の 2 台の従業員デバイスが TanStack に対する Mini Shai-Hulud サプライチェーン攻撃によって影響を受けたことを明らかにしたと報じました。 OpenAI は、ユーザーデータ、実稼働システム、または知的財産が不正な方法で侵害または変更されたことはないと述べました。 OpenAI はまた、予防措置としていくつかの製品のコード署名証明書をローテーションし、macOS ユーザーには 2026 年 6 月 12 日の期限までに更新するようアドバイスしました。
TanStack は、このインシデントには侵害された公開パスと悪意のあるパッケージ バージョンが関与しているとの続報を公開しました。 StepSecurity は、TeamPCP が Mini Shai-Hulud の新たな波を立ち上げ、正規の npm パッケージを侵害し、ハイジャックされた CI/CD パスを使用して悪意のあるバージョンを公開したと報告しました。 Snyk は、2026 年 5 月 11 日の 19:20 から 19:26 UTC の間に、CI 名前空間内の 42 のパッケージにわたって 84 個の悪意のある npm パッケージ アーティファクトが公開されたと報告しました。
StepSecurityによると、この攻撃では、ハイジャックされたOIDCトークンを使用し、プロジェクト独自のGitHub Actionsリリースパイプラインを通じて悪意のあるバージョンが公開されたという。 Snyk 氏は、ビルド パイプライン自体がハイジャックされたため、悪意のあるパッケージには有効な SLSA ビルド レベル 3 の出自が含まれていると強調しました。その点が重要です。来歴は、パッケージが予期されたビルド システムを介して提供されたことを正しく示しました。予想されるビルド システムが問題でした。
いくつかの公開記事では、資格情報の盗難が主な目的であると説明されていました。報告されたターゲットには、GitHub トークン、クラウド認証情報、SSH キー、CI/CD シークレット、開発者ツール ファイル、AI コーディング アシスタント構成パスが含まれます。
この事件が重要な理由
最新の開発は共有パッケージに依存しています。単一の Web アプリケーションは、数百または数千の直接的および推移的な依存関係をプルできます。チームは、GitHub Actions、npm、パッケージ来歴、OIDC、署名、コンテナー、シークレット マネージャー、AI コーディング ツール、デスクトップ アプリ、開発者のラップトップを使用します。各ピースはスピードアップに役立ちます。各ピースは制御が必要なパスを作成します。
TanStack のケースは、これらの道の交差点に位置するため、重要です。
影響を受けるパッケージは広く使用されていました。悪意のあるバージョンは、正規に見えるインフラストラクチャを通じて公開されました。下流の消費者は、通常の開発または CI の一部としてそれらをインストールできます。開発者の資格情報とローカルの機密情報が貴重なターゲットになりました。このインシデントは、深刻なセキュリティ リソースを備えた AI 企業に影響を及ぼしました。これは、リスクが成熟したチームにも関係することを証明しています。
ビジネス翻訳は簡単です。製品がオープンソース パッケージと自動ビルドに依存している場合、セキュリティ コンターには、メンテナ、CI ランナー、パッケージ レジストリ、トークン、ローカル ワークステーション、署名 ID、開発者ツールが含まれます。
攻撃経路の仕組み
公開調査では、構築および公開インフラストラクチャを悪用したキャンペーンについて説明されています。正確な連鎖はレポートによって異なりますが、防御モデルは安定しています。
正規のパッケージ エコシステムが侵害されました。悪意のあるパッケージのバージョンが公開されました。これらのバージョンをインストールした開発者または CI システムは、認証情報を盗む動作を実行する可能性があります。マルウェアはシークレットとトークンを検索しました。一部のレポートでは、開発者ツールと AI コーディング アシスタントの構成における永続性フックについて説明されています。認証情報が盗まれると、キャンペーンがさらに多くのパッケージに広がったり、内部リポジトリやクラウド アカウントに到達したりする可能性があります。
つまり、最初に感染したマシンが最終ターゲットではない可能性があります。価値のあるターゲットは、次のトークン、次のリポジトリ、次のメンテナ アカウント、次のパッケージ、または次の CI ジョブです。
これが、サプライチェーンの対応が動きを前提とする必要がある理由です。パッケージの削除は 1 つのステップにすぎません。チームはまた、マシンを検査し、シークレットをローテーションし、CI ログを確認し、パッケージのロックファイルをチェックし、リポジトリのアクティビティを検証し、異常なパッケージ公開を探す必要があります。
ダメージはどのように見えるか
OpenAI に関する公開レポートでは、ユーザー データ、実稼働システム、または中核となる知的財産が不正な方法で侵害または変更されたことはないと述べています。それは重要であり、保存する必要があります。
より広範なリスククラスは依然として深刻です。
最初の損害カテゴリは、認証情報の漏洩です。開発者マシンには、多くの場合、GitHub トークン、パッケージ トークン、SSH キー、クラウド プロファイル、API キー、環境変数、パスワード マネージャー セッション、および一時的な認証情報が保持されます。 1 台のマシンで多くのシステムにアクセスできます。
2 番目のカテゴリはリポジトリの公開です。読み取り専用アクセスであっても、アーキテクチャ、内部サービス、過去に誤ってコミットされた秘密、展開パターン、製品計画、セキュリティ ツール、および顧客固有のロジックが明らかになる可能性があります。
3 番目のカテゴリは、署名と配布のリスクです。 OpenAI の証明書ローテーションは、コード署名 ID が重要である理由を示しています。攻撃者が署名資料を悪用したり、署名された成果物に関して混乱を引き起こしたりする可能性がある場合、ユーザーと顧客は迅速に明確にする必要があります。
4 番目のカテゴリは、下流の爆発半径です。人気のあるパッケージは、一度に多くの企業内に存在します。悪意のあるリリースは、数時間以内に製品チーム、CI 作業者、テスト環境、開発者のラップトップ、ステージング システム、ビルド キャッシュに影響を与える可能性があります。
5 番目のカテゴリーは監査の圧力です。サプライチェーンのインシデントの後、顧客は、どのパッケージがいつ、どこに、誰がアクセス権を持ったか、どのシークレットがローテーションされたか、期間中にどのリリースがビルドされたか、そして最終製品が影響を受けたかどうかを尋ねます。
6 番目のカテゴリは AI ワークフローの公開です。開発者ツールには、AI アシスタント、ローカル エージェント、エディター統合、プロンプト、モデル キー、自動化フックが含まれるようになりました。これらのパスを変更する資格情報を盗むパッケージは、通常のクリーンアップを通過して日常作業中に再アクティブ化される可能性があります。
通常のコントロールがこのクラスを見逃す理由
多くのチームは、パッケージ レピュテーション、ロックファイル、署名済みコミット、CI 権限、来歴、および自動依存関係スキャンに依存しています。これらのコントロールが役に立ちます。盲点もあります。
正規のパッケージが侵害されると、レピュテーションは失敗します。
悪意のあるバージョンが許可された更新期間中に侵入した場合、または一時的なブランチに到達した場合、ロックファイルは失敗します。
承認されたビルド パイプラインが不正なアーティファクトを作成すると、来歴は失敗します。
悪意のある動作が新しいものである場合、難読化されている場合、またはインストール スクリプト中に配信された場合、依存関係のスキャンは失敗します。
開発者のマシンの管理が緩い場合、または疑わしい動作が通常のパッケージ ツールのように見える場合、エンドポイントの検出は失敗します。
トークンがローカル ファイル、CI ログ、シェル履歴、アプリケーション キャッシュ、またはエディター プラグインにも存在する場合、シークレット マネージャーは失敗します。
答えは重ねられた証拠です。パッケージ ポリシー、動作分析、制限付き CI 権限、シークレット ローテーション、開発者エンドポイント制御、レジストリ監視、インシデント Runbook は連携して機能する必要があります。
チームが今検査すべきこと
依存関係のインベントリから始めます。公開インシデント期間中に、影響を受けるパッケージの直接的および推移的な使用を特定します。パッケージのロックファイル、npm キャッシュ、CI ログ、コンテナーのビルド ログ、開発者マシン、アーティファクト リポジトリを確認してください。
インストール スクリプトを確認します。インストール中にコードを実行するパッケージは、特別な精査に値します。 CI で可能な場合はライフサイクル スクリプトを無効にします。ホワイトリストを必要とするパッケージにはホワイトリストを使用してください。
CI トークンを制限します。 OIDC トークンとパッケージ公開トークンは、有効期間が短く、範囲が狭く、特定のジョブに関連付けられている必要があります。ビルド システムは、あらゆるワークフローに広範なレジストリまたはクラウド権限を与えるべきではありません。
ビルド権限とリリース権限を分離します。プル リクエスト ビルドには、署名付きリリース ビルドと同じシークレット アクセスを持たないでください。テスト ワークフローでは、運用成果物を公開できません。
パッケージの公開を監視します。新しいパッケージのバージョン、異常な公開時間、メンテナーの変更、予期せぬ出所、インストール スクリプトの変更、および依存関係グラフの突然の変化に関するアラートを発します。
開発者のエンドポイントを強化します。開発者のラップトップには、EDR、ディスク暗号化、デバイス管理、ローカル秘密管理、ブラウザー セッションの衛生管理、AI コーディング アシスタントとプラグインの明確なルールが必要です。
規律を持ってローテーションします。開発者マシンまたは CI ランナーが悪意のあるパッケージを実行した可能性がある場合は、その環境から到達可能なすべてのシークレットをローテーションします。これには、GitHub トークン、npm トークン、クラウド キー、SSH キー、API キー、パッケージ レジストリの資格情報、CI シークレット、および漏洩が考えられる場合の署名資料が含まれます。
証拠を保存します。影響を受けるパッケージ、マシンのチェック、ログのレビュー、シークレットのローテーション、ワークフローの変更、検証されたリリース アーティファクトの記録を保持します。
より安全なビルド チェーンのための制御モデル
より安全なビルド チェーンは、権限の境界から始まります。
開発ビルドには限定された秘密を含める必要があります。リリース ビルドは、制御されたワークフローで実行する必要があります。パッケージの公開には、ナロー トークン、名前付きメンテナー、保護されたブランチ、およびレビューが必要です。クラウド展開には別の権限パスが必要です。署名には個別の保護と強力な監査が必要です。
有用な制御モデルは、次の 5 種類の権限を分離します。
- コード権限: ソースコードを変更できる人。
- ビルド権限: どのワークフローがアーティファクトを作成できるか。
- 発行権限: どのワークフローがパッケージまたはリリースを発行できるか。
- デプロイ権限: どのワークフローが実稼働インフラストラクチャに到達できるか。
- 署名権限: ユーザーが受け入れるアーティファクトを作成できるシステム。
1 つのトークンまたは 1 つのワークフローが複数の種類の権限を持つ場合、サプライ チェーン インシデントはさらに大きくなります。広範囲のトークンを盗む悪意のあるパッケージは、開発者ワークステーションからリポジトリ、リポジトリから CI、CI からパッケージ レジストリ、そしてパッケージ レジストリから顧客に移動する可能性があります。
その動きを減らしてください。権限を狭くしてください。雇用期間を短くしてください。秘密を日常的なテスト ワークフローから遠ざけてください。リリースジョブにはより強力なレビューが必要です。
開発者の輪郭における AI ツール
AI コーディング ツールはローカル ワークステーションを変えます。プラグイン、エージェント、モデル キー、コンテキスト ウィンドウ、ローカル キャッシュ、エディター フック、および場合によってはバックグラウンド プロセスを追加します。最新のサプライ チェーン マルウェアに関する公開レポートでは、AI コーディング アシスタントの構成パスへの関心が説明されています。これらのパスには有用な秘密が含まれたり、永続化の機会が生み出されたりする可能性があるからです。
チームは AI ツールを開発者のセキュリティ輪郭の一部として扱う必要があります。
つまり、承認された AI ツールのインベントリを作成し、拡張機能を制御し、ローカル ストレージを確認し、API キーを保護し、機密データが関係するリポジトリ コンテキストを制限し、予期しない構成変更を監視します。これは、インシデント対応中に AI アシスタントがアクセスできるものを定義することも意味します。チームがそれを封じ込めようとしている間、侵害された開発者マシンは外部ツールにリポジトリ コンテキストを送信し続けるべきではありません。
これは実践的な規律です。製品チームは AI ツールを使用しながらも制御を維持できます。会社にはルール、監視、証拠が必要です。
サプライチェーン訴訟後にバイヤーと投資家が尋ねること
真剣な購入者は、ソース コードからリリースされた製品まで直接接続することを望んでいます。
彼らは、依存関係がどのように承認されるかを尋ねます。パッケージが固定されているかどうかを尋ねられます。彼らは、悪意のあるパッケージがどのように検出されるかを尋ねます。インストール スクリプトを許可するかどうかを尋ねられます。どの CI ワークフローを公開できるかを尋ねます。彼らは秘密がどのように保存されるかを尋ねます。開発者エンドポイントが管理されているかどうかを尋ねます。彼らは、コード署名がどのように保護されているかを尋ねます。彼らは、会社がどれだけ早くきれいな状態から再建できるかを尋ねます。
投資家は関連する質問をします。製品が価値のあるものになった場合、企業は大規模なリリース パスを保護できるでしょうか?
曖昧な答えは会話を遅らせます。明確な証拠パッケージがそれをスピードアップします。パッケージには、依存関係ポリシー、CI 権限モデル、シークレット ローテーション プロセス、エンドポイント管理状態、リリース署名コントロール、インシデント ランブック、および最近のレビュー結果が含まれている必要があります。
その証拠が商業的な強みを生み出します。購入者は、製品を作成する経路の制御を失うことなく、迅速に出荷できる企業を求めています。
認定資格がカバーすべき内容
ソフトウェア サプライ チェーンの輪郭について、StOFU セキュリティ認定では、リポジトリ、CI/CD システム、パッケージ マネージャー、アーティファクト レジストリ、署名パス、開発者エンドポイント コントロール、AI コーディング ツール、シークレット ストア、リリース ワークフローに名前を付けることができます。
レビューには悪用可能性に関する質問を含める必要があります。悪意のある依存関係から何が読み取られるのでしょうか?どのジョブ シークレットがプル リクエストに公開されますか?どのワークフローを公開できますか? 1 つのジョブを超えても生き残るトークンはどれですか?どのマシンに署名資料が保管されていますか?プライベート コードにアクセスできる AI ツールはどれですか?侵害されたパッケージが実行されたこと、または実行されなかったことを証明するログはどれですか?
認定には、マテリアル変更のトリガーもリストする必要があります。新しいレジストリ、新しいリリース システム、新しい AI コーディング アシスタント、新しい署名プロセス、主要なリポジトリの移行、または新しいクラウド デプロイメント パスでは、レビューを再開する必要があります。
これにより、証明書が有効な状態に保たれます。これは、静的なマーケティング成果物ではなく、ビルド チェーンの生きた証拠になります。
SToFU はこのクラスのリスクとどのように戦うか
SToFU は、製品セキュリティの輪郭の一部としてソフトウェア サプライ チェーンをレビューします。私たちは、アプリケーション コード、依存関係リスク、CI/CD、シークレット、リリース権限、開発者デバイス、クラウド アクセス、AI ツール、および顧客向けのアーティファクトを結び付けます。
サプライチェーンのインシデントと準備状況のレビューについては、次のことを支援できます。
- リポジトリとビルド システム間の依存関係とパッケージ インベントリ。
- CI/CD GitHub Actions、OIDC、パッケージ公開、クラウド アクセス、署名の権限レビュー。
- 開発者マシン、CI ワーカー、リポジトリ、環境、ログ、アーティファクト ストアにわたる秘密暴露マッピング。
- インストール ウィンドウ、ロックファイル、キャッシュ、コンテナ、リリース アーティファクトに対する悪意のあるパッケージの影響レビュー。
- 認証情報、エディター プラグイン、AI ツール、ローカル エージェント、永続化パスに重点を置いた開発者エンドポイントのレビュー。
- 署名されたアーティファクト、パッケージの出所、証明書のローテーション、および顧客更新ガイダンスのリリース整合性レビュー。
- 修復計画と再テスト。
- レビューされた輪郭の準備ができたら、証拠のパッケージ化とセキュリティ認証を行います。
サプライチェーンに関する質問が企業の営業や投資家の評価に現れるようになったため、この証明書は役に立ちます。購入者は、コードが開発マシンから本番成果物にどのように移動するかをベンダーが証明できるかどうかを知りたいと考えています。
製品チームの対応計画
グラフ内のパッケージが侵害されたことをチームが知った場合は、迅速に行動し、作業の順序を維持してください。
影響を受けるビルドをフリーズします。チームがアーティファクトを確認するまで、影響を受ける依存関係ウィンドウを使用したリリースを一時停止します。
暴露を特定します。パッケージ ロック ファイル、pnpm ロック、yarn ロック、npm キャッシュ、CI ログ、コンテナ レイヤー、アーティファクト リポジトリ、開発者のインストール履歴を検索します。
マシンを隔離します。期間中に悪意のあるパッケージを実行したホストは、エンドポイントのレビューを受ける必要があります。開発者のラップトップと CI ランナーは両方ともカウントされます。
秘密をローテーションします。公開が信頼できる場合は、パッケージ レジストリ トークン、GitHub トークン、クラウド キー、SSH キー、CI シークレット、署名資料から始めて、到達可能な認証情報をローテーションします。
リポジトリを確認します。異常なアクセス、新しいワークフロー、変更されたアクション、変更されたリリース スクリプト、新しいデプロイ キー、新しいメンテナ、および予期しないパッケージの公開を探します。
クリーンな状態から再構築します。依存関係をクリーンアップし、侵害されたバージョンを削除し、アーティファクトを再構築し、必要に応じて出力を比較します。
証拠をもとにコミュニケーションをとる。顧客とパートナーは、影響を受ける製品、影響を受けるバージョン、期間、修復、資格情報のローテーション、および必要なユーザーのアクションなど、冷静な事実を必要としています。
買い手のシグナル
TanStack の事例は、サプライチェーンのセキュリティが製品の信頼性の中心に移ってきていることを示しています。企業は、依存関係、ビルド、シークレット、リリースがどのように管理されているかを説明できない場合、本番環境に違反することなく購入者の信頼を失う可能性があります。
最強のチームは質問される前に答えます。彼らは自分がどのパッケージを使用しているかを知ることができます。どのワークフローが公開できるかを知ることができます。彼らは秘密がどこにあるかを知るでしょう。彼らはAIツールがどのように管理されているかを知ることになるでしょう。彼らは結果を回転させ、再構築し、証明する方法を知っています。
SToFU はその状態を作り出すのに役立ちます。ビルド チェーンを確認します。権限を縮小します。露出を追求します。リリース パスを確認します。輪郭を証明します。
ソフトウェアは高速に動きます。証拠もそれに伴って動かなければなりません。
