「Miasma」キャンペーンが明らかにした、新たなサプライチェーン脅威モデルと開発者認証情報の闇市場の実態

盗まれたセッションクッキーは、攻撃者がnpmソフトウェアレジストリ内の32個のRed Hatパッケージを汚染するためにそれを利用するまで、7週間にわたり闇市場に放置されていました。これは、現代のサプライチェーン攻撃の背後にある組織的な手法の典型例です。

Miasmaワームとnpmサプライチェーン攻撃の背景

6月1日、自己増殖型ワーム「Miasma」が、@redhat-cloud-services ネームスペース下の32の公式npmパッケージを侵害し、毎週8万～11万7千件と推定されるダウンロードに対して、認証情報を収集する不正コードを配信しました。5日間のうちに、この攻撃は3つの異なる攻撃の波を経て激化し、GitHubはMicrosoft傘下の4つの組織にまたがる73のリポジトリを無効化せざるを得なくなりました。

Miasmaのサプライチェーン攻撃に関する技術的な詳細は憂慮すべきものです。悪意のあるパッケージに有効な「ソフトウェアアーティファクトのサプライチェーンレベル（SLSA）」の認証が付与されていたこと、インストールスクリプトのモニタリングを回避する新たな実行手法、そしてAIコーディングアシスタントを標的とした新たな持続性メカニズムなどが挙げられます。 しかし、最も重要な詳細はタイムスタンプです。

ダークウェブモニタリング企業のWhiteintelは、4月13日、情報窃取ツールのログから、Red Hatの従業員のGitHubの認証情報とセッションクッキーを検出しました。5月15日に2件目の目撃情報が報告されました。この認証情報は、約7週間にわたり闇市場に出回っていた後、6月1日に攻撃者によって悪用されました。この7週間のギャップは、Tenableのリサーチの特別調査活動（RSO）チームが「開発者認証情報エコノミー」と呼ぶ新たな脅威モデルの特徴であり、同チームは2026年3月からこの動向を追跡しています。

「開発者認証情報エコノミー」とは、高度な特権を持つ開発者認証情報を対象とした組織化された闇市場であり、オープンソースのサプライチェーンへの侵害が認証情報生成のインフラとして機能し、闇市場が流通層として機能し、それぞれ異なる動機を持つ複数の攻撃者が、収集したアクセス権を後段で悪用するものです。 「Miasma」キャンペーンは、これまでのところこのモデルの最も明確な例であり、2026年を通じてnpm、PyPI、GitHubのエコシステム全体で加速している傾向を裏付けるものです。

三層構造: Miasma を例に解説

Tenable RSOは3月にこのパターンを初めて評価した際、TeamPCPのカスケード型キャンペーン（Trivy、KICS、LiteLLM、Telnyx、および66以上のnpmパッケージ）と、Sapphire Sleet/UNC1069によるAxiosへの侵入を分析の軸としていました。 この分析では、認証情報の生成、配布、および悪用という3層構造を特定しています。3か月後、「Miasma」キャンペーンは、各層を驚くほど明確に立証しています。

層 1: 認証情報の生成

「開発者認証情報エコノミー」の第一層は、搾取です。攻撃者が開発者向けツールやオープンソースのインフラを侵害する主な目的は、エンドユーザーにマルウェアを配布することではなく、GitHubトークン、npm公開トークン、クラウドプロバイダーの認証情報、CI/CDのシークレット、SSHキー、APIキーなど、それらの環境に含まれる認証情報を収集することにあります。

TeamPCPは、2025年9月からオリジナルの「Shai-Hulud」ワームを用いて、これを大規模に展開する先駆者となりました。 その最大の特徴は、「カスケード型認証情報抽出」という手法でした。つまり、信頼されているツールを1つ侵害し、そのツールが保持する認証情報を収集し、その認証情報を使って依存関係チェーン上の次のツールを侵害するというものです。 

Trivyの脆弱性スキャナーが侵害され、CI/CDランナーのシークレット情報が流出しました。 それらの秘密が、KICSへの不正アクセスを可能にしました。KICSから、さらにクラウドの認証情報がもたらされました。チェーンの各リンクが、より広範な特権アクセス権を生み出していました。

5月までに、TeamPCPはこの仕組みを「Mini Shai-Hulud」バリアントへと改良し、生成層の効率を劇的に高める2つの機能を導入した：

1. ワームによる拡散： このマルウェアは、侵害されたアイデンティティが公開できるすべてのパッケージについてnpmレジストリに照会を行い、それらすべてに自動的に自身を再公開します。
    
2. OpenID Connect（OIDC）トークンの抽出によるCI/CDパイプラインの乗っ取り： Mini Shai-Huludは、静的な認証情報を盗むのではなく、GitHub Actionsを通じて有効期限の短いOIDCトークンをリクエストすることで、有効な暗号学的出所情報を備えたパッケージを公開できるようにしています。

「Miasma」サプライチェーン攻撃キャンペーンにおいて、この生成層は、Red Hat の従業員のGitHubアカウントが乗っ取られたことを利用して活動していました。このワームの不正コードは、感染した環境内で以下の項目をスキャンしました。

• GitHub トークンと個人用アクセストークン
• npm パブリッシングトークン
• AWS、GCP、およびAzureのクラウド認証情報
• HashiCorp Vault トークン
• Kubernetes サービスアカウントのトークン
• SSHの秘密鍵
• Dockerレジストリの認証情報
• GPG鍵
• .env ファイル 

6月の亜種では、GCPおよびAzureのクラウドアイデンティティ専用の情報収集機能が追加され、シークレット情報の抽出にとどまらず、感染したマシンが保有するすべてのクラウドアクセス権限を列挙するようになりました。

侵害された @redhat-cloud-services パッケージのバージョンに対してnpm installを実行したすべてのマシンが、認証情報の生成ノードとなってしまいました。

層 2: ディストリビューション

2番目の層はマーケットプレイスです。 盗まれた認証情報は、生成層から闇市場、情報窃取型ログの集約サイト、アクセス仲介サービスへと流れ込み、そこであらゆる購入者が入手できるようになります。

Miasmaによるサプライチェーン攻撃のタイムラインにより、これまでの攻撃キャンペーンでは明らかにならなかったこの層が浮き彫りになっています。 Whiteintelは4月13日、情報窃取ツールのログから、Red Hatの従業員のGitHubの認証情報とセッションクッキーを検出しました。 その認証情報は、Red Hat を標的としたサプライチェーン攻撃によって生成されたものではありません。一般的な情報窃取型マルウェアによって収集されたものであり、SpyCloud の「2025年アイデンティティエクスポージャーレポート」が記録した 1,320 万件の情報窃取型マルウェア感染事例のうちの 1 件です。同レポートによると、これらの感染 1 件あたり平均 50 件の認証情報が生成されていたことが明らかになっています。その認証情報は、数十億ものデータポイントの一つとして、 ディストリビューション層に取り込まれました。SpyCloudは、2025年だけで、犯罪者コミュニティのモニタリングを通じて、53億組の認証情報、1,810万件の漏洩したAPIキーおよびトークン、86億個の盗まれたセッションクッキーを回収しました。

7週間にわたり、その認証情報は、誰かがそれに対して何らかの措置を講じるまで、ディストリビューション層に留まっていました。その滞留時間が、開発者認証情報エコノミーが利用するシステム上の隙間となっています。流出した開発者認証情報を扱う闇市場をモニタリングしていない組織は、「生成から悪用化に至るパイプラインが存在しない」か、あるいは「そのパイプラインの動きが遅いため問題にならない」という前提で運営しています。『Miasma』は、闇市場の基準からすれば長い方である7週間という期間でさえ、武器化には十分すぎるほどであることを示しています。

5月12日、TeamPCPが「Shai-Hulud: Open Sourcing The Carnage」というメッセージとともに、Mini Shai-Huludの完全なソースコードをMITライセンスの下でGitHubに公開したことで、その普及はさらに拡大しました。このリリースには、CIキャッシュポイズニング用スクリプト、OIDCトークン抽出ツール、および拡散ロジックを備えた認証情報窃取ツールが含まれていました。これは、サプライチェーンにおいて、実用的なエクスプロイト・フレームワークを公開することに相当します。ツール自体が拡散経路となり、構造的に同一の攻撃キャンペーンを実行したいと考えるあらゆる攻撃者にとって、参入障壁が低くなったのです。

層 3: 武器化

第3の層は運用上の利用です。 それぞれ異なる動機を持つ攻撃者は、ディストリビューション層から認証情報を取得し、特定の標的に対してそれを武器として利用します。

