はじめに

こんばんは、mirukyです。
昨今、すっごく色々なところで「サプライチェーン攻撃」という言葉を聞きますよね。
念のため断っておくと、ここで言うサプライチェーンは製造業等の部品供給プロセスではなく、「ソフトウェアの依存関係や配布経路」のことです。npmやDocker、GitHub Actions、VS Code拡張など、私たち開発者が毎日使っているものが、そのまま「サプライチェーン」です。
（前者の方のサプライチェーン攻撃もIPAの情報セキュリティ10大脅威で常連なので、ちょっとややこしいですよね。）

そして2026年4月下旬、開発者向けツールを狙ったサプライチェーン攻撃が数日で連続しました。Checkmarx KICSのDockerイメージ、GitHub Action、VS Code/Open VSX拡張、Bitwarden CLIのnpm配布経路、Open VSXのGlassWorm系スリーパー拡張などです。Bitwarden CLI周辺では「Shai-Hulud: The Third Coming」という文字列も確認され、続報を追ううえで重要なキーワードになっています。

今回の怖さは、単に「怪しいライブラリを入れたら危ない」という話ではない点にあります。開発者の端末、CI/CD、依存更新bot、エディタ拡張、セキュリティスキャナが、まとめて攻撃面になっています。

以前、GitHubとnpmで脆弱なパッケージを入れないための設定は別記事で整理しました。

今回はそこから一歩進めて、 攻撃者がどこから入り、どの秘密情報を盗み、どう横展開するのか を見ます。最終的に、今日からできる防御設定までコンパクトにまとめます。
個人的にかなり気になっていたのもあり、今回の記事では結構詳細にまとめました。

この記事は2026年4月26日時点の公開情報をもとにしています。Checkmarx関連の調査は継続中のため、影響範囲や時刻は公式インシデントページで更新される可能性があります。

目次

何が起きたか
本質は開発者環境の秘密情報
攻撃連鎖の見方
今日やる確認
GitHub Actionsの守り方
VS CodeとOpen VSX拡張の守り方
Dockerと依存更新botの守り方
もし踏んだ場合の対応
続報の追い方

1. 何が起きたか

まず、直近の事案を「どこで実行されたか」で見ると理解しやすいです。

同一犯と断定するための表ではありません。一部の分析ではTeamPCP、TeamPCP系、または同じマルウェア生態系として追跡されていますが、公式にすべてが同一主体と確定したわけではありません。重要なのは、 攻撃経路がパッケージマネージャだけに閉じていない ことです。

（Google翻訳してます）

Dockerの報告では、KICSのケースで攻撃者は有効なCheckmarxの公開者資格情報を使い、正規の公開フローから悪性イメージをpushしました。Dockerのインフラ自体が侵害されたわけではない、という整理です。悪性化したKICSはスキャン出力を収集し、audit.checkmarx[.]cxへ送信していたとDockerは説明しています。User-AgentはKICS-Telemetry/2.0です。

Checkmarx公式は、影響対象としてKICS Dockerイメージ、ast-github-action、Microsoft MarketplaceとOpen VSX上のCheckmarx VS Code拡張、Developer Assist拡張を挙げています。Dockerイメージの悪性タグは重複を除くと、latest、v2.1.20、v2.1.21、alpine、debian、v2.1.20-debian、v2.1.21-debianの7種類です。特にDockerイメージはlatestだけでなく、一見固定に見えるタグも問題になったため、 タグ名だけを見ても安全とは言えない 事例になりました。

2. 本質は開発者環境の秘密情報

今回の本質は、脆弱なライブラリそのものではなく、開発者環境とCI/CDが秘密情報の金庫になっていることです。

攻撃者が欲しいのは、最初に侵入したツールの中身だけではありません。そのツールが動く場所に置かれた認証情報です。

秘密情報	盗まれた場合に起きること
GitHubトークン、PAT、`gh`認証情報	リポジトリ作成、workflow改変、Actions実行、ソース閲覧
npmトークン、`.npmrc`	悪性バージョンの公開、依存先への横展開
AWS、Azure、GCPの認証情報	クラウドリソースの読み書き、永続化、コスト被害
SSH鍵、`.git-credentials`	サーバーやGitリポジトリへの侵入
`.env`、CI/CD Secrets	アプリ本番環境や外部APIの乗っ取り
Claude、MCP、AIコーディングツールの設定	エージェント経由の情報収集や操作誘導

セキュリティスキャナやIaCツールは、Terraform、CloudFormation、Kubernetesマニフェストを読むため、クラウド構成や内部トポロジーに近い場所で動きます。Bitwarden CLIのような開発者向けCLIも、端末上のシークレットに近い場所で動きます。VS CodeやOpen VSX拡張は、ソースコード、ターミナル、環境変数、設定ファイルに近い場所で動きます。

つまり、攻撃者から見ると「どのツールを侵害したか」よりも、 そのツールがどの権限と秘密情報に触れたか が重要です。

3. 攻撃連鎖の見方

今回の事案は、次の流れで見ると整理できます。

攻撃の入口は違っても、連鎖の形は似ています。

【入口は信頼済みの開発ツール】
Dockerイメージ、GitHub Action、npmパッケージ、VS Code/Open VSX拡張は、どれも日常的に使うものです。悪性ファイルを直接ダウンロードして実行するより、正規の開発フローに紛れ込ませるほうが成功率は高くなります。

【実行場所は秘密情報の近く】
CI/CD runner、開発者端末、依存更新botは、ビルドやデプロイに必要な権限を持ちがちです。ここで動く悪性コードは、ソースだけでなく環境変数、トークン、設定ファイル、キャッシュにアクセスできます。

【盗んだ権限で次の供給元になる】
GitHubトークンが盗まれると、workflowの追加やartifact経由の持ち出しが可能になります。npmトークンが盗まれると、別パッケージに悪性リリースを出せます。これがサプライチェーン攻撃の「連鎖」です。

4. 今日やる確認

まずは、次の観点で棚卸しします。時間がない場合は、最初にこの3つだけ確認します。

npm ls -g @bitwarden/cliで影響版の有無を見る
.github/workflowsに見覚えのない変更がないか見る
DependabotやRenovateが影響時間帯に強い権限でCIを動かしていないか見る

そのうえで、広域点検に進みます。

Bitwarden CLIについては、影響版を入れた可能性がある場合、公式案内どおり削除、キャッシュ削除、Secretsローテーションを進めます。

# グローバルに入っているBitwarden CLIのバージョンを確認する
npm ls -g @bitwarden/cli

# クリーンアップ中はnpmのインストール時スクリプトを無効化する
npm config set ignore-scripts true

# 影響版を入れた可能性がある場合は削除する
npm uninstall -g @bitwarden/cli
npm cache clean --force

# クリーンアップ後はチームのポリシーに合わせて元の設定へ戻す
# npm config delete ignore-scripts

Checkmarx関連では、公式がcheckmarx.cxとaudit.checkmarx.cxに対応するIPのブロック、pinned SHAの利用、IDE拡張の自動更新設定の見直し、疑わしい場合の資格情報ローテーションを推奨しています。

「不審な通信ログが見つからないから安全」とは限りません。端末、runner、プロキシ、DNS、EDRのどこで観測できるかは環境差があります。影響時間帯に該当ツールを実行していた場合は、到達可能だった秘密情報を基準にローテーション範囲を決めます。

5. GitHub Actionsの守り方

GitHub Actionsは、今回のような攻撃で横展開の通路になりやすい場所です。まず直すべき設定は、かなりはっきりしています。

5-1. `GITHUB_TOKEN`を最小権限にする

リポジトリやOrganizationのデフォルトを読み取り中心にし、必要なjobだけ個別に権限を増やします。

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-length-commit-sha>

id-token: writeは、OIDCでクラウドやnpm trusted publishingへ認証するときに使います。常時付けるものではありません。

5-2. ActionsはSHAで固定する

GitHub公式は、サードパーティActionsをfull-length commit SHAに固定することを推奨しています。タグは便利ですが、移動や削除が可能です。侵害時には、同じv1やv2を参照していても、昨日と今日で実行される中身が変わる可能性があります。

重要なworkflowほど、タグではなくSHA固定に寄せます。特に次のActionsは優先度が高いです。

優先度	対象
高	release、publish、deploy、署名、SBOM生成、IaCスキャン
中	dependency review、lint、test、code scanning
低	コメント投稿、ラベル付けなどSecretsに触れない補助処理

5-3. workflow変更にCODEOWNERSを置く

.github/workflowsの変更は、コード変更より危険な場合があります。workflowはSecretsとrunnerを直接動かせるためです。

.github/workflows/ @your-org/security-team

レビュー必須のbranch protectionと組み合わせると、不審なworkflow追加を止めやすくなります。

5-4. 長期SecretsをOIDCへ寄せる

AWS、Azure、GCP、npm publish用の長期トークンは、盗まれた後の有効期間が長くなります。GitHub ActionsではOIDCを使い、短命でスコープされた認証に寄せます。

npmについては、Trusted publishingを使うと、GitHub Actions、GitLab CI/CD、CircleCIからOIDCで公開できます。npm公式も、利用できる場合は長期トークンよりTrusted publishingを優先するよう説明しています。

Bitwarden CLIでは、公式はnpm配布経路での短時間配布を説明し、技術分析ではCI/CD内のGitHub Action悪用が指摘されています。つまり、Trusted publishingを使う場合でも、公開workflowそのものが信頼境界になります。

Trusted publishingは、長期npmトークンを置かないための強い対策です。ただし、許可されたpublish workflow自体が書き換えられたり、正規のCI経路で悪性artifactをpublishされたりすると、それだけでは止められません。Bitwarden CLIの事案は、Trusted publishingを使う場合でも、workflow変更のレビュー、branch protection、tag protection、Environmentの承認を組み合わせる必要があることを示しています。

name: Publish Package

on:
  push:
    tags:
      - 'v*'

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-length-commit-sha>
      - uses: actions/setup-node@<full-length-commit-sha>
        with:
          node-version: '24'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm publish

さらに強くするなら、npm側でTrusted publisherを設定した後、従来のpublishトークンを無効化し、Publishing accessでトークン利用を制限します。

6. VS CodeとOpen VSX拡張の守り方

Open VSXのGlassWorm系キャンペーンで重要なのは、拡張機能が「最初は無害に見えて、後から更新で悪性化する」点です。

VS Code、Cursor、Windsurf、VSCodiumなど、拡張エコシステムを使うエディタは、同じ発想で点検します。

見るポイント	理由
公開者名と公式サイト	人気拡張のなりすましを見分けるため
ソースリポジトリ	急に作られたリポジトリや実体のないリンクを避けるため
直近更新日	長期間静かだった拡張の急な更新を疑うため
`extensionPack`と`extensionDependencies`	依存拡張経由で意図しない拡張が入るため
native binaryや外部ダウンロード	`.node`や外部VSIX取得は実行リスクが高いため
インストール数とレビュー	低品質なスリーパー拡張を避けるため

手元では、まずインストール済み拡張とバージョンを一覧化します。

# インストール済み拡張とバージョンを一覧化する
code --list-extensions --show-versions

個人開発でも、業務リポジトリと実験用リポジトリでエディタプロファイルを分ける価値があります。秘密情報を持つプロファイルには、本当に必要な拡張だけを入れます。

チーム端末では、拡張の自動更新を完全に信用しない運用が必要です。Checkmarx公式も、IDE marketplaceの自動更新設定の見直しを推奨しています。

7. Dockerと依存更新botの守り方

KICSの事案は、Dockerタグが安全境界ではないことを改めて示しました。

latestだけでなく、v2.1.20のような一見固定に見えるタグでも、レジストリ上では上書きされる可能性があります。重要なCI/CDで使うイメージはdigest固定に寄せます。

checkmarx/kics@sha256:<verified-digest>

依存更新botも、単に「自動更新してくれて便利」では済みません。botがpullしたイメージやパッケージが、CI上でSecretsに触れるなら、botは攻撃連鎖の入口になります。

Renovateを使っている場合、たとえば次のように「新しすぎるnpmリリースを少し待つ」「DockerやActionsはdigest固定に寄せる」「重要面は手動承認する」設定が候補になります。

{
  "pinDigests": true,
  "packageRules": [
    {
      "matchDatasources": ["npm"],
      "minimumReleaseAge": "3 days",
      "prCreation": "not-pending",
      "internalChecksFilter": "strict"
    },
    {
      "matchManagers": ["github-actions", "dockerfile"],
      "dependencyDashboardApproval": true
    }
  ]
}

minimumReleaseAgeは万能ではありません。ゼロデイ的に悪性化した既存パッケージや、数日後に悪性化するスリーパー拡張は止められません。それでも、公開直後の悪性リリースを即座に取り込むリスクは下げられます。

npm CLIにもmin-release-ageがあります。CIで直接npmを使う場合は、パッケージ更新ポリシーとして検討する価値があります。

8. もし踏んだ場合の対応

踏んだ可能性がある場合、削除だけで終わらせないことが重要です。悪性コードは、すでに秘密情報を読んでいる前提で動きます。

時間軸	やること
最初の1時間	影響端末やrunnerを隔離し、該当workflowを止める。疑わしいartifact、workflow、public repoを消す前に証跡を保存する
当日中	GitHub、npm、クラウド、SSH、CI/CD、外部APIのSecretsをローテーションする。到達可能だったSecretsを対象にする
24時間以内	GitHub audit log、workflow runs、artifact、package publish履歴、Docker pull履歴、EDR、DNS、プロキシログを確認する
1週間以内	自動更新設定、Actions権限、OIDC、CODEOWNERS、runner分離、拡張機能ポリシーを見直す

特に見るべきGitHub上の痕跡は次のとおりです。

見覚えのないpublicリポジトリ
.github/workflows配下の不審な追加
不審なworkflow runとartifact
Organization SecretsやRepository Secretsの変更
npmパッケージの不審なpublish、dist-tag変更、owner変更
DependabotやRenovateのPRが、通常より強い権限でCIを動かしていないか

ここで大事なのは、IOCだけに頼らないことです。audit.checkmarx.cxや特定ファイル名が見つからなくても、別経路や亜種で動いた可能性があります。判断基準は「どの秘密情報にアクセスできたか」です。

9. 続報の追い方

このテーマは、数日単位で影響範囲やIOCが変わります。追う順番は、公式発表、キャンペーンページ、技術分析の順にすると迷いにくいです。

公式発表で影響版、影響時間帯、推奨対応を見る
キャンペーンページでIOCと影響パッケージの増減を見る
技術分析で攻撃手法と横展開の条件を見る
自分の環境では利用履歴、pull履歴、workflow履歴に落とし込む

特に更新が速いのは、Checkmarx公式のSecurity Update、BitwardenのCommunity Forums、SocketのGlassWorm v2とCanisterSprawlのキャンペーンページです。本文末の参考リンクでは、公式発表と技術分析に分けて置いています。

おわりに

ここまでお読みいただきありがとうございます。

開発者向けツールは便利になるほど、強い権限と多くの秘密情報に近づきます。だからこそ、便利な自動化を止めるのではなく、壊れても被害が広がりにくい形に設計する必要があります。

ではまた、お会いしましょう。

参考リンク

公式発表

技術分析

防御設定