はじめに こんにちは、クラウドエースの梶尾です。 Google Cloud の運用設計を進める中で、特定の外部パートナーや運用担当者に、特定の VM インスタンスだけを触らせたいという要件が発生することがあります。 他のインスタンスへの操作は一律で禁止したい、というケースです。 ここで前提として知っておくべき Google Cloud の仕様があります。 実は、コンソール上で特定の VM だけを表示し、他の VM の名前を非表示にするような「画面レベルでの絞り込み」はできません。 プロジェクト内のすべての VM 一覧は、どうしても画面上に見えてしまいます。 しかし、一覧は見せるものの

本ブログは 2026 年 7 月 29 日に公開された AWS Blog「 Amazon identifies North Korean hacker group behind open-source supply chain attacks 」を翻訳したものです。 Amazon は、北朝鮮 (朝鮮民主主義人民共和国、DPRK) に関連する脅威アクターが、世界中の企業がアプリケーション開発に利用する共有ビルディングブロックであるオープンソースソフトウェアライブラリを標的にしている実態について、新たな調査結果を公開します。Amazon Threat Intelligence は、最近発生した複数の人気 Node Package Manager (NPM) ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによるものであることを特定しました。この関連性はこれまで公に報告されていませんでした。また、この分析では、生成 AI が悪意のあるソフトウェアパッケージの姿をどのように変化させているか、そして脅威アクターが AI ベースのコードシステムをどのように探り始めているかについても説明します。この調査結果を公開することで、オープンソースコミュニティやセキュリティチームが、こうした事象をより的確に検知し、対処できるよう支援します。 これらの動きは、XZ Utils バックドア事件から 2 年後に発生しています。この事件は、忍耐強い攻撃者がボランティアのメンテナーの信頼や時間的な制約を悪用することで、重要なオープンソースソフトウェアをどのように侵害できるかを示しました。オープンソースソフトウェアは、オペレーティングシステム、ウェブサーバー、暗号化ライブラリ、そして企業が日常的に利用しているアプリケーションフレームワークなど、インターネットインフラの多くを支えています。攻撃者が広く使われているオープンソースパッケージを侵害すると、そのパッケージに依存するすべての組織が影響を受ける可能性があります。それ以降、Amazon Threat Intelligence は、北朝鮮に関連する脅威アクターやサイバー犯罪グループが大きく関与する形で、ソフトウェアサプライチェーン攻撃の件数と巧妙さが増していることを確認しています。 この記事では、Amazon Threat Intelligence と Amazon Inspector チームが、人気の NPM パッケージを狙った最近の攻撃活動について新たな詳細を共有します。これには、axios、debug、chalk、typo-crypto の各ライブラリの侵害が、同一の北朝鮮に関連する脅威アクターによって行われたという証拠が含まれます。この脅威アクターは、セキュリティコミュニティでは SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されています。また、オープンソースリポジトリを侵害する手法がどのように進化しているか、そしてこうした変化がオープンソースソフトウェアに依存する組織にとってなぜ重要なのか、さらに、お客様がこれらの脅威を検知して対応できるよう、 Amazon Web Services (AWS) がどのような取り組みを行っているかについても説明します。 複数の NPM 侵害の背後にいる単一の北朝鮮関連グループ 2025 年 3 月、北朝鮮に関連する脅威アクターは typo-crypto パッケージを侵害しました。2025 年 9 月には、同じ脅威アクターが debug と chalk の NPM パッケージを侵害しました。2026 年 3 月には、同じ手口が axios パッケージの侵害でも確認されました。axios は、週間ダウンロード数が 1 億回を超える、最も広く使われている JavaScript ライブラリの 1 つです。いずれのケースでも、脅威アクターはパッケージの信頼されたメンテナーに対してソーシャルエンジニアリングを行うことでアクセス権を獲得し、その後、悪意のあるコードを含むソフトウェアアップデートを公開しました。これらのパッケージの最新バージョンを自動的に取得していた組織は、すべて侵害されたアップデートを受け取ったことになります。 axios の侵害については既に公にこの北朝鮮に関連する脅威アクターによるものと特定されていましたが、typo-crypto、debug、chalk の各インシデントについては、これまでこの脅威アクターとの関連が指摘されていませんでした。Amazon Threat Intelligence は、これらのサプライチェーン攻撃活動全体に共通する戦術、技術、手順 (TTP) を特定しました。具体的には、トロイの木馬化された NPM パッケージ、インストール後フック (パッケージのインストール時に自動的に実行されるスクリプト) の利用、そしてコードの再利用です。コマンドアンドコントロール (C2) の痕跡や TTP の分析に基づき、Amazon Threat Intelligence は、これらの攻撃活動が SAPPHIRE SLEET、STARDUST CHOLLIMA、BlueNoroff、CageyChameleon、Alluring Pisces として追跡されている北朝鮮に関連する脅威アクターによるものであると、中程度の確度で評価しています。これらの侵害がこの北朝鮮に関連する脅威アクターと公に結び付けられるのは、今回が初めてです。 Amazon Threat Intelligence は、これを金銭目的の攻撃パターンの一部と評価しています。少数の非常に人気の高いパッケージを侵害することで、このグループは数千もの下流環境に同時にアクセスできる可能性を得ます。金銭目的の脅威アクターにとって、このアプローチは組織を 1 つずつ標的にするよりもはるかに効率的です。 これらのインシデントの累積的な影響は、共有される依存関係を狙うことの効率性を浮き立たせています。Wiz Research の報告によると、debug と chalk のサプライチェーン事件では、わずか 2 時間の間に、クラウド環境の約 10 分の 1 が影響を受けました。 後の攻撃活動の前兆となった小規模な攻撃活動 axios の脅威アクターに関連する痕跡や TTP を定常的に分析していた際、Amazon Threat Intelligence は 2025 年に登録されたドメインとの関連性を発見し、その過去の活動について本格的な調査を行いました。その調査により、同一の北朝鮮に関連する脅威アクターが、2025 年 3 月に typo-crypto の NPM パッケージにトロイの木馬化されたファイルをコミットしていたことが判明しました。この悪意のあるファイル core.js は、typo-crypto リポジトリ内で正規の core-js NPM パッケージになりすましています。 確認されたダウンロード数が限られていることから、Amazon Threat Intelligence は、この攻撃活動が小規模なものであり、2025 年後半から 2026 年にかけて発生した、より大きく注目を集めたサプライチェーン攻撃活動の実験場となった可能性が高いと評価しています。このグループは、公に注目を集めた大規模な攻撃活動よりも 1 年以上前から、サプライチェーンの手法を洗練させていたようです。Amazon Inspector は、より広範なセキュリティコミュニティがこの調査結果を活用できるよう、このマルウェアを Open Source Vulnerabilities (OSV) データベースに報告し、現在は MAL-2026-3400 として追跡されています。 このトロイの木馬化されたファイルは、値 0098273 で始まるハッシュ入力を受け取ると実行されます。トリガーされると、ハードコードされた C2 サーバーから第 2 段階のペイロードをダウンロードし、被害者のオペレーティングシステムに応じて実行します。Windows、macOS、Linux それぞれに合わせた挙動が用意されています。このマルウェアは、ペイロードのローテーションを伴うファイルベースの永続性を実装しており、base64 エンコードされたテキストと 01042025 をキーとする XOR 暗号を組み合わせた多層難読化を使用しています。 関連する侵害の痕跡 (IoC) は以下のとおりです。 ドメイン : npmjs[.]store IP アドレス : 216[.]74[.]123[.]126 NPM パッケージ : typo-crypto (SHA256: 24604384b0e748ada07923630b3d037489e696284a98c4409fb9b6763565571f) トロイの木馬化されたファイル : core.js (SHA256: 2014d09c7ded74d89c885b5f11693865224116f1b25df9330e61fe528f419d73) Amazon Threat Intelligence は、このグループが、その後 axios、debug、chalk に対して行われた、より影響の大きい攻撃活動で使われた手法を、当時実験していたと評価しています。確認されたダウンロード数は少なかったものの、そのトレードクラフト (攻撃者に特徴的な手口や行動様式) は、より人気の高いパッケージへの攻撃で後に確認されたものと一致しています。 攻撃者のトレードクラフトの変化 過去 1 年間、Amazon Threat Intelligence と Amazon Inspector は、脅威アクターがオープンソースライブラリを標的にする際の手法を変化させていることを確認してきました。この変化は重要です。オープンソースパッケージは今なお魅力的な標的であり続けているからです。広く信頼されており、多くの環境で自動的に更新され、新しい貢献者を歓迎するコミュニティによって維持管理されています。以下のパターンは、攻撃者が最新の防御策を回避するために手法を適応させている様子を示しています。いずれの手法も、依存関係が検査される瞬間と、実際に実行される瞬間の間にあるギャップを悪用するように設計されています。1 年前は、悪意のあるパッケージそのものを探すのが主な手法でした。現在では、単体では無害に見えるパッケージ群に分割された、悪意のある挙動を探しています。 パッケージ単位の攻撃から、フラグメント単位の攻撃へ Amazon Inspector は、攻撃者が 1 つの悪意のあるワークフローを、一見ごく普通に見える複数のパッケージに分割するケースが増えていることを確認しています。あるパッケージは、設定ファイルを装った暗号化データを保持します。2 つ目のパッケージは、その復号ロジックを提供します。多くの場合、後から公開される 3 つ目のパッケージが、ペイロードを取得して実行します。 それぞれのパッケージを単独で見ると、無害に見えます。目立つインストールフックもなく、信頼できない入力を評価する明らかな処理もなく、不審に見えるネットワーク呼び出しもありません。悪意のある挙動は、これらのコンポーネントが意図された順序で組み合わせて使われたときにのみ現れます。このアプローチは、実際の依存関係グラフの中でパッケージ同士がどのように相互作用するかを考慮せず、1 つずつパッケージを評価するスキャナーを回避するように設計されています。 信頼の蓄積に投資する、長期にわたる攻撃活動 また、脅威アクターが信頼の蓄積を長期的な視点で捉えている様子も確認しています。明らかに悪意のあるコードを公開してダウンロードを待つのではなく、実際に有用なものを公開し、それを維持管理するのです。こうした攻撃者は、数週間から数か月にわたって、本物のメンテナーのように振る舞います。機能を追加し、バグを修正し、依存するプロジェクトを増やしていきます。 同じ忍耐強さは、人間側の行動にも表れています。場合によっては、目的は新しいパッケージを立ち上げることそのものではなく、既存プロジェクトの貢献者になることです。これは、XZ Utils バックドアから debug、chalk、axios のメンテナー侵害まで一貫して見られる流れです。いずれのケースでも、攻撃者は正当性を、アクセス権が最大になる瞬間に一度だけ使う資産として扱っていました。 パッケージとその挙動の分離 最近の多くのケースでは、公開されているレジストリ上ではパッケージがクリーンに見えても、実際には危険な場合があります。これは、パッケージの実際の挙動が、攻撃者が別の場所で管理しているリソースに依存しているためです。これには、実行時に外部リポジトリから取得される guard や license スクリプト、特定の挙動を制御する設定ファイル、起動時に参照されるリモートエンドポイントなどが含まれます。 これらの外部リソースが無害な状態を保っている限り、コードレビューは通過し、自動スキャンもクリーンな結果を返します。しかし、攻撃者がそのコンテンツを切り替えたり、それまでプレースホルダーを返していたエンドポイントを実際に機能させたりすると、新たなパッケージのリリースを行わなくても、既にインストールされているすべてのコピーが一斉に悪意のあるものになる可能性があります。現時点で悪意のある挙動を示していないパッケージは、設計上安全なパッケージと同じではありません。 基本的な難読化から、本格的な暗号技術へ 以前、攻撃者はミニファイや単層の base64 エンコードといった単純な難読化に依存していましたが、現在ではより強力な暗号技術を使う多段階のペイロードが確認されています。例としては、パスフレーズで保護された AES-GCM 暗号化データ、呼び出しごとに異なるキーを使う RC4 形式の文字列配列、base64 の上に重ねられた XOR 暗号、そして次の段階を暗号化されたフィールドとして保持し、メモリ内でのみ復号するネイティブローダーなどが挙げられます。 これらに共通する設計上の選択は、復号キーがパッケージ自体には決して保存されないという点です。復号キーは実行時のコンテキストから導出されたり、実行時にサーバーから取得されたり、ライセンスキーとして提供されたりします。つまり、ソースへの完全なアクセス権を持つアナリストであっても、静的な方法でペイロードを確実に復号することはできません。第 1 段階は単純な復号器に見えますが、悪意のあるコンテンツは、実際のターゲット上で実際のキーを使って実行されるまで暗号文のままです。 サンドボックスでの実行を回避するペイロード 防御側がクラウドサンドボックスでの自動分析をスケールさせるにつれて、攻撃者は自分たちのコードをより環境認識型にしてきました。ペイロードは、実行に先立って、自分が分析対象になっているかどうかを判断します。実際のパッケージインストールライフサイクルを経た場合にのみ実行されるようにしたり、1 回限りしか使えない環境変数を使ったり、本物の開発環境やビルド環境であることを示すシグナルを確認したりする挙動が確認されています。これには、対話型ターミナル、現実的なユーザー名やホスト名、ドメインへの参加状況、妥当なアップタイム、ローカルのファイル履歴、特定のオペレーティングシステム、そして分析用インフラストラクチャと通常のワークロードを区別するのに役立つクラウドメタデータなどが含まれます。 一部の配信サーバーは、クライアントに応じて提供する内容を変えることもあります。一般的なブラウザらしいリクエストには無害なデコイが返され、実際のペイロードは、マルウェアが使う正確なユーザーエージェントに対してのみ配信されます。その結果、クラウドサンドボックスから「安全」という判定が出たとしても、そのパッケージが本当に安全であることよりも、環境がどれだけ「本物らしく」見えるかを示している場合が多いのです。 生成 AI が攻撃と防御の両方を変えている 生成 AI は、攻撃者が作り出せるものと、防御側が頼れるものの両方を変化させています。攻撃者は今や、大規模に新しいコードやコンテンツを生成できます。これまで、多くの悪意のあるパッケージは、不自然な文章、内容の乏しいドキュメント、明らかなコピー & ペースト、サンプル間で再利用される特徴的な関数など、「見た目がおかしい」ことによって検知されてきました。生成 AI は、こうしたシグナルの多くを消し去ってしまいます。 現在、攻撃者は、説得力のあるドキュメント、妥当性のあるコミット履歴、架空のメンテナーの身元情報を伴う、一貫性があり、自然で、コメントが丁寧に付けられた数千行のコードをバックドアの周りに用意できます。それぞれのバリアントを変異させ、名前を変え、再構成し、再暗号化できるため、一致させるための単一の安定したシグネチャは存在しません。パターンベースの検知は、デプロイごとに一点物のように見えるマルウェアに対して、劣勢に立たされています。 AI はまた、新しい初期アクセスの経路も生み出しています。その 1 つが スロップスクワッティング (slopsquatting) です。これは、AI コーディングアシスタントが幻覚として生成した、実在しないパッケージ名を攻撃者があらかじめ登録しておく手法です。開発者や自律型コーディングエージェントが支援を求め、モデルが自信を持って存在しないパッケージを推奨してしまうと、攻撃者はその名前を事前に登録して待つことができます。その推奨に従った次の人物は、タイプミスをしたわけでも悪意のあるサイトを訪れたわけでもないにもかかわらず、マルウェアを受け取ってしまう可能性があります。実質的に、AI がその悪意のある依存関係を代わりに配信してしまったことになるからです。組織が、人によるレビューを限定的にしか行わずに依存関係をインストールするエージェントへと移行するにつれて、この経路は単なる興味深い事例ではなく、大規模に展開可能な配信チャネルとしての性格を強めていくと考えられます。 最も重要な点として、AI は防御の自動化における前提そのものを変えています。攻撃者はもはや、人間の目を欺くためだけにマルウェアを書いているわけではありません。AI レビューシステムが承認してしまうようなマルウェアを書いているのです。組織がコードのレビューやパッケージのトリアージに AI システムを頼るようになるにつれて、その AI システム自体がアタックサーフェスの一部になります。隠された指示によって AI システムに意図しない行動を取らせる手法である間接プロンプトインジェクションが、AI ベースのコードスキャナーを欺くために悪意のあるパッケージに組み込まれるケースが今後増えていくと予想しています。これらの指示は、ソースコードのコメント、README ファイル、docstring、テストフィクスチャなどに隠され、自動化システムを説得して、悪意のあるコードを安全と判定させたり、特定のファイルをスキップさせたり、分析中に意図しない動作を実行させたりするように作り込まれます。マルウェアが動作するために必要なコンテンツそのものが、それを検査する機械に向けた、もう 1 つの別のメッセージを同時に運んでいる可能性があるのです。 AWS の対応 Amazon Threat Intelligence と Amazon Inspector は、こうしたソフトウェアサプライチェーンリスクの変化する状況にお客様が適応できるよう、投資を続けています。Amazon は、巧妙な脅威アクターによる脅威を積極的に検知・軽減することで、お客様とインターネット全体のセキュリティ保護に貢献することに、引き続き取り組んでいます。Amazon は、Amazon 内の各チーム、業界パートナー、そしてセキュリティコミュニティと連携し、インテリジェンスを共有し、脅威を軽減する取り組みを続けていきます。この攻撃活動を発見した際、Amazon Threat Intelligence は Amazon Inspector と協力し、この悪意のあるパッケージを追跡してその脅威を軽減し、OSV データベースを通じてコミュニティに情報を共有しました。さらに、確認された侵害の痕跡は Amazon GuardDuty にも共有され、お客様にこの活動について警告できるようにしています。 Amazon Inspector は、これらの知見を活用して検知ロジックを改善し、レジストリ全体でのカバレッジを拡大し、この記事で説明したトレードクラフトの変化を反映するシグナルを優先しています。また、パッケージレジストリや Open Source Security Foundation (OpenSSF) といった業界パートナーとも連携し、調査結果を共有しています。 また、Amazon は、オープンソースのメンテナーがプロジェクトをより安全に保護できるようにするための取り組みにも投資しています。2026 年、AWS は Linux Foundation および他の業界のリーダー企業とともに、AI を悪用したサイバー脅威から重要なオープンソースソフトウェアを守るための協力イニシアチブである Akrites の立ち上げに参加しました。AWS はまた、AI を悪用した攻撃からオープンソースエコシステムを守るため、他の組織とともに 1,250 万ドルを共同で投資しています。これらの取り組みは、より大きな理念を反映しています。オープンソースソフトウェアのセキュリティは共有の責任であり、それを守るためには、それに依存する組織による継続的な投資が必要だという理念です。 Amazon の目標は、お客様の環境がオープンソースコンポーネントにどのように依存しているかを理解できるように支援し、不審な挙動を早期に特定し、ソフトウェアサプライチェーンが侵入経路として利用された際に迅速に対応できるようにすることです。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティの利点を「最も抵抗の少ない道」にすることで、Amazon の各事業を支えることを使命としています。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO や、直近では AWS CISO など複数の役職を務めた後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社以前、CJ は連邦捜査局 (FBI) の Cyber Division で、コンピュータおよびネットワーク侵入に関する技術分析を主導していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務した経験があります。CJ は、現在のセキュリティ業界の基盤となっているとされる、複数のコンピュータ侵入捜査を主導してきました。 CJ は、コンピュータサイエンスと刑事司法の学位を保持しており、SRO GT America の GT2 クラスで現役のレースカードライバーとしても活動しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

品質戦略のレイヤーに、QAがいない。 PdMやDevには役割を広げていくキャリアパスが見えている。PdMはプロダクト組織のリーダーへ、Devはアーキテクトやテックリードへ。でも、QAの先は確立されていない。AI時代になって、この空白がさらに際立って来るように感じる。 ソフトウェア開発の現場には、3つの主要ロール、いわゆる3アミーゴがいます。 PdM（プロダクトマネージャー）：「何を作るか」を決める人 Dev（開発者）：「どう作るか」を実現する人 QA（品質保証）：「それで正しいか」を問う人 自分は開発者→QA→事業開発と渡り歩いてきました。コードを書く側、品質を問う側、売上を