Harness（ハーネス）は、2026年8月4日に自己増殖型のnpmワームがkeyvとcacheableのエコシステム内のパッケージから複数の無関係な組織が管理するパッケージへと移動し、正規の公開ワークフローを通じて急速に拡大したと報告した。Harnessが引用した公開分析によると、SafeDepは444のパッケージ名にわたる2,234の汚染バージョンを確認し、ワームが4時間以内に12の組織に到達したことを確認した。影響を受けた4つの主要パッケージ（keyv、flat-cache、file-entry-cache、cacheable-request）は、合計で月間約18億8000万回ダウンロードされていることが指摘された。
Harnessによると、悪意のあるリリースは、インストール中に実行されるnpmのプリインストールフックを追加し、開発者のマシンやCI/CD環境から認証情報を収集するものだった。ペイロードは、GitHub、npm、クラウド、HashiCorp Vault、Kubernetes、データベース、その他の機密情報を検索し、GitHub Actionsランナーのメモリーを検査し、盗まれたnpm公開アクセスを利用してさらにパッケージを変更および再公開したという。研究者らは、VS CodeとClaude Codeのプロジェクト構成に関連する追加の永続化ベクトルを指摘しており、これらのツールで開かれたリポジトリーが、標準的なパッケージインストールとは無関係に悪意のあるアクションを引き起こす可能性があるとしている。
Harnessは、直感に反する対策の詳細を指摘した。マルウェアは、盗まれたGitHubトークンが機能しなくなった場合に、攻撃者が制御するコマンドを実行できる監視機能をインストールしていた。そのため、対応者は、攻撃者による自動復旧を防ぐため、認証情報の失効やローテーションを行う前に、こうした永続化メカニズムを特定して削除するよう促された。
このインシデントは、出所情報とソースの信頼性という重要な違いを浮き彫りにしたと報じられた。複数の悪意のあるパッケージが有効なSLSA認証を取得していたのは、GitHub Actionsとnpm OpenID Connectの承認済み公開ワークフローによって、侵害されたアーティファクトがビルドされ公開されたためだと報告されている。アナリストは、出所情報はアーティファクトがどのように、どのシステムによって生成されたかを検証できるものの、そのビルドに使用されたソースがレビューまたは検証済みであることを証明するものではないと強調した。
セキュリティー責任者は、変更履歴だけでは、変更がレビューされ承認されたかどうか、リリースが想定されるコミット、プルリクエスト、またはタグに対応しているかどうか、ワークフローファイルやエディター構成が変更されたかどうか、依存関係でインストール時スクリプトの実行が許可されるべきかどうか、ビルド環境がアクセスできるIDやシークレットは何かを確認できないと警告された。ビジネスへの影響は広範囲に及ぶ可能性があると指摘された。開発者や実行者から取得した認証情報によって、ソースリポジトリー、レジストリー、クラウド環境、クラスター、シークレットストア、および下流のリリースワークフローへのアクセスが許可され、依存関係の侵害がIDとリリースの整合性の危機に発展する可能性がある。
同様のリスクを軽減するため、Harnessは、出所をより広範な証拠チェーン内の入力の一つとして扱い、階層的な制御を採用することを推奨した。推奨される対策には、ブランチを保護することでソースコードとワークフローの変更を管理すること、リリース関連コードには独立したレビューを要求すること、パッケージマニフェスト、ライフサイクルスクリプト、CIワークフロー、エディタータスク、AIエージェント構成に精査を追加することなどが含まれる。チームは、公開された成果物をソースイベントと関連付け（承認されたコミット、プルリクエスト、タグ、ワークフローバージョン、ビルドIDを検証）、予期しないパッチリリースや対応するソース活動のない成果物を調査するよう促された。
追加の緩和策として、不要な場合はCIでnpmライフサイクルスクリプトを無効にすること、必要なスクリプトの実行を分離して監視すること、既知の動作のみを明示的に許可すること、必要なタスクに狭くスコープされた一時的で最小限の権限の認証情報を使うこと、使い捨てのビルド環境、最小限のインメモリー認証情報、制限されたアウトバウンド接続、および疑わしい暴露後にランナーを再構築することによってランナーを分離することが推奨された。公開およびプロモーションポリシーでは、ソースレビューステータス、依存関係のリスク、疑わしい新しいスクリプト、スキャナーの検出結果、リポジトリーと公開されたアーティファクトの関係を考慮して、署名の有効性だけでなく、より多くのものを評価することが推奨された。ChainDropインシデントに関しては、組織はトークン監視の永続性、エディターフック、侵害のパッケージの指標、および予期しないリリースを探し出し、影響を受けたシステムと下流の成果物を再構築する前に、既知のクリーンな環境からクレデンシャル情報の失効とローテーションを実行するように強く求められた。
Harnessは、これらの制御をサポートすることを目的とした機能の概要を示しました。これには、ソフトウェアサプライチェーンの姿勢を評価するツール、ソフトウェア部品表によるオープンソースの依存関係の管理、SLSA認証と並行したアーティファクトのプロモーションの管理などが含まれる。より広範なプラットフォームは、Open Policy Agentを介して組織のポリシーを強制し、配信パイプラインにセキュリティーゲートを挿入し、きめ細かなアクセス制御を適用し、監査証跡を保持できると説明された。一方、アーティファクトレジストリーはコンポーネントを一元化し、品質とセキュリティーの標準を強制できる。ChainDropのようなインシデントに適用した場合、これらの機能は、許可された依存関係とバージョンを管理し、パッケージの最小経過期間ポリシーを強制し、成果物の公開またはプロモーション前にセキュリティーとポリシーのチェックを要求し、認証を承認された配信プロセスと関連付け、自動強制によって問題のあるパッケージを制限し、侵害されたコンポーネントが使用されている場所を特定し、調査と修復のために監査証拠を保持するのに役立つと提案された。
Harnessは、これらの措置によって出所証明が完璧になるわけではないが、周囲の安全対策を強化し、リスクを軽減し、透明性を向上させ、信頼性シグナルが矛盾した場合の是正を加速させるだろうと述べた。この報告は、2026年8月5日午前10時19分（米中部標準時）時点で入手可能な公開情報に基づいている。
出典：Harness
この製品の詳細については、Harness製品ページをご覧ください。