3 月、RSO チームは、同じ認証情報の集まりを利用して活動する少なくとも 3 つの異なる攻撃者を確認しました。TeamPCP は認証情報を大規模に収集し、Sapphire Sleet/UNC1069 (北朝鮮系) は Axios への侵入で盗んだ npm トークンを悪用して金銭的利益を得ました。また、LAPSUS$ は LiteLLM の侵害で流出した Tailscale VPN の認証情報を使い、Mercor AI からデータを盗み出しました。これらはいずれも、同じ認証情報の基盤に依存していました。

Miasmaの武器化の段階は進化を続けていますが、その3つの波にわたる推移からは、次のようなパターンが浮かび上がってきます：

• 第1波（6月1日）では、盗まれたRed Hatの認証情報を利用して32個の@redhat-cloud-servicesパッケージを侵害し、侵害されたバージョンがインストールされたすべての開発環境から新たな認証情報を生成しました。
   
• 第2波（6月3日）では、リサーチエンジニアらが「Phantom Gyp」と呼ぶ新たな手法を用いて、さらに57個のパッケージを標的とした。この手法は、157バイトの「binding.gyp」ファイルを悪用し、npm installの実行中にコード実行を引き起こすもので、以前の波を受けて防御側が導入していたpreinstall-scriptのモニタリングを迂回するものでした。
  
• 第3波（6月5日）では、5月19日のPyPI攻撃の際にも使用された、以前に侵害されていたコントリビューターアカウントを利用して、MicrosoftのAzure/durabletaskリポジトリに悪意のあるコミットをプッシュし、GitHubは105秒間の自動スキャンにより73のリポジトリを無効化せざるを得なくな。

それぞれの波が次の波を生み出し、次々と続いていきました。第1波で盗まれた認証情報により、第2波の標的へのアクセスが可能となり、侵害された同じアカウントが第3波でも悪用され続けました。このワームの自己増殖行動により、感染が成功するたびに認証情報プールが拡大し、生成と悪用が相互に作用し合う複合的なサイクルが形成されています。

すべてのセキュリティチームが懸念すべき事態の深刻化

「Miasma」キャンペーンには、セキュリティ関係者がこれまでのサプライチェーン攻撃で観察してきたものをはるかに上回る、3つの点における本格的なエスカレーションが見られます。

1. ソフトウェアの来歴証明だけでは、もはや不十分

MiasmaのWave 1パッケージには、ソフトウェアサプライチェーンの完全性検証において最高レベルにあたる、有効なSLSAビルドレベル3の認証が付与されていました。 Red Hatの正規のCI/CDパイプラインは、攻撃者がパイプラインに注入したGitHub Actionsのワークフローを通じて、Red Hatの信頼できるOIDC (OpenID Connect)アイデンティティを使用してパッケージをビルドしました。 その暗号証明書は正当なものでした。そのパッケージは、実際にそのパイプラインによってビルドされました。 その時点で、たまたまそのパイプラインにマルウェアが含まれていたのです。

これは、来歴検証の迂回ではありません。これは、来歴検証が、防御側が想定しているものとは異なる疑問に答えを与えることを示しています。署名付き認証は、特定のパイプラインがパッケージをビルドしたことを証明するものです。 それは、パイプラインが汚染されていなかったことを証明するものではありません。サプライチェーン管理の主たる手段として来歴検証に依存している組織は、Miasmaを単発の不具合ではなく、構造的な制約として捉えるべきです。

2. AIコーディングエージェントは、今やアタックサーフェスとなっている

「Phantom Gyp」攻撃（6月3日）および「Azure」攻撃（6月5日）では、これまでのサプライチェーン攻撃では報告されていなかった持続化メカニズムが導入されました。それは、マルウェアがAIコーディングアシスタントのプロジェクトディレクトリに設定ファイルを配置するというもので、具体的にはClaude Code用の.claude/settings.json、Cursor用の.cursor/rules、そしてGemini CLIやVS Code用の設定ファイルがこれに該当します。これらは、トロイの木馬化された拡張機能や、悪用されたプラグインではありません。 これらは、開発者が次にプロジェクトを開いた際に、AIアシスタントの動作を黙って変更する、命令層のオーバーライドです。

開発者がAI支援型IDEで感染したプロジェクトを開くと、バックドアが実行されます。こうして、攻撃者が隠した指示がAI生成コードに影響を及ぼし、正当な提案と見分けがつきにくい微妙な脆弱性が生じる可能性があります。 これは、パッケージレジストリやCI/CDパイプラインから、開発者のローカル環境やAIを活用したワークフローに至るまで、アタックサーフェスが大幅に拡大したことを意味します。 この攻撃には「npm install」は不要で、開発者がリポジトリを開いた際に発動します。

これは、AIを活用した開発ワークフローを、持続化および拡散の基盤として体系的に標的とした、初めて確認されたサプライチェーン攻撃キャンペーンです。AIコーディングアシスタントが企業の開発環境において標準的なツールとなるにつれ、この攻撃手法は模倣され、さらに洗練されていく可能性が高いです。

3. オープンソース化されたツールによって、模倣犯（コピーキャット）が横行するエコシステムが形成されている

Mini Shai-Hulud は、もはやTeamPCP限定ではなくなりました。5月12日に、実戦用のツールチェーン全体が一般公開されたことで、どの攻撃者でも、新しい標的となるエコシステムに対して、構造的に同一の攻撃キャンペーンを再現できるようになりました。 「Miasma」の不正コードはオープンソースのコードを基にしており、Duneの世界観に関連する要素をギリシャ神話のテーマ（「Miasma」、「spartan」、「nemean-hydra」）に置き換えるといった外観上の変更が加えられています。これがTeamPCPが新たなブランド名で活動しているのか、それとも公開されたコードを研究して改良を加えた別のグループによるものなのかは不明です。 明らかなのは、その含意です。 npm を利用したサプライチェーン攻撃を実行するための障壁は、大幅に、かつ恒久的に低くなりました。

証拠によると、こうした拡大はすでに進行しているようです。 Palo Alto NetworksのUnit 42は、Shai-Huludツールチェーンを用いた模倣活動「copycat activity」が、今後の犯行主体の特定を困難にしていること、また「Phantom Gyp」の波の進化 （binding.gypの実行、AIエージェントを標的とした攻撃、改変された情報流出経路）は、TeamPCPによる継続的な活動、あるいは公開されているインフラを活用する有能なオペレーターによる活動のいずれとも一致しています。

EDRや事後検出ではなぜこの問題を解決できないのか

サプライチェーン防御をめぐる議論は、実行層での検出に大きく依存してきました。つまり、エンドポイント検知・対応（EDR）ツールが不正コードの実行時にそれを検出し、組織を保護するという考え方です。「Miasma」キャンペーンは、この前提に構造的な欠陥がある理由を明らかにしています。

EDRは、サイバーエクスポージャーではなく、実行状況をモニタリングします。 サプライチェーン攻撃対策としてEDRだけに頼るのは、台所にガソリンを置いたまま煙探知機に頼るようなものです。 EDRでは、設定ミスのあるGitHub Actionや、過剰な特権を持つnpmトークン、あるいは闇市場に7週間も放置されている盗まれた認証情報などを検知することはできません。EDRエージェントが悪意のある不正コードに対して対応を開始する頃には、次の攻撃の波を可能にする認証情報の窃取はすでに発生しています。

監視対象外の隙（カバレッジのギャップ）こそが、窃取が発生する場所なのです。EDRは、Miasmaによる認証情報の収集が実際に実行される一時的なCI/CDランナーやビルド環境について、まったく可視化できていません。 これらの環境は、人間のアナリストがアラートの優先順位付けを行う前に、起動し、改ざんされたnpm installを実行し、機密情報を外部へ流出させ、そして破棄されます。「開発者認証情報エコノミー」においては、エージェントが存在しない場所で盗難が発生します。

検出回避の進化が、検出の進化を上回っています。5月のTanStackへの侵入事件を受けて、防御側は検出対策として、インストール前スクリプトのモニタリングを導入しました。そのわずか3週間後に到来した「Phantom Gyp」攻撃は、実行を「binding.gyp」というファイルに移すことで、その制御を完全に回避しました。このファイルは、ほとんどのセキュリティツールが監視対象としていないものです。 その後、Azure waveはパッケージのインストールを完全に廃止し、IDEやエディタの起動時に実行されるリポジトリレベルの設定ファイルへと移行しました。 防御反応が行われるたびに新たな回避目標が生まれ、その反復サイクルは数ヶ月単位ではなく、数日単位で測定されます。EDRの回避は、能動的かつ組織化された手法であり、サプライチェーン攻撃を行う者たちも同様の適応的な行動を見せています。

EDRには一定の役割がありますが、それは「病気」（開発者の認証情報やCI/CDインフラの管理不備によるサイバーエクスポージャー）そのものではなく、「症状」（実行時のマルウェアの不正コード）に対処するに過ぎません。「開発者認証情報エコノミー」によって生じるシステミックリスクを無力化するには、根本的に異なるアプローチが必要です。すなわち、攻撃者が悪用する前に、サイバーエクスポージャーの状態を特定し、排除することです。

全体として対策は進んでいるが、根本的な問題は依然として残っている

npmのエコシステムも決して手をこまねいていたわけではありません。npmは5月19日にプラットフォーム全体でのトークン無効化を実施し、すべてのメンテナンス担当者に再認証を義務付けました。また、npm CLIバージョン11.15.0では、人間による2段階認証（2FA）の承認プロセスを伴う段階的公開機能が導入され、パッケージのバージョンが公開される前に、必ず人間による確認手順を経ることが求められるようになりました。GitHubは、Shai-Huludキャンペーンの過程で、約3,800件の社内リポジトリが外部へ流出していたことを明らかにしました。npmの創設者であるアイザック・シュルーター氏は、MFA（多要素認証）なしでの公開を強制的に無効化するよう求めました。

これらの対応は有意義ではあるものの、構造的には事後対応的なものです。つまり、それぞれの対応は前の攻撃の波で観察された手法に対処するものですが、その間に攻撃者はすでに次の段階へと移ってしまっているのです。 段階的な公開により、Wave 1で発生したOIDCトークンの不正利用に対処します。 Wave 2におけるPhantom Gypのbinding.gypの実行については扱っていません。 いずれも、Wave 3におけるAIコーディングエージェントの持続化については対処していません。

今後進むべき道は、事後対応型の検出から先制的なエクスポージャー管理へと移行することです。つまり、攻撃者が認証情報を悪用する前に、その生成源を特定し、封じ込めることです。

「認証情報経済」を打破するための段階的なアプローチ

「開発者認証情報エコノミー」は、ある単純な原理に基づいて機能しています。すなわち、防御側が漏洩していることを認識していない認証情報は、更新されることがなく、その結果、脆弱性を持ったまま残ってしまうのです。 段階的なCTEMアプローチにより、各層で攻撃の連鎖を断ち切ることができます。

フェーズ 1: 生成層を強化する

最優先すべきは、認証情報の盗難を可能にする要因を取り除くことです。 組織は、インストール後およびインストール前の攻撃経路を排除するため、直ちにロックファイルの監査を実施し、ライフサイクルフックを無効化（--ignore-scripts）する必要があります。 しかし、Miasmaの「Phantom Gyp」攻撃が示すように、ライフサイクルフックはもはや唯一の実行面ではありません。パッケージの取り込み制御にbinding.gypのモニタリング機能を追加し、クローンされたすべてのリポジトリを監査して、AIコーディングエージェントの持続性ファイル（.claude/settings.json、.cursor/rules、.gemini/ 設定ファイル）を確認する必要があります。

セキュリティツールそのものを、重要インフラとして扱う必要があります。2026年に起きた出来事は、このことを繰り返し証明しています。Trivy、Checkmarx KICS、そしてNx Console VS Code 拡張機能は、開発者から信頼されているからこそ、いずれも非常に価値の高いエントリポイントとして機能しました。本番システムに適用されているのと同じ完全性検証および隔離制御設定を、セキュリティツールにも適用します。

フェーズ 2: 収集した機密情報をリアルタイムで無力化する

Miasmaの攻撃タイムラインにおける7週間の認証情報保持期間は、「開発者認証情報エコノミー」が依存する攻撃の好機となる期間です。このリスクを解消するには、定期的なローテーションにとどまらず、アンダーグラウンド市場やCI/CDランナー、EDRが展開されていない一時的なビルド段階など、認証情報がどこでさらされているかを継続的に把握する必要があります。

開発者アカウント（GitHub、npm、PyPI、Docker Hub）について、ダークウェブ上の認証情報を継続的にモニタリングし、検出時に自動的にローテーションを実行する仕組みを導入します。個人アクセストークンの有効期間を短縮し、多要素認証（MFA）を必須とします。 「Tenable クラウドおよび AI セキュリティリスクレポート 2026」によると、クラウド環境の 65% に、「ゴースト」認証情報、休眠中のサービスアカウント、および更新されていない鍵が存在しており、これらは攻撃者にとって格好の侵入経路となっていることが明らかになりました。 すべてのゴースト認証情報は、ディストリビューション層で活動する攻撃者にとっての「フリーパス」となります。 Tenable Oneを使用して、実行層での検出ではカバーできない CI/CD パイプラインやクラウドネイティブなビルド段階を含め、アタックサーフェス全体を可視化します。

フェーズ 3: 人による承認を必須とし、自動化の連鎖を断ち切る

このワームの自己拡散は、完全に自動化された公開プロセスに依存しています。トークンを盗み、公開可能なパッケージを列挙し、マルウェアを仕込んで再公開し、これを繰り返すという仕組みです。 人による確認という必須の手順を挿入すると、その自動化の連鎖が途切れてしまいます。

npmのステージドパブリッシング機能（npm CLI 11.15.0）は、このゲートウェイの具体的な実装であり、パッケージのバージョンが公開される前に、人間による2段階認証（2FA）による承認を必要とします。 組織は以下のことを行う必要があります。 

• 段階的な公開、あるいはそれに相当する人間によるチェックを伴うワークフローを直ちに導入する
• GitHub Actions の OIDC トークンのスコープ設定を確認し、id-token が確実に取得されるようにする。「Write」は、保護されたブランチ上のリリースワークフローにのみ制限する
• minimumReleaseAge制御を実装し、新しいパッケージバージョンが利用される前に隔離する
• Miasma指標の検出ルールを設定する：「Miasma:」という説明文が付いた GitHub リポジトリ： 「The Spreading Blight」；GCPのユーザーエージェント文字列「google-api-nodejs-client/7.0.0」；およびデッドドロップ用のGitHubアカウント「liuende501」
• 組織アカウントにおいて、npmのパブリッシュイベントの異常や、GitHubリポジトリの不正な作成がないかモニタリングする

これらは、任意のセキュリティ強化策ではありません。 これらは、実際に確認されている（出回っている）脅威機能に対する直接的な対応策であり、現在ではあらゆる運用者がデプロイできるオープンソースのツールとして利用可能となっています。

今後どうなるのか

「開発者認証情報エコノミー」は、サイバー犯罪の成熟度が著しく高まったことを示しており、単なる機会主義的な攻撃の域を超え、洗練され、スケーラビリティがあり、高度に専門化された市場が確立されています。3 月から 6 月にかけての一連の出来事は、この見解を非常に明確に裏付けています。具体的には、TeamPCP による Shai-Hulud ワームのオープンソース化、Miasma のような模倣型亜種の拡散、npm から PyPI や GitHub Actions、VS Code 拡張機能にまで広がる横断的な拡散、さらにAI コーディングエージェントが新たな攻撃対象として組み込まれたことなどが挙げられます。

この進化により、私たち自身の開発ツールが逆手に取られ、大規模な侵害に必要なアクセス権が収集されてしまうのです。 

今後の道筋は、攻撃者が認証情報を悪用する前に、その生成源を特定し、封じ込める「サイバーエクスポージャー・インテリジェンス」への根本的な転換です。 この変化を乗り切れる組織とは、開発環境を単なるワークステーションではなく、コントロールプレーンインフラストラクチャとして捉え、CTEMフレームワークが提供する継続的な可視性と予防的なセキュリティ強化を通じてそれらを管理する組織です。

Miasma における 7 週間にわたる認証情報の動きは、最悪のケースではありません。これはあくまで基準にすぎず、次の攻撃はすでに同じオープンソースツールを使って準備が進んでいます。

もっと詳しく

• Mini Shai-Hulud: TeamPCPサプライチェーン・キャンペーンに関するよくある質問
• 開発者認証情報エコノミー: エクスポージャーデータがサプライチェーン攻撃における新たな最前線
• Tenable Hexa AI で Axios サプライチェーンの脅威を粉砕: 自律型 AI のユースケース
• 北朝鮮と関連のある攻撃者「UNC1069」によるAxiosのnpmサプライチェーン攻撃に関するよくある質問
• ダウンロード数の水増し: サプライチェーン攻撃を狙う新たな npm 欺瞞手法

最新のサイバー脅威に関する詳しい議論については、Tenable Connect 上の Tenable Research Special Operations（RSO）チームをご覧ください。

現代のアタックサーフェスに対応するエクスポージャー管理プラットフォーム、Tenable One の詳細をご覧ください。