プロジェクトの作者たちは、自分たちのプロジェクトにどんなライブラリが必要かすら分かってないと思う。多くは間接依存関係だからね。サプライチェーン攻撃について、そのライブラリを確認した可能性はゼロだよ。だから、依存関係をプロジェクトにバンドルするんじゃなくて、ユーザーが直接npmからインストールする方がいい理由だよね。

理由があるんだ。これまでの一般的な考え方は「車輪を再発明するな」ってこと、またはHN以外の言い方で「それ用のアプリがある」ってことだよね。みんなが自分で暗号を作るべきだとは全く思わないけど、それとフォントの色を選ぶライブラリの間には健全な中間点があるはずだよ。

ほとんどのパッケージマネージャーはこれをやってるよ。すべてのパッケージを検査してたら、仕事が進まないからね。renovateやdependabotのようなサービスは、js開発者にとってコストなしでこの作業をしてくれるし、多分もっと上手くやってるよ。

これってmavenやpython、rubyのプロジェクトにも同じことが言えるんじゃない？ウェブだけの問題とは思えないな。

それとも、もっと悪いのは「sudo curl URL | bash」かな。

これは、ピアレビューやキュレーションなしでパッケージを公開することの重要な脆弱性だね。無制限で即時に誰でも公開できるのを許すんじゃなくて、もっと多くの自動化された行動コードカバレッジ分析と人間のレビュアーが必要だよ。

彼らがそのライブラリをサプライチェーン攻撃についてチェックした可能性はゼロだよ。たとえチェックしたとしても、プロジェクトがすべての依存関係をgitハッシュに固定していない限り、1つの更新で全てが台無しになるからね。だからDependabotみたいなのは素晴らしいんだ。

ほとんどは、良いSASTツールとプロセスで管理できるよ。

Rustもそんな感じだよね。Rustプロジェクトを開くたびにCargo.lockを見て、何百もの再帰的な依存関係があるのを見て、マジで頭おかしくなる。従来のCやC++プロジェクトと比べると、もう狂気の沙汰だよ。

だからこそ、ソフトウェアを書くときは外部パッケージを使わないようにしてるんだ。例えば、最近Pythonで天気観測データをローカルデータベースに同期するツールを書いたんだけど、[1] Pythonの標準ライブラリを使ってダウンロードを管理するのにちょっとだけ手間がかかったけど、Requestsみたいな外部パッケージを使うよりも、Pythonに付属しているもの以外の依存関係がなくなったんだ。隠れた依存関係の木がいつかトロイの木馬を抱えるかもしれない心配をしなくて済むのは、心の平穏が得られていいよね。[1] https://github.com/tmoertel/tempest-personal-weather [2] https://pypi.org/project/requests/

彼らはバックリンクやSEOスパムを注入して、給料日ローンやオンライン薬局、カジノなんかを宣伝してるんだ。30,000のリンクを一度に自分のウェブサイトに集められるなんて想像してみて。Googleはそのページをすごく高くランク付けするよ。ジェネリックや無許可のカジノを売ってる薬局は、1日に何万ドルも稼げるからね。だから、一週間でもかなりの金額を稼げるんだ。

彼らは他のサイトへのバックリンクを追加してるんだ。そうやって収益を得ているか、あるいは（もっと可能性が高いのは）不正な商品へのバックリンクを売っているんだろうね。

よく、検索エンジンにインデックスされる存在しないページを何千も生成して、Aliexpressのページや他のアフィリエイトリンクサイトに人をリダイレクトさせちゃうんだよね。

npmの代替として、すごく面白いプラットフォームになりそうだね。WordPressのエコシステムよりもインセンティブがちょっとはマシかもしれないけど、まだ足りないかも。

大多数のリポジトリがSEOフック付きのマルウェアだと仮定した場合、同僚からの密かなヒントなどを使わずに、どうやって安全なディレクトリを見つけるんだろう？リポジトリの増加がユーザーにとってどう改善されるのか、全然見えないよ。（確かに、規制からの自由を夢見せてくれるのは間違いないけど、使いやすさの観点からは価値が中立的だよね。）

諦めなかったよ！プロジェクトの技術的な部分にもっと焦点を当てて、他のエコシステムにも広げる方向にシフトしたんだ。今はTypo3コミュニティと協力してFAIRを持っていこうとしてるし、さらに広げていく予定だよ。（AMA、私は共同議長で、コアプロトコルの多くを書いたよ。）

これだけのリスクがあるから、彼らはあなたのソフトウェアの依存関係を買ったり、あなたの社員の一人に「間違い」を犯させるために退職金を渡したりできるんだ。LAPSUS$は、管理者アクセスを持つ社員を賄賂で引き込むことで非常に活発だったよ。これは理論上の話じゃない。普通の国家が内部アクセスを持つ誰かを賄賂するためにどれだけのお金を持っているか、想像してみて。

うん、同意するな。私にとってMythosの主なリスクは、悪いことをより早くできるようになることでの飽和だと思う。脆弱性は見つかって修正される、それが現実。でも問題なのは、脆弱性を特定して優先順位をつけること。誤った分類や誤認識があると、脆弱性の攻撃ウィンドウが長くなる可能性がある。もしクラウドプロバイダーや複数のクラウドプロバイダーが何かに対してオープンなら、みんなが危険にさらされる。これは私が今いる場所でのかなり大きな悪夢のシナリオだよ。

それにはFreeBSDのエクスプロイトを書く能力なんて必要ないんだ。確かにそれはいい指摘だね。最近、Registerに「コスト・ベネフィット・リスク分析のためにサプライチェーンを研究するのが、彼らの運営方法の一つになってきている」という記事があったよ。合理的なら、そうする理由があるよね（もちろん、その前提は議論の余地があるけど）。

「それはEthereumのスマートコントラクトを通じてC2ドメインを解決し、公開ブロックチェーンのRPCエンドポイントをクエリしています。従来のドメイン削除は機能しません。なぜなら、攻撃者はいつでもスマートコントラクトを更新して新しいドメインを指すことができるからです。」ってことは、ファイアウォールは今後すべてのEthereumエンドポイントをブロックしなきゃいけないの？

既存の方法で人がハッキングされる可能性があるからって、新しいハッキングの方法を無視する理由にはならないよね。

まあ、暗号通貨はその新しい時代の一部だよね。単に問題を悪化させるだけじゃなくて、トレードオフを伴う技術なんだ。もう猫は袋から出ちゃったし、これからも残る技術に合わせてデザインしていかなきゃいけないよ。分散型の暗号技術に基づく通貨やトークンは、その一つだね。