VueJs（JSON AjaxレスポンスをUIに変換するJavaScriptライブラリ）とHtmx（HTML AjaxレスポンスをUIに変換するJavaScriptライブラリ）の開発依存関係の数の違いって意味あるの？違いはあるけど、桁違いってわけじゃないし、どちらも完全に独立してるわけじゃない。サーバーでJSを使わないって決めるのはこの記事の文脈では合理的だけど、クライアント側ではhtmxも他のJSライブラリと同じように（開発）依存関係があるよ。 https://github.com/bigskysoftware/htmx/blob/master/package.j... https://github.com/vuejs/core/blob/main/package.json

私の見たところ、この攻撃が依存しているのは、新しい依存関係を追加する際の開発者のチェック不足だけだね。このチェック不足がJavaScriptエコシステムに特有のものでない限り、この攻撃はRustやGolangでも起こり得たと思う。

マルウェアを取りに行くまで、サプライチェーン攻撃はパッケージ管理やマシンへのベクトル、コードのあらゆるレイヤーで起こるよ。NPMが本当に気にしてるなら、公開するのに2FAを必須にするべきだね。公開前にスキャンを要求する。パッケージにハードキーと署名で署名する。インストールされた全てのパッケージが署名と一致するか確認する。セマンティックバージョニングの一致だけじゃ不十分だし、CRCチェックも足りない。これをパッケージとパッケージ管理に組み込む必要がある。

残念ながら、こういうサプライチェーン攻撃は現代のJavaScriptエコシステムに組み込まれてるってことを実感してきたよ。 こういう奇妙な見解をよく見るけど、攻撃の範囲を最近起こった単一のエコシステムに自動的に狭めるのは、技術的な根拠がないよね。特に懸念すべきは、セキュリティ業界でこういう見解が見られること。例えばNPMをターゲットにした対策が講じられているけど、PyPiやCratesには全くない。これが奇妙なのは、そうすることで他のエコシステムが無防備になるだけじゃなく、対策は非常に似ているはずだから、大きな利益のために最小限の追加労力で済むのに。

JavaScriptは過剰に使われすぎてるし、依存されすぎてる。多くのウェブサイトはテキストや画像を表示するだけなのに、みんなが知ってるからって重いJavaScriptライブラリを使ってる。これが現代のウェブを支えるトラッキングを可能にするからね。ユーザーにとってのメリットはないし、もし本当にJavaScriptを使わざるを得ない選択肢がなければ、こういうサイトが存在しない方がいいと思う。

そうだよ。パッケージマネージャーに依存しすぎて、標準ライブラリがない言語はこういうのに脆弱だね。いつか人々は気づいて、バニラJSに戻る必要があると思うけど、それはかなり難しいだろうな。Rustエコシステムも同じだし。パッケージへの依存が多すぎる。正しくやってる例はGoだね。

伝統的なJSは実は今まで作られた中で最も安全な環境の一つなんだ。毎日、何十億ものデバイスが信頼できないJSコードを実行していて、他のプラットフォームではこんなに大規模なサンドボックス実行は見られない。ほぼ30年の間に、ブラウザエンジンに対する大規模な攻撃はほとんどなかった。それが、ブラウザから派生したJSエンジンをサーバーサイドフレームワークを作るための完璧なツールにしている。ただ、NodeJSやnpmのプロセスや実践はセキュリティの見直しが急務だね。leftpadは解決すべき文化的な問題だよ。まずは、スニペットはnpmに置く必要はない。

単にJavaScriptを避けるだけじゃダメだよ。npmは大きくて簡単なターゲットだけど、一般的な問題はすべてのパッケージリポジトリに存在するからね。攻撃者が使ってないパッケージリポジトリを狙うのを期待するより、サプライチェーン攻撃の緩和戦略を考えた方がいいと思う。JavaScript開発の文化では、抽象化を重ねるコストを無視する風潮があるけど、それに乗っかる必要はないよ。多分、一番簡単なのは遷移依存関係を数えることだね。

npmの「postinstall」って概念があるせいで、影響範囲がさらに悪化してるんだよね。これによって、インストール後にホストシステムでコマンドを実行できるパッケージが増えちゃう。依存関係の依存関係にもこれが適用されるから、node_modules内の何でもこのフックにアクセスできるんだ。これはひどいアイデアで、削除するかもっと安全なものに置き換えるべきだと思う。

サプライチェーン攻撃 OSSに関しては、この用語を使うのはやめた方がいいよ。サプライチェーンって関係を示唆するけど、これらの企業や開発者はパッケージを含める以外にクリエイターとの関係はないから。「フリーコード攻撃」とか「ホビイストコード攻撃」みたいな名前にした方がいい。

Goを主な言語に切り替えた理由の一つは、純粋なGo実装のトレンドがあって、通常は標準ライブラリとgolang.org/x以外の依存関係をゼロにしようとするからなんだ。こういうプロジェクトは、CGO_ENABLED=0で動くことを目指しているから、ライブラリが非常にポータブルで、異なるシステムコールバックエンドでも動くのがいいんだよね。それに、依存関係のスナップショットをgo mod vendorで管理するのも好きなんだけど、短期的な修正にはいいけど、長期的な原因解決にはならない。だけど、Goエコシステムもパッケージの更新に署名がないから脆弱なんだよね。「誰がこのパッケージに署名したのか」をエンドツーエンドで確認できない限り、状況は良くならないと思う。さらに、過去のサプライチェーン攻撃はCI/CDインフラに集中してたけど、そこも同じくらい問題が多いからね。署名キーがランナー自体に必要ないCI/CDワークフローが必要だと思う。そうじゃないと、攻撃対象が別の場所に移るだけだし。個人的には、パッケージマネージャーにも少し責任があると思う。GPG署名を推奨し、特に配布にgitタグを使うときはgitコミットでも義務付けるべきだよ。

自分で簡単に書けるものに依存関係を持ち込まないのが答えだね。これで多くのプロジェクトでは依存関係を2/3くらい減らせると思う。特に、left-padみたいなやつ。ちゃんと自己完結した小さなパーツといくつかのテストを書けば、あんまり触る必要もなくなるし、メンテナンスの負担もそんなに高くないよ。left-padみたいな小さな依存関係を全部チェックするのと比べるとね。もし依存関係が絶対必要じゃないなら、やらない方がいいよ。

うん、eslintは特にイライラするね：https://npmgraph.js.org/?q=eslint コミュニティには依存関係の数を減らす手助けをしてくれる人がたくさんいるけど、やっぱりメンテナーがそれを優先しないといけない。そうじゃないと、oxlintみたいな別のソリューションに切り替えるしかないよね。

この問題に苦しむ この機能の恩恵を受ける。

Rustではcargo vetがあって、監査を共有して自動化して使ってるよ。GoogleやMozillaみたいな企業も監査に貢献してる。

そうだね、ある意味でDebian（または他のディストロ）は拡張された標準ライブラリだよ。

新しいパッケージが追加されず、バージョンがほとんど変わらない安定したディストロを使うべきだよ（セキュリティアップデートとバグ修正だけ、新機能はなし）。これがほとんどの人が使ってるやり方。残念ながら、ほとんどの人は新しいハードウェアをサポートしない古いソフトウェアを使いたがらないから、結局Debian stableを使わないんだよね。

GoのパッケージリポジトリはGitHubだけなんだよね。結局、すべてはURLなんだ。特別なURLのセットを求めてるわけだ。誰かにそのメンテナンスに時間をかけさせる必要があるよ。

君のアイデアの問題は、Node/Python/Rubyライブラリのすべてのバージョンを監査したい人を見つける必要があるってことだね。

こういうことをやりつつ、分散型を維持する方法があると思いたいな。例えば、あるパッケージが一定期間に[閾値]以上のダウンロードを超えたら、さらなるコード更新には2FAの再認証が必要になるとか。もしくは、人気のあるパッケージについては、再現可能なビルドを持つ自動ビルドシステムの選ばれたリストだけが直接NPMにプッシュできるようにするとか。そうすれば、マルウェアを仕込むにはまずソースコードリポジトリを侵害しないといけないからね。正直言って、これでこのワームの拡散を完全に止められたわけではないけど、進行をかなり遅らせることはできたと思う。これは「NPMのユーザー体験や分散化を全て犠牲にする」って話じゃなくて、「リリース管理をするべき規模になった時だけ、少し手動のユーザー体験にする」ってことなんだ。

セキュリティアップデートとバグ修正だけってこと？ちょっと気になったんだけど、攻撃面が減るのはいいけど、まだ攻撃面はあるよね？

関連情報（7日前）：NPMのdebugとchalkパッケージが侵害された（1366ポイント、754コメント）：https://news.ycombinator.com/item?id=45169657

この攻撃を実際に発見したのは誰なんだろう？彼らにクレジットを与えられるのかな？これらの投稿の表現が面白いね。直接クレジットを主張している人もいれば、ただ事件を認めている人もいる。Aikidoは言う：> 「npmに対する大規模な攻撃が警告された…」 Socketは言う：> 「Socket.devがさまざまなCrowdStrikeのnpmパッケージが侵害されたことを発見した…」 Oxは言う：> 「攻撃者が新しいリリースに悪意のあるコードを滑り込ませた…」 Safetyは言う：> 「Safetyの研究チームがNPMエコシステムに対する攻撃を特定した…」 Phoenixは言う：> 「別のサプライチェーンとNPMのメンテナーが侵害された…」 Semgrepは言う：> 「いくつかの侵害されたnpmパッケージについて認識している」

まだ広がっているのかな？そのブログには違うパッケージがリストされているみたい。

こういうサプライチェーン攻撃が、意図せずに別の無関係なサプライチェーン攻撃を引き起こすのも時間の問題だと思う。

マルウェアはムーアの法則に従わなきゃいけないんだよね。テキーラウイルスは1991年に約2.6KBだった。