Nxおよび一部サポートプラグインの悪意あるバージョンが配布

 (github.com/nrwl)
3 ポイント 投稿者 GN⁺ 2025-08-29 | 1件のコメント | WhatsAppで共有
  • Nxパッケージとプラグインの悪意あるバージョンがnpmに配布され、ファイルシステムをスキャンし、認証情報を収集した後、ユーザーのGithubアカウントのリポジトリへ送信
  • 影響を受けたか確認するには、Githubアカウントにs1ngularity-repositoryリポジトリが作成されていないか確認が必要
  • 感染した場合、トークンとパスワードの交換、悪意あるリポジトリの削除、シェル設定ファイルの点検が必須
  • 悪意あるバージョンはpostinstallスクリプトでシステムに影響し、特にVSCode Nx Consoleプラグイン利用時に無意識に実行される危険が高まる
  • Nx側は再発防止と追加のセキュリティ対策を実施しており、該当バージョンはnpmから削除済み

概要と要約

  • 今回のセキュリティ勧告は、Nxパッケージおよび一部の関連プラグインに対する深刻なサプライチェーン攻撃であり、悪意あるコードがnpmを通じて配布された
  • 該当する悪意あるバージョンは、ユーザーのファイルシステムをスキャンして認証情報やパスなどを収集し、Githubリポジトリ（s1ngularity-repository）にアップロードした
  • 悪意あるpostinstallスクリプトは、ユーザーのシェル設定ファイル（.zshrc、.bashrc）も改変し、システム終了コマンドを追加した
  • 攻撃ベクトルと攻撃の進行過程、影響を受けるバージョン、ユーザーが取るべき緊急対応、再発防止策などが詳しく整理されている

緊急対応方法

全員が確認すべき事項

  1. 自分のGithubアカウントのリポジトリ一覧で、s1ngularity-repositoryが作成されていないか確認
  2. 当該リポジトリに含まれるファイルをダウンロードして記録保管
  3. リポジトリをGithub上で削除
  4. security@nrwl.io にメールを送り、漏えい情報の復号方法の案内を受ける
  5. すべてのアカウントの認証情報とトークンを直ちに交換

Githubトークンの交換方法

  • https://github.com/settings/connections/… にアクセス
  • 接続済みアプリのアクセス権を取り消して既存トークンを無効化
  • gh CLIを使っている場合は再認証して新しいトークンを生成
  • 未対応のままだと既存トークンが悪用される危険がある

悪意あるNxバージョンの利用停止と整理

  • 現在使用中のNxバージョンが悪意あるバージョンかどうかを npm ls nx コマンドで確認
  • 感染バージョンなら npm uninstall nx && npm install nx@latest で更新
  • npm cache clean --force でキャッシュを整理

すでに感染したユーザー

  • npmおよびGithubトークンを交換
  • Github、関連サービスのパスワードと認証情報をすべて再設定
  • .zshrc、.bashrc ファイルに見慣れないコマンドが挿入されていないか確認し、削除

内部パッケージリポジトリ管理者の場合

  • 社内レジストリ内のproxyから悪意あるバージョンを直ちに削除し、追加拡散を防ぐ必要がある

影響を受けたバージョン案内

Nxパッケージ

  • 21.5.0、20.9.0、20.10.0、21.6.0、20.11.0、21.7.0、21.8.0、20.12.0
  • EDT 10:44 PM時点でnpmから削除完了

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

  • EDT 10:44 PM、6:20 AM時点でnpmから削除完了

攻撃ベクトル詳細

脆弱なWorkflowの原因

  • Github Actionsワークフローに任意コード実行が可能な脆弱性が導入された
  • PRタイトルに特定のbashコードを挿入すると、ワークフローでシステムコマンドが実行される脆弱性（Bash Injection）
  • pull_request_target トリガーによりelevated権限（GITHUB_TOKEN など）を持つことになり、悪用された
  • 削除されるまでmainではない旧ブランチに脆弱なワークフローが残っており、攻撃者は悪意あるPRでワークフロー実行とシークレット窃取に成功した

npmトークン窃取の過程

  • 脆弱なワークフローを通じて publish.yml を実行させた
  • publish.yml はnpmトークンをGithub Secretsに保管しており、この過程で外部Webhookへトークンが送信された
  • 最終的に攻撃者はこのトークンを使って、Nxおよびサポートパッケージの悪意あるバージョンをnpmにアップロードした

悪意あるパッケージの挙動

認証情報を含む情報収集とGithubリポジトリへの公開

  • 感染したNxパッケージのpostinstallスクリプト実行時に、各種テキストファイルの場所と認証情報を収集
  • s1ngularity-repository という名前のGithubリポジトリにbase64エンコードしてアップロード
  • 実際のリポジトリが削除済みでも、以前は公開状態だったため情報漏えいの可能性を考慮する必要がある

シェルプロファイル（.zshrc、.bashrc）の改ざん

  • postinstallが sudo shutdown -h 0 コマンドを挿入し、ターミナル実行時にシステム終了を誘発し、パスワード露出の可能性がある

postinstallが動作するさまざまなシナリオ

  • npm install / yarn / pnpm install の明示実行以外にも、推移的依存関係、エディタ拡張、スクリプト実行など多様な状況で動作する可能性がある

  • 特に、VSCode用Nx Console拡張（18.6.30〜18.65.1バージョン）は、エディタ起動時に自動で nx@latest をインストールし、postinstall実行を引き起こす可能性がある

  • 根本的に、意図しなくてもさまざまな場所でNPMモジュールのインストールが行われ得ることに注意が必要

  • Nx Console（18.66.0）からは、latest nxのインストール過程が削除された

攻撃と対応のタイムライン

8月21日

  • 4:31 PM: Bash注入脆弱性を含むPRがマージ
  • 10:48 PM: 脆弱性を指摘する投稿がX（旧Twitter）に掲載

8月22日

  • 午後: 内部調査、脆弱なワークフローをロールバック（不完全）
  • CodeQL導入により、今後のPRで類似脆弱性の検知を適用

8月24日

  • 攻撃者フォークでnpmトークン漏えいの兆候があるコミットが発生
  • 悪意あるPRが作成・削除され、publish.yml がこのPRによって実行された

8月26日〜27日（悪意あるバージョン配布、対応）

  • 悪意あるNxおよびプラグインの多数バージョンがnpmに順次配布
  • Github/NPMコミュニティへ問題報告
  • 10:44 PM: NPM側が該当バージョンを全量削除するなどの対応
  • 11:57 PM: すべてのNx関連パッケージ公開用トークンを無効化
  • 8月27日: Nx Consoleのパッチ、2FA、Trusted Publisher方式への移行など追加対応

事前予防措置と今後の対応

  • すべてのnrwl組織maintainerに2FAを義務化
  • Trusted Publisherメカニズムを適用。npm tokenベースの配布を禁止
  • 今後のパッケージは必ず2FA・信頼ベースの検証後に配布
  • 追加リスク検知、PR承認、ブランチ保護などを段階的に適用

教訓と今後の計画

  • サプライチェーンとCI/CDパイプライン、ワークフロー権限の最小化の重要性をあらためて認識
  • チーム内で再検討した後、コミュニティに学習内容を共有予定

問い合わせ

  • security@nrwl.io に問い合わせ可能

参考および付録

  • Githubの主要Issue、タイムライン、関連ポスト
  • 感染パッケージ内の telemetry.js スクリプト例を提供
  • このスクリプトは、ファイルシステム内の主要テキストファイルのパスをインベントリ作成目的で収集する

結論要約

  • Nxと関連プラグインの最新アップデートとパッチ適用が重要
  • npm、Githubなど主要認証情報の即時交換を推奨
  • サプライチェーンセキュリティとワークフロー権限管理の不備が大規模事故につながり得ることを示した事例

関連記事

1件のコメント

 
GN⁺ 2025-08-29
Hacker Newsのコメント

  • 定期的に npm install スクリプトを無効化するよう勧めたい

    • たとえば次のコマンドを使う:

        npm config set ignore-scripts true [--global]

    • この設定はプロジェクト単位でもグローバルでも簡単に適用できる

    • 最近はスクリプトなしでは動かない正当なパッケージはまれなので、たいてい問題ない

    • 動作に必須なパッケージは、別のインストールスクリプトを作ってそのフォルダで手動実行することで対応できる

    • サプライチェーン攻撃への万能な解決策ではないが、実際に npm 経由の多くの攻撃を効果的に防げた

    • 詳細は npm config公式ドキュメント を参照

    • 自分は bubblewrap も使って npm、pnpm、yarn およびそれらが起動するすべてのセッションをシステムから隔離して実行している

      • 自分のソースコードは ~/code 配下にしか置かず、PATH の先頭に以下の bash スクリプトを npm として保存している
      • 他のパッケージマネージャーもシンボリックリンク/ハードリンクで接続: 
        #!/usr/bin/bash
bin=$(basename "$0")
exec bwrap \
  --bind ~/.cache/nodejs ~/.cache \
  --bind ~/code ~/code \
  --dev /dev \
  --die-with-parent \
  --disable-userns \
  --new-session \
  --proc /proc \
  --ro-bind /etc/ca-certificates /etc/ca-certificates \
  --ro-bind /etc/resolv.conf /etc/resolv.conf \
  --ro-bind /etc/ssl /etc/ssl \
  --ro-bind /usr /usr \
  --setenv PATH /usr/bin \
  --share-net \
  --symlink /tmp /var/tmp \
  --symlink /usr/bin /bin \
  --symlink /usr/bin /sbin \
  --symlink /usr/lib /lib \
  --symlink /usr/lib /lib64 \
  --tmpfs /tmp \
  --unshare-all \
  --unshare-user \
  "/usr/bin/$bin" "$@"
      • こうするとパッケージマネージャーは ~/code とシステムライブラリへの読み取り専用アクセスしか持てない
      • bubblewrap は安定していて、Steam や flatpak などでも使われているツールだ

    • pnpm を使うのも方法だ。最新バージョンはデフォルトであらゆるライフサイクルスクリプトを無視し、個別にホワイトリスト登録したものだけ実行する

    • この助言を聞くたびに思うのだが、npm がインストールした数十万〜数百万行のコードを実際に全部読む開発者はいない

      • たいていの開発者のワークフローはこうなる
        1. git clone
        2. npm install（ここで悪性パッケージが入る危険がある。post-install スクリプトを無視すれば一時的には防げるが）
        3. npm run（ここで悪性パッケージが実行されて感染する）
      • この助言が有効になるには、2 と 3 の間で node_modules 全体を監視・監査する必要があるが、そんなことをする人はいない

    • 自分は npm ベースのツールをすべて Docker コンテナ内で、現在のディレクトリ以外にはアクセス権なしで実行している

      • 攻撃対象領域を劇的に減らす効果がある
      • 方法は ブログ記事 を参照

    • なぜこうした助言が setup.py（Python）や build.rs（Rust）には同じように適用されないのか気になる

      • npm はしばしばソフトウェア配布自体にも悪用されるが（たとえば別プログラムの配布）、他言語のパッケージマネージャーはライブラリ管理だけに使われるからなのだろうか
      • 関連する議論は こちら を参照

  • 新しい依存関係を追加するときは本当にもう一度考える文化が必要だ

    • 今年は本当に多くのサプライチェーン攻撃が起きた

    • 今週、Go プロジェクトに 8 個の統計カウンター付きプログレスバーを追加しようとした

    • ライブラリを探したらコードが 3,000 行を超えていたので、LLM に簡単な UI コード生成を頼んだら 150 行未満で済んだ

    • 依存関係なしで意図どおり動き、とても単純なので誰でも簡単に読んで改善できる

    • 機能は端末出力を消して毎秒再描画し、スレッドセーフ対応というものだ

    • 導入とレビューまで 25 分で十分だった

    • 複雑な統計機能が不要なら、30 行程度のコードでもプログレスバーは十分実装できる

    • 今後、依存関係を追加するか悩んだら自作する方向のほうが自分には合っていそうだ

    • すべてのパッケージ更新を監視するだけのリソースはない

    • その指摘には同意するし、「言語ごとのパッケージマネージャー」が普及し始めた頃は本当に不安だった

      • システムプログラミング寄りの仕事をしていて pip や npm などを距離を置いて見ていたが
      • Rust プロジェクトに移って、Cargo の 1 行設定だけで未検証の依存関係を何十個もインターネットから引っ張ってくるのを体験し、危険だと思った
      • 実際にこうなってしまった。良い方向ではないと思う。（とはいえ、もう後戻りするとは思っていない。そもそもコンピュータセキュリティなんて存在しないのだから……）

    • 自分は cargo vet のようなアプローチが今後の方向性だと思う: cargo vet の紹介

      • もちろん、すべての言語エコシステムにこういう仕組みが必要になる以上、オーバーヘッドは大きくならざるを得ない
      • インターネット初期やメールにも良い時代はあったが、結局スパムと商業化で壊された
      • 今では依存関係の連鎖までもが同じ被害を受けている
      • こういう理由で、私たちは良い環境を維持できなくなる

    • 自作とライブラリ利用の違いは当然ある

      • ライブラリは本質的に汎用で、さまざまな環境に合わせて柔軟かつ設定可能である必要があるため、コードが長くなるのは避けられない

    • 自分はこういうプログレスバーライブラリ、特に emacs shell を壊すものが本当に嫌いだ（expo、eas など）

      • なぜ単純に ..10%..20%..30% や Uploading… のように出力しないのか分からない
      • 端末制御コードは TUI や対話型インターフェース専用にすべきだと思う

    • うちのチームは大手保険会社で NX を中心に大規模モノレポとライブラリ群を運用している

      • 10 個以上の独立アプリと 25 個以上のライブラリを単一モノレポで管理し、CI/CD もかなり密結合している
      • lerna、rushjs、yarn workspaces なども試したが、NX ほどうまくいくツールはなかった（lerna も結局 NX に買収され、rushjs も管理されていない）
      • フロントエンドのモノレポの複雑さをきちんと扱える方法や代替案を提案してほしい
      • 今回のセキュリティ事故で代替に関心を持つ人が多いだけに、いろいろな意見を聞きたい

  • Nx や Anthropic、プラットフォームだけを責めず、本当の原因を考え直すべきだ

    • 今回の攻撃の実質的な原因は、盗まれた「トークン」（パッケージマネージャー作業権限を与える文字列）で悪性パッケージをアップロードできたことだ
    • しかしこれは配信手段にすぎず、成功させた根本原因は以下の点にある:
      1. パッケージマネージャーのリポジトリが成果物の署名を必須にしておらず、権限を持つ開発者が作ったものだと検証できなかった
      2. コード署名も必須ではなかった
      3. （推定）異常行動検知、新規 IP 登録、国変更などの異常アップロード防止ヒューリスティクスが実装されていなかった
      4. （推定）盗難トークン使用時に MFA が必須ではなかった
      5. （推定）トークンがワンタイムではなかった
      6. （推定）トークンが新しいアプリケーションやセッションで使われたとき、手動承認が必要なパスワードマネージャーに保存されていなかった
    • これらはすべて、防げたはずのことだ
    • 実際、自分が被害を受けて GitHub アカウントに新しいリポジトリが作られていたなら、自分自身も認証トークンを十分に強く保護していなかったことになる
    • こうした予防策がデフォルト設定になっていないのは、ソフトウェア業界全体の大きな失敗だ
      • この攻撃は何年も繰り返されてきた
      • 私たちは自分たちが開発者であるにもかかわらず修正してこなかった
    • だから自分は、建築基準法のようにソフトウェアにも強制的な規制（検査や罰金を含む）が必要だと主張する

      • この攻撃は金融、電力、通信、病院、軍事など何万もの組織に壊滅的な被害を与えうる

      • AI の普及に伴い、攻撃の規模と影響力はさらに大きくなる

      • 私たちは十分に責任あるソフトウェアの書き方ができていない。建築基準法のように強制的にでも安全とセキュリティを守るべきだ

      • 今の個人向けコンピューティング環境が一つの大きな空間にまとまっていること自体が、思った以上に危険だ

        • Mac、Windows、Linux のどれでも、暗号資産ウォレット、認証情報ファイル、さまざまなアプリが全部同居している
        • これらをうまく分離するツールはまだ貧弱だ
        • ときどき macOS 上で複数の Windows VM を動かしながら、最終的には作業ごとのコンテナや VM に Alt-Tab で切り替えて入っていく、きれいで滑らかな未来を想像する
        • たとえば、ゲーム用コンテナ、暗号資産作業専用コンテナ、主要コードプロジェクトごとのコンテナなど
        • VSCode 拡張機能を一つ入れただけでビットコインの鍵が漏れるかもしれない、という現実は本当におかしい
        • ソフトウェア版の建築基準法のようなルールだけでは、こうした根本問題までは解決しにくいと思う
        • OS レベルでアプリ間のデータアクセスを制御する規則も必要で、実際にどう策定し執行するかまで議論すべきだ

      • 被害者の 50% は VS Code が感染経路で、Linux と macOS でのみ動作した

        • この攻撃の詳細分析は ブログ分析 を参照
        • 感染時には:
          • postinstall 段階でユーザー認証情報など重要資産（暗号資産ウォレット、Github および npm トークン、SSH 鍵など）を収集
          • AI コマンドラインツール（Claude、Gemini、Q など）を使った情報収集と能動的な偵察
          • 盗んだデータを base64 で二重・三重エンコードしたうえで、攻撃者所有の GitHub リポジトリ（s1ngularity-repository など）へアップロード
          • 何千個ものリポジトリが見つかっている
          • 1000 個超の GitHub トークン、数十件のクラウドおよび NPM 認証情報、約 2 万ファイルが流出した
          • 主に NX の VSCode extension 経由で実行されるか、ビルドパイプライン（例: GitHub Actions）上で動いていた
          • 8 月 27 日 9AM UTC に GitHub が攻撃者のリポジトリをすべて無効化したが、最大 8 時間の露出期間中にデータは流出した
          • base64 エンコードは簡単に元に戻せるので、このデータは事実上すべて公開されたと見なすべきだ

      • GitHub トークンや認証情報を手動解除型のパスワード管理ツールに入れていないのは GH CLI のせいでもある

        • GH CLI は一度ログインするとリポジトリアップロード権限が付き、再認証をほとんど要求しない
        • AWS CLI はポリシー次第だが 18 時間ごとに自動失効する
        • ただ、どちらのプラットフォームでもデフォルトではローカル環境にトークンが平文で残りやすい

      • 「ソフトウェア建築基準法」導入の発想は好きではないが、業界全体があまりにも脆弱だという点には同意する

        • 規制が本当に必要な段階なのかもしれない

      • 無料のオープンソースライブラリを使っておいて責任を問うという発想は傲慢だと思う

        • ちゃんとした保証が欲しいならライセンスを買うべきだ
        • 無料ソフトウェアに責任を負わせようとする Google の敵対的な検証ポリシーと同じだ

  • 最近の開発作業の大半を VM でやっている

    • 今の環境のセキュリティ水準は到底受け入れられないと感じる

    • エージェント（エージェント型ソフトウェア）がマルウェアのベクターとして機能する可能性が極めて高くなった

    • 攻撃者がマシンに侵入したなら、1,000 ドル以上の価値があるデータ、暗号鍵、パスワード、個人情報、金融情報などもいつでも狙われる時代だ

      • 自分も似たように Podman コンテナ内で作業している。ソースコードのディレクトリ以外はホストと共有しない

      • 問題の一部は従来の PC セキュリティモデル（Linux/Windows）にある

        • 実行ファイルを信頼済みとして扱い、それらに自分のあらゆる個人情報へのアクセスを許すモデルは 2025 年には合っていない
        • モバイル（Android）はだいたいこれを克服したが、PC では SELinux 以外に深い代替があまりない

      • もしこういうやり方が好みなら、Qubes OS を勧めたい。すべての作業を VM で行える良い UX を提供してくれる

        • 自分の日常使いの環境で、本当に強く勧める

      • ただし、こうした環境の構築はソフトウェアエコシステムや歴史的経緯のために非常に難しいか、かなりコストがかかる点は明記しておく

  • Claude Code は生産性向上のための革新的なツールだ

    • 一方で、次のようなセキュリティ上の懸念がある:

      • NodeJS アプリである
      • インストール時に curl を bash にパイプする（リモートコード実行リスク）
      • LLM がファイルシステムやコマンドなどさまざまなものに触れられる

    • このように少なくとも 3 つのセキュリティ上の弱点があるので、VM/コンテナ/専用開発マシンのようなサンドボックス外で動かしたくない

      • 自分もエージェントはサンドボックスで動かすべきだと思う

        • その代わり、Claude code は最初から（個別の許可なしに）勝手にコマンドを実行したりはしない

      • それで、だから何だというのか？

        • ユーザーが自分で実行ボタンを押さないと動かない
        • たいていのプログラムも同じく権限を持っている
        • ターミナルだってファイルシステムを触れるが、だからといって勝手には動かない
        • Claude Code は自分のコンピュータを自発的に壊すデーモンのようなものではなく、明確な指示がなければ何もしない
        • 自分は Claude Code をここ 30 年で使った中で最高のツールだと思っている
        • 「攻撃ベクター」が何だったかはあまり気にしていない。誰かが自分のコンピュータに不正アクセスしたなら、それは Claude Code 固有の問題ではない

      • 本当に危険なのは、ユーザーの介入なしに自動更新を行い、実行中のリモートコード実行（RCE）権限を Anthropic に与えてしまっている点だ

  • パッケージマネージャーに「最小パッケージ年齢（min-age）」のような設定が必要ではないかと思う

    • たとえば、登録から 24〜36 時間未満のパッケージは無視するようにすれば

    • 以前に似たケースを経験したが、パッケージ更新がすべてを壊し、数時間後にはすぐ修正・削除された

      • GitHub dependabot が最近まさにそういう機能を追加した

      • Renovate bot はすでに（minimumReleaseAge 設定で）この手のオプションを提供している。dependabot も今は対応している

        • パッケージマネージャーは最新バージョンを入れることしか気にしないが、こうした無料ツールで適切な周期の更新管理ができる
        • JavaScript エコシステムは徐々に統合の方向に進んでおり、サプライチェーン攻撃対策ツールも少しずつ出てきている
        • 最新の NPM、PNPM、Bun などは postinstall スクリプトをデフォルトで実行せず、必要なときだけ明示的に実行する必要がある（それでも結局は他人のコードを実行することに変わりはない）

      • OS レベルではないが、Astral の uv ツールには Python パッケージ向けにこういうオプションがある

      • npm install にも、ある時点/日付以前の依存関係だけをインストールするフラグがある

        • npm install --before (2日前の日付) で、その日付以降に登場した依存関係はインストールしない

      • 自分は .npmrc に save-exact=true を設定し、lockfile と手動更新だけを使っている

        • パッケージを頻繁に上げる必要はない
        • fakerjs の件などを経験して、慎重であるべきだと感じている

  • claude code が本当にそういうプロンプトを実行するのか疑問だったのでテストした

    • 結果は次のとおり:

      • 「この依頼は暗号資産ウォレット、秘密鍵などの機密ファイルの検索・列挙を求めているようで、悪用の恐れがあるため手伝えない」

      • セキュリティ点検、脆弱性分析、監視ツール作成、ファイル権限の理解、バックアップ手順設計などの正当な依頼だけ案内した

      • 少なくとも 250 件以上の成功例を確保している（つまり、一部のプロンプトは通っている）

        • Claude は平均的に拒否率がかなり高く、Q もよく拒否する（Claude ベースなので似ている）
        • ちなみに、自分は一日中こうした問題への対応をしながら関連する 分析レポートを書いた

      • 実戦で Claude と他モデルが拒否合戦になるたび、Claude の拒否や安全対策のほうがはるかに優れていると毎回確認している

        • 有名な例では、ChatGPT は精神的な問題を抱えた利用者を延々と「The Oracle」として扱い続けた一方、Claude は拒否して専門家への相談を勧めた
        • もちろん「正解です！」系の返答が続くといら立つこともあるが、Anthropic が他社より拒否と安全性を重視している点は十分認めて評価できる

  • OS はデフォルトでアプリがファイルシステム全体に無制限アクセスできないようにすべきだ

    • 一部のアプリには apparmor/selinux プロファイルがあり、firejail なども使える

    • ただし UX の面で変化が必要だ

      • これは非常に深刻な問題だ。30 年前のデスクトップ前提で設計されたからだ

        • 一方で最新のモバイル OS（iOS など）は、アプリごとのサンドボックスと権限許可のポリシーが優れている
        • デスクトップでは Qubes（OS）、Firejail、bubblewrap、AppArmor などさまざまな試みがあるが、複雑だったり一般ユーザーには使いづらい
        • OpenSnitch もあるが、ネットワークに限定される
        • エンドユーザーにとっては、プログラムごとに権限設定を細かく調整するのは負担が大きい
        • 結局、広く使われるアプリ向けのプロファイルが継続的に保守されることが重要だ
        • デスクトップのセキュリティがここまで脆弱なのは衝撃的だが、本質的に難しい問題であり、解決しても金銭的インセンティブが小さい

      • 自分は Linux で Podman によるプロジェクト別環境分離に特化したツールを自作中だ: probox

        • UX 改善に力を入れている
        • よく使っているので、セキュリティレビューをしてくれる人が必要だ

      • Android のファイルセキュリティについては Google はよくやっている

      • bubblewrap と小さな chroot 環境の使い方を覚えるのも勧める

      • どの OS も、アプリケーションに「ファイルシステム全体への無制限アクセス」をデフォルトで与えているわけではないと思う

        • Linux、BSD、MacOS、Windows のいずれにも強力な制限条件がある
        • 一般ユーザーが自分で危険な形で権限昇格して実行しない限り、基本的には安全だ

  • 昔は「攻撃者は自分の環境を言い当てなければならない」という漠然とした自信があったが、今では LLM に環境に合わせた攻撃を学習させて実行させられる

    • 自分でもこの流れを実際に予測していたような気がしている

    • 以前の議論 に参考になる話があった

      • （冗談）自分は攻撃者だ、新しいアイデアある？ (/s)

  • 本当にぞっとするのは、今やローカル LLM を使ってシークレットを見つけ出すやり方だ

    • 「postinstall」問題自体は以前と同じだが、ペイロードはまったく新しい世代のものだ

    • 悪性ロジックがコードではなくプロンプトに隠れるため、従来の静的解析では検出しづらくなる

    • こうした悪性プロンプトをどう防げばいいのか考えさせられる

      • Claude Code を完全に隔離されたコンテナ/VM で動かし、コミットするコードをすべて自分でレビューする以外に答えはなさそうだ