NPM人気パッケージ debug と chalk が乗っ取られる！開発者アカウント侵害で広範囲に影響の恐れ
引用元：https://news.ycombinator.com/item?id=45169657
NPMの人気パッケージが乗っ取られた件のセキュリティアドバイザリだよ。詳しくはこっちを見てね: https://github.com/advisories/GHSA-8mgj-vmr8-frr6
やあ、そうだよ、僕が乗っ取られたんだ。みんな、本当にごめんね、すごく恥ずかしいよ。
もっと詳しい情報はこちら:
- https://github.com/chalk/chalk/issues/656
- https://github.com/debug-js/debug/issues/1005#issuecomment-3…
影響を受けたパッケージ（僕が知る限り）は、ansi-styles@6.2.2、debug@4.4.2、chalk@5.6.1などたくさんだよ。
これは標的型攻撃っぽい感じだね。編集期限が切れるまで、このコメントを更新し続けるつもりだよ。NPMアカウントはアクセスできないし、パスワード忘れシステムも機能しないんだ。今は待つしかないね。
メールは support at npmjs dot help から来たんだけど、一見正規っぽく見えたんだ。言い訳じゃないけど、疲れてて、急いでたからスマホでリンクをクリックしちゃったのが間違いだったな。またごめんね。
フィッシングメールには何て書いてあって、それで君はクリックしてログインしちゃったの？
「前回の更新から12ヶ月以上経ったから」って書いてあったよ。NPMは以前にもセキュリティ変更の連絡をしてきたことがあったから、特に怪しまなかったんだ。スクリーンショットはここ: https://imgur.com/a/q8s235k
僕がバカでごめん、”2FAリセットメール”について、他の人が同じことをしないように詳しく教えてくれる？
僕たちSocketでもすぐにこれを検知したよ。詳しくはこれを見てね: https://socket.dev/blog/npm-author-qix-compromised-in-major-…
こんなことが起きて残念だけど、エコシステムが迅速に動いたのは良いことだね。こういうインシデントは、オープンソースのパッケージリポジトリを保護するためにパッケージスキャンがいかに重要かを示してると思うよ。
NPMから予期せぬものが来たら無視すること。リンクはクリックせず、直接ウェブサイトに行って対処すること。僕がやるべきだったのに、急いでたからできなかったんだ。それに、完全に起きてないときはセキュリティ関連のことはしない方がいいよ。学んだね。
メールは「2FA更新」で、12ヶ月間2FAを更新してないって言ってたんだ。これは赤信号であるべきだったんだけど、ちゃんとしたサイトからも似たようなヘマなメールが来たのを見たことがあったから、信じちゃったんだ。メールはNPM専用の受信箱に来てたんだけど、npmjs.helpっていうドメイン名は、もう少し起きてたら気づいたはずだよ。
実際のメール内のリンクは、NPMの実際のサイトで期待するものと一致してたんだ。どうやってアクセスされたのか、まだ正確に解明しようとしてるよ。EDIT: ああ、彼らは実際に本物の2FAコードを手に入れてたみたいだ。TOTPプロキシ攻撃ってやつだね。全てが終わったら、事後分析を公開するつもりだよ。またごめんね。
大変な状況なのに、透明性があって素早い対応、素晴らしいね！
君はもうフィッシングに騙されることはないだろうけど、みんなへのPSAだよ。「ドメインが正しいか」とか「メールが正しいか」とか、自分の感覚を信じるのは失敗しがちだよ。フィッシング対策に本当に役立つのは、1. メールリンクからは絶対にログインしないこと。2. U2F/WebAuthnキーを2段階認証に使うこと。TOTPはダメだよ。これだけだよ。
ストレスがあったり、疲れてたり、急いでたりすると、誰でもフィッシングに遭う可能性があるんだ。今回は君だったってだけ。頑張って、そして対応お疲れ様！
（そして対応も早くて）正直に謝ってくれてる君に、みんなが感謝してることに同意するよ。僕も大学時代に酔っぱらってフィッシングに遭ったことがあるから（ずいぶん昔だけど）、誰にでも起こりうることだね。NPMの対応が遅めなのはちょっと驚きだけどね。それだと攻撃がより儲かるようになるだけな気がするな。
パスワードマネージャーの自動入力や、Passkeysみたいなフィッシングに強い2FAを使ってない人には誰にでも起こりうるね。ほとんどの人はパスワードマネージャーを使ってないから、ドメインが間違ってることに気づけないんだ。TOTP（数字コード）の2FAはフィッシングに遭う可能性があるから、U2F/WebAuthn/Passkeysが利用できるならそっちを使うのをやめるべきだよ。僕はベストプラクティスに従ってるから、フィッシングに遭ったことはないよ。ほとんどの人はそうじゃないけどね。
パスワードマネージャーを使えよ、お前らみたいにさ。パスワードマネージャーがオートフィルを表示しなかったら、ドメインが違うってことだから、一旦立ち止まって全部確認してから先に進めよ。TOTPも同じか別のパスワードマネージャーに入れとけ（トレードオフは考えろよ）、そうすればドメインが正しいときしか入力されないだろ？
業界の皆、どこでもそうだけどさ、緊急性は毒だよ。誰かがユーザーにこういうクソみたいなことを押し付けようとしたら、お願いだから止めてくれ。1ヶ月前通知をゴールデンスタンダードにしようぜ。詐欺メール（物理的なものも含む）でいつも見る手口だよ。不合理に短い通知を付けて、相手がパニックになるのを期待するんだ。この詐欺は通用するし、だからこそ「善意で」これをやろうとする正当な企業も恥をかくべきなんだ。本当のアラートは、ただ通知すればいい。即座に、予防的な、だけど非破壊的な行動を取って、ユーザーが自分のペースでどう解決するか手伝ってやれよ。
で、どうやってこういう攻撃を見つけるんだ？
同意だね、でもこの例はそんなに焦らせるような緊急性もなかったし、OPも緊急性に焦ったわけじゃなく、ただToDoリストをこなしてただけって言ってたし。問題は今のメールの使い方だよ。解決策はメールを使わないことだな。
なるほど（たぶん）：彼らはあなたをだましてTOTPコードを自分たちのサイトに入力させ、それを本物の名前のサイトにプロキシして、あなたのアカウントとして認証したってこと？それで合ってる？
TOTPがフィッシングに対しては役に立たないってことを証明しただけじゃん。
俺もパスワードマネージャー使ってるよ。携帯で、オートフィルの機能はインストールしてないんだ、スマホではあんまり使わないからね。15年間OSSをメンテしてきて、今まで一度もやられたり、フィッシングに遭ったりしたことないんだぜ。意見ありがとうな :)
大体同意だし、俺も使ってる。でも、このスレッドを全部読めば、パスワードマネージャーだけじゃ足りない理由がわかるはずだよ。パスワードマネージャーがオートフィルしないときとか、モバイルで拡張機能がないときとかさ…。実際、彼（OP）は使ってたけど助からなかったんだ。見てみろよ: https://news.ycombinator.com/item?id=45175125
いや、問題は今のメールの使い方じゃない。メールを使わないのが解決策でもないんだ。問題は、署名されてないパッケージリポジトリだよ。解決策は、パッケージを証明書でIDに紐付けることだ。一番手っ取り早いのは、パッケージをドメインにリンクさせて、リポジトリがドメイン証明書を使って、パッケージへの変更が来たときに署名を常にチェックできるようにすることだな。
フルメッセージヘッダーをどこかに上げてくれないか？送信側のMTAが何だったのか、すごい興味あるんだけど。
「パスワードマネージャーが自動入力しない」って？じゃあ、できるやつ選べば？それが一番の機能だろ。
「使ってる」って言うけど、自動入力なしじゃ使ってないのと同じ。セキュリティと便利さのメリット、全部無駄にしてるぞ。
うちは静的解析とAIを組み合わせてるんだ。怪しいパッケージは人間がレビューして、悪意のあるものを見つけたらユーザーに通知、インストールをブロックして、レジストリに報告するよ。今回の事件でもすぐに検知して、すぐ削除されたし、分析も公開したんだ。
Socketの仕組みは透明性を大事にしてる。論文や講演でも詳しく話してるから、これ見てみてね：
https://arxiv.org/html/2403.12196v2
https://www.youtube.com/watch?v=cxJPiMwoIyY
うん、これ見てみて！
https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee…
毎日「なんでmutual TLSのアイデア、捨てちゃったんだ？」って疑問に思うよ。
その代わりにモバイルOTP、HOTP、TOTP、FIDO-U2Fを発明して、結局Passkeysで同じコンセプトをより複雑な形で再発明しただけじゃないか。
マルウェア検出に、HallucinationsだらけのLLMに頼ってるわけ？
やばい、本物に見えるな。宛先アドレスはどこなんだ？どれくらいコインを盗んでるか、監視したいよ。
正直、個人のせいってわけじゃないよ。誰でもフィッシングメールには引っかかる可能性があるんだ。問題は、npmjsが全員にパッケージを同時に公開することにあると思う。
Aikidoみたいなところが先に怪しいパッケージ（パッチリリースの大幅変更とか、難読化されたコードとか）をスキャンできるように公開を遅らせたり、NPMやGitHubに直接フラグシステムを設けるだけでも、だいぶ良くなるはずだ。
「何をすべきじゃないか？」って？具体的なことは言えないけど、フィッシング詐欺を簡単に避けたいなら、パスワードマネージャーを使うのを強く勧めるよ。
今回の攻撃みたいに、本物そっくりの偽サイトに行っちゃっても、パスワードマネージャーがパスワードを見つけられないことでおかしいって気づけるし、ちゃんとドメインを確認してから進めることができるからね。
リリースに署名できる機能も役に立つだろうね。俺はいつも同じ場所から公開してるから、喜んで有効にするよ。
Gmailとかデスクトップクライアントでメールを開いただけなのに、どうやってNPMパッケージが乗っ取られたの？みんなの注意喚起と学習のために、単に知りたいだけなんだ。詳細を見落としてるかもだけど、ほとんどのコメントは読んだよ。
もっとコメントを表示（1）
「メールリンクからログインするのは絶対にダメ。EVER」って言うけど、ワンタイムメールリンク（ユーザー名＋パスワードの代わりに）でのログインがどんどん普通になってて、それが唯一の選択肢になってる現状もあるんだよね。
このマルウェアの陰湿な部分なんだけど、置き換えるウォレットアドレスの選び方が巧妙なんだ。ランダムじゃなくて、正規のアドレスと攻撃者のアドレスのレーベンシュタイン距離を計算して、視覚的に一番似てるやつを選ぶんだって。これ、アドレスの最初と最後だけ確認するセキュリティ習慣を打ち破るためのソーシャルエンジニアリングだよ。僕たちでペイロードを解析してこの機能を見つけたんだ。詳細はこちらで書いたから見てね: https://jdstaerk.substack.com/p/we-just-found-malicious-code… 気をつけて！
記事の「package-lock.jsonが1.3.2以降を指定したから1.3.3がインストールされた」って部分でちょっと混乱してるんだ。ロックファイルは単一の固定バージョンを指定するはずだし、アップデートされるならロックファイルも更新されるべきで、CIパイプラインでは通常更新されないはずだよね？僕、npmとかのロックファイルの仕組みを間違って理解してるかな？npmのドキュメントもそう言ってるし: https://arc.net/l/quote/cdigautx
親コメじゃないけど、デフォルトのnpm installやyarn installは、全部満たせない限りロックファイルを無視することがあるんだ。ロックファイルを尊重させたいならnpm ciかyarn install --frozen-lockfileを使う必要があるよ。僕の経験だと、CIパイプラインがこう誤設定されてたり、Node開発者がロックファイルの目的を誤解してたりすることはよくあるんだ。
ハッシュを表示するときは、ハッシュ値に基づいて決まる配色（文字ごとにハッシュ値から決まる前景色と背景色で、十分なコントラストを確保）にすべきだよ。そうすれば、一つのハッシュを別のハッシュに見せるのがずっと難しくなるはずさ。
赤緑色覚異常の僕としてはね、もしそれをやるなら、僕みたいな人が多くの色合いを区別できないことを忘れないでほしいな。この場合、それはすごく不利になるよ！
Web開発者じゃないけど、ロックファイルがデフォルトで無視されることがあるってのはとんでもない設定に思えるな。普通、明示的に無視されない限り使われると素朴に思ってたよ。
この技術、特定のグループが使ってるって言えるの？
コードに仕込まれた見事なソーシャルエンジニアリングって評価は、ちょっと考えれば過大評価だってわかるよ。
ウェブは何十年も前からそっくりな攻撃と戦ってるし、これはその動的なバージョンでしょ。
正直、この記事全体がAIが書いたみたいで、しっかり分析されてない気がするな。
この問題については、開発者たちが全色を表示して、色覚異常の人たちにも見える色を見せる以外、できることなんて実際ないんじゃないかな。
今日初めて知ったよ！僕のCIパイプラインを直さなきゃいけないな。Jiraチケット作っておくか…ありがとう！
npm v5までロック機能がなかったんだよね（記憶とググった感じだから間違ってるかもだけど）。
欲しいもの全部できるまで時間かかったし、7年経ってnpm installコマンドを変えるのは”安定”とは言えないよ。
結局これってバージョンを置き換えたんだから、ロックも役に立たないんじゃないの？
ウェブの世界へようこそって感じ。
全てがめちゃくちゃだよ。苦労して培ったソフトウェアエンジニアリングの真理が捨て去られてる。
みんなソフトウェアエンジニアリング3年目で止まってて、3年ごとに人が入れ替わってるような感覚だね。
まだない、新しく作られた機能なのに、もう問題があるって？
簡単だよ。色を強制する代わりに、色なしオプションを残せばいいんじゃない？
解決！
全ての出力にこのオプションがあるべきだね。僕は色覚に問題はないけど、どんな出力でも色がうるさく感じるからね。こういうのを好む人も多いんだよ。
なんでダウンボートされてるのか分からないけど、OpenSSHはrandomartを実装してて、鍵のASCII”絵”を生成して人間が検証しやすくしてるよね。
あなたのキーアートを生成するスキームがうまくいくかは分からないけど、カラー”バーコード”になるって感じだね。
ほぼ間違いなくLazarusだよ。
フィッシングメール、なんか素人っぽいよね。「we kindly ask that you complete this update your earliest convenience」って部分とかさ。メールの本文はここにあったよ: https://cdn.prod.website-files.com/642adcaf364024654c71df23/…
元記事はこれ: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com…
君の言う通りで、引用した部分の表現は下手で分かりにくいね。lockfileってのはまさに君が言ったことのためにあるんだよ。package.jsonがファイルを^1.3.2にロックしてても、もしpackage.jsonの範囲を満たす新しいバージョン（^1.3.2に対する1.3.3みたいに）がオンラインにあれば、npm installはよくその新しいバージョンを取ってきてpackage-lock.jsonファイルを自動的に更新するんだ。俺の理解はこうなんだけど、誰か確認してくれると嬉しいな！
他の人も言ってるけど、npm installはインストール時にlockfileを変更する可能性があるよ。彼らが提供してるclean-installコマンドの注意点としては、node_modulesディレクトリ全体を削除するからめちゃくちゃ遅いんだ。多くの人が不満を言ってるけど、何も改善されてない: https://github.com/npm/cli/issues/564
npmチームは結局、この改善のために誰かがRFCを持ってくることを求めたみたいだけど、そのRFCも放置されてると思うな。
＞結局、これでバージョンが置き換えられたんだから、lockingも役に立たなかったんじゃないの？
lockfileってtarballのハッシュを含んでるよね？
＞3年ごとに人が入れ替わるってやつね。
それは、ある意味「置き換えられてる」からだよ！Web開発みたいに業界が5年ごとに倍増してた時期は、数学的に言って平均的な開発者の経験年数は5年以下になるんだ。ベテランも最終的には10年、15年の経験を積むけど、急増する新人たちの数に圧倒されちゃうんだよね。だからJavaScript界隈のあらゆるものが幼稚な態度や行動になっちゃうんだ。
＞正直、この記事全体がAIが書いたみたいで、綿密な分析って感じじゃないよね。
発見されてからまだ数時間だよ？発表する代わりに分析に時間をかけるとでも？それに最近はほとんどの人がAIでコンテンツを編集してるでしょ。だから人間が書いてないってことにはならないよ。
npm ciはCI環境でずっと速いはずだよ。lockfileから正確な依存関係のバージョンを直接インストールできるから、依存関係解決アルゴリズム全体を通す必要がないんだ。CI環境では、毎回クリーンな状態から始めるべきだから、既存のnode_modulesディレクトリを削除するのを待つ必要もないしね。
数年前、似たようなことやったNFTのコントラクト攻撃について読んだ記憶があるな。だから今もあるのは確かだと思うよ。
アルゴリズムがどの色を選んでも、背景と前景が可能な限り多くの人にとても区別できるなら問題ないよ。prev/nextもたいてい区別できるだろうし。色覚異常のタイプとその発生率を考慮した賢い色の計算をするための柔軟性がそこにはたくさんあるんだ。
ウェブ開発界は「これで十分」って思想があったけど、さらに悪い状況になってるよね。
ハッシュコントラストはデフォルトで最大にすべきで、もし低い方が良ければ自分で設定を変えればいいって話。セキュリティ意識が高い人は自分で調整するだろうから、この機能はそういう人向けじゃないってこと。
no-color.orgを支持するよ。ChalkがFORCE_COLOR=0なんて、独自の道を突き進んでるのが信じられない。GitHubのissueでその対応を見つけたんだけど、「文句言うな」みたいな態度で最悪だよ。
詳細はこちら: https://github.com/chalk/chalk/issues/547#issuecomment-11268...
関連issue: https://github.com/chalk/chalk/issues?q=is%3Aissue%20NO_COLO...
またこの手の話か。以前Nxの件でも言ったけど、こういうのは防げたはずなんだ。これはソフトウェア業界全体の失敗だよ。サプライチェーン攻撃の影響はデカいんだから、コード署名や2FAとかの基本的なセキュリティ対策は全てのパッケージングプラットフォームで必須にすべき。AIの進化でこれからもっと悪くなるぞ。
週に何千回もダウンロードされるようなパッケージは、リリース速度が速すぎるんじゃない？NPMに新しいバージョンがアップロードされたら、すぐに公開じゃなくて、メンテナーに通知して「○月×日に公開されますがキャンセルしますか？」みたいな猶予期間を設けるべきだと思うんだ。
もっとコメントを表示（2）
Linuxディストリビューションのパッケージリリースプロセスって、新バージョン提出→メンテナー承認→不安定版→テスト版→安定版って流れがあるじゃん？だからタイポスクワッティングなんて起きにくいんだ。でもプログラミング言語のパッケージマネージャーは、野良パッケージを無審査で公開してるから問題なんだよ。これはLinuxディストリビューションでは考えられないことだね。もちろんLinuxもサプライチェーン攻撃に無縁じゃないけど、対策は自動化できるし簡単だよ。
この問題は昔から解決済みだったのに、開発者がセキュリティや信頼性を面倒くさがって無視してきた結果だよね。でも、もうすぐ収まるんじゃないかな。俺が知ってる多くの会社が、NPM/NodeとかComposerから離れ始めてるよ。エコシステムがリスク高すぎだってね。
Arch Linuxユーザーのみんな、AURも無法地帯だから気をつけろよ。
セキュリティ対策にはトレードオフがあるよ。例えばヒューリスティクスやアッテステーションみたいな制御は、自動化システムとか多くの一般的なソフトウェアを排除しちゃう可能性があるんだ。「Linuxユーザーかどうか」とか「Firefoxを使ってるか」みたいな単純なヒューリスティクスは馬鹿げてるけど、結構使われてるから問題。2FAもSMSは安全じゃないし、メールはフィッシングに繋がりやすい。TOTPはいいけど、これもフィッシングされる可能性はある。ハードウェア認証だけは安全だけど、NPMがそれを導入するのは難しいだろうね。
2FAはほとんどの状況でめちゃくちゃ効果的だと強く思うな。「新しいパッケージをアップロードしたことを確認する」みたいな機能がデフォルトであったらいいよね。NPMが、週にX回以上ダウンロードされるパッケージのリリース時に人間がCAPTCHAを使って承認する仕組みを義務付けるべきだと思う。これで攻撃をかなり難しくできるはずだよ。
2FAは普通のパスワードよりはるかに良いんだけど、今回もダメだったね。パッケージ開発者は2FAを設定してたのに、フィッシングページにログインさせられて、そこで2FAコードを本物のログインページにプロキシされちゃったんだ。
でも前のコメントで「公開前のアップロードごとに」って言ってたじゃん。もし「今アップロードしたパッケージを公開しますか？」ってメールがたくさん来たら、この攻撃は100%阻止されたはずだよ。(開発者の話を読むと、これがうまくいったって分かるはず)
これのもう一つの利点はCI/CD向けだね。MFAはCI/CDだと面倒だし。CIで公開トークンやOIDC認証を使ってアップロードした後、Web UIで手動承認が必要な形にできたら、かなりうまくいくと思うな。CIシステムの侵害リスクも減らせるし。「パッケージ公開済み」通知はもう手遅れだからね。
うん、まさにその通り。2FAや認証スキームの多くは自動化を壊しちゃうから、このシナリオでは本当に困るよね。難しい問題だよ。
開発者のアカウントが乗っ取られたと仮定したら、その公開ボタンもクリックできちゃうんじゃないの？
「誰かが標準のセキュリティ対策を実装すれば、こういう侵害は防げる」って言うけど、この一文はすごく多くのことを含んでるよね。「残りのフクロウを描け」と同じくらい難しい話だよ。
僕らはエンジニアだよ。アーティストがフクロウの残りを描けるのと同じように、毎日「どうせ無理」って諦めがちになってるこの分野に対して、できないって言うのはおかしいだろ。
フクロウの一部は消費者のアップグレード方法かもしれないね。最新パッチだけじゃなくて、良いバージョンと時期の二次情報源を活用して、脆弱性が発見される時間を稼いでからアップグレードする。多くの人がインストールする前に脆弱性を検出できると仮定すれば、いけるはず。あとは緊急のセキュリティ修正だけは例外にすればいい。
そんなに単純じゃないよ。どんなに厳重なセキュリティ対策をしても、結局は人間のミスでシステムは破られる。人間が一番の弱点だから、安全なシステムなんて存在しないんだ。npm内のプロセスは改善できるだろうけど、今回のフィッシング攻撃みたいなのは常に脆弱性になる。AIツールで攻撃が巧妙化するなら、僕らもAIを使って対抗するしかない。火には火で戦うのが唯一の賢い戦略だよ。
面白いね。https://www.wiz.io/blog/s1ngularity-supply-chain-attack によると、最初の侵入経路は「GitHub Actionsの欠陥ワークフローで、サニタイズされていないプルリクエストのタイトルからのコード注入を許していた」らしい。これは8月29日には検出されて緩和されたって。それから10日以上経つのに、昨日も主要なパッケージが侵害されたって？どういうことだろ？
みんなWindowsユーザーが多いからWindowsを狙うよね。でも、今やJavaScriptやPythonでプログラミングする人がもっと増えてるって言ったらどうかな？そう、これからはもっとひどくなるだけだよ。
NPMはここで非難されるべきだと俺は思うね。数え切れないほどのサードパーティのインテリジェンスやセキュリティスタートアップがこの悪意ある活動を検出できるのに、パッケージの唯一の真の情報源であるNPMは、あらゆるデータイベントやセキュリティシグナルにアクセスできるのに、この種の攻撃の犠牲になり続けるのを止められないって？もはや意図的な無知だよ。
NPMはGitHubが所有してるからMicrosoftのものだね。Microsoftは、ジェネレーティブAIを導入する理由がまったくないアプリにCopilotを組み込むのに忙しすぎなんだよ。
でもGitHubはセキュリティ関連でいろんなことやってるよね、侵害されたNPMパッケージの報告とかも。NPMが最近Microsoftに買収されたのは知らなかったけど、考えてみれば、Microsoftこそこのサプライチェーン攻撃の対策を真っ先にやるべきだよ。彼らは何十年もセキュリティ問題でひどい目に遭ってきたからね、特に90年代半ばから2000年代初頭にかけては、数億台のデバイスがインターネットに接続されたのに、OSがまだ対応できてなかったからさ。
Microsoft以前のNPMが、プロフェッショナルな管理やエンジニアリングの模範だったわけじゃないしね…
忘れてる人のために言うと、MicrosoftがNPMを買収したのは、NPM社が破綻寸前だったから、基本的にはコミュニティサービスだったんだよ。https://www.businessinsider.com/npm-ceo-bryan-bogensberger-r…
https://www.businessinsider.com/npm-cofounder-laurie-voss-re…
違いは利用できるリソースにあるよね。時間とお金なしには”プロフェッショナル”にはなれないし、買収後のNPMは、おそらく両方をもっと持ってるはず。認めざるを得ないのは、NPMには収益モデルと呼べるものがおそらくないから、Microsoftもあまり注意を払ってないんだろうってことだけどね。
おいおい。なんでもかんでもAIについての意見にする必要はないだろ。
GitHubはMicrosoftの”CoreAI”チームに組み込まれたんだって。あまり信頼できない話だね。
実際、パッケージの各更新が悪意があるか、難読化されてるかを見るのにAIを使えるだろうね。
