パッケージマネージャー界隈、ちょっと落ち着こうぜ。進化のスピードと複雑さに物申す

最近のパッケージマネージャーを取り巻くエコシステムは、あまりにも複雑化し、進化のスピードが速すぎる気がしませんか？新機能の追加やツール自体の肥大化に追われるよりも、今は一度立ち止まって、安定性やシンプルさを見直すべきタイミングかもしれません。

全員が7日経ってからしかパッケージを使わなくなったら、単に問題のあるパッケージが見つかるのが7日遅れるだけな気がする。7日という期間が機能しているのは、「一番手になりたくない」効果があるからだ（証拠はないけど断言する）。でも全員が同じように遅らせたら、自分だけ遅らせるメリットはもうなくなる。これは誰もアップグレードしなくなる囚人のジレンマみたいだよね。 クールダウン期間を設けること自体には意味があると思う。自動レビューシステムがアラートを出す時間を稼げるのはいいことだし。 各エコシステムの報告メカニズムがどうなっているかは詳しくないけど、「保留（hold）にすべき」と宣言するのは重大なことだし、実際に保留や削除を実行するのは、リポジトリのメンテナにとって非常に人的コストのかかる決断だ。かなりのラグも発生する。だから中央集権的だとしたら、少なくとも2日はかかるだろう。 理想を言えば、atprotocolみたいに、個人が自分のPDS上に危険を宣言するレコードを作成できる仕組みが欲しい。これなら評価システムを構築して、悪意のあるアクター（虚偽の報告）を抑制しつつ、ネット上の誰もが分散型でリアルタイムに迫りくる危険を素早く察知できるようになる。（僕を雇って。それ作るから。）

タイマーはアップロード時に始まるの？それとも大規模な悪用（exploitation）が始まった時？ 悪いアイデアじゃないけど、それを強制的かつ広範囲に適用するには、前者のケースの証拠が必要だよね。 記憶が確かなら、多くの場合、メンテナの認証情報の漏洩が原因で、それはすぐに発見される。だから前者の証拠はあると言えるんじゃないかな。

最新のアップデートを適用することと、サプライチェーン攻撃を避けることの微妙なバランスだよね。 著者の言いたいことはよくわかるよ。というのも、僕も最近は最新のCVEを追うことよりも、サプライチェーン攻撃を避ける方に傾いているから。 シスアドとしての25年の経験に基づいた直感でしかないし、実際のデータがあるわけじゃないけど、サプライチェーン攻撃はパッチが当たっていない既知の脆弱性よりも、一般的にずっと大きなダメージを与える可能性があると感じている。 言葉にするなら、サプライチェーン攻撃の方がターゲットが絞られていて、侵入の成功率が高い。一方でCVEが大規模に悪用されることは非常に稀で、悪用には多くの条件が伴うことが多いんだ。 それに今の世界情勢を考えると、サプライチェーン攻撃は国家レベルのアクターにとって、非常に価値の高い標的になっているみたいだしね。

Bunがpackage.jsonに trustedDependencies を追加して、それらの依存関係から来る postInstall スクリプトだけを実行するようにしたね。これはバージョンのクールダウン以上に、すべてのJSパッケージマネージャーでサポートされるべき機能だと思う。

どこかの有名なパッケージマネージャーで、僕らが仕事で変更をデプロイする時に使っているような段階的なロールアウト（staggered rollout）モデルを試したところはある？ 課題は当然、バージョンの互換性や不一致だけど、解決可能な問題だと思う。そうすれば自動のカナリアシステムを構築できるしね。 これに一番近いものといえば、オプトインの早期リリースチャンネルくらいかな。

この記事に .NET が含まれているのがちょっと面白いね。 最後に Dapper 以外に色々パッケージを入れたのは、.NET Framework 4.8 を使っていた頃かな。今の .NET は「Batteries included（標準機能が充実）」だからね。Dapper とあと2つくらいにクールダウンを設定すればある程度守られるかもしれないけど、サードパーティの依存関係が文字通り片手で数えられる程度なら、時間が経っても把握しきれなくなることはない。依存関係のアップグレードはめったに起きないから、ネオンサインみたいに目立つしね。シグナルとしての感度が高いから、アップグレードが起きた時に監査する時間はたっぷりあるよ。

最近、卒業論文のプロジェクトとしてこの問題に取り組んでいて、長期的にも続けていく予定なんだ。 基本的な前提は、NPMやPyPiなどの代替となるセキュアなパッケージレジストリで、リスクを最小限にするために色々な手法を組み合わせてる。例えば、再現可能なビルド、実行のトレースによるリリース版とソースコードの挙動の差異の特定、過去の挙動の異常検知、ベースラインとなる安全なパッケージとの比較とかね。それで、クライアント側のソフトをインストールする代わりに npm config set registry ... を実行するだけで済むようにしたい。 eBPFでネットワークリクエストやファイルアクセスみたいなハイレベルな挙動をトレースすれば、Shai Huludみたいな基本的な大規模サプライチェーン攻撃はキャッチできるはず。もっと難しいのは xz-utils みたいな巧妙なバックドアだね。これにはバージョンを跨いで再現可能なテストを実行して、正確な挙動をトレースする必要がある。 可能な限り自動化することで、多くのセキュリティ製品みたいに高価なエンタープライズ専用（これには本当に腹が立つ）じゃなくて、一般的に利用できるようにしたいと思ってる。ただ、誤検知は名誉毀損みたいなものだから、フラグが立ったものに対しては人間のレビュー層が絶対に必要だけどね。 これが正しい方向かどうかは完成して実際のケーススタディでベンチマークを取るまで分からないけど、少なくとも1つのスタートアップアクセラレーターが資金提供に興味を持ってくれているよ。

前にも書いたことがあるけど、前の職場では Artifactory を段階的にセットアップして、テストステージを通っていないものは本番でプルできず、CIを通っていないものはテスト環境でプルできないようにしていた。 リリース頻度が他の職場（継続的デプロイ）に比べて比較的ゆっくり（週次）だったから、サードパーティのパッケージが本番環境に入る前に脆弱性スキャンをする余裕が十分にあったんだ。 設定はすごくシンプルで、あるステージの成果物を次のステージのリポジトリにリンクするスクリプトがあるだけ。でも最終的な効果として、本番環境がインターネットから直接取得することはなくなり、前のステージにデプロイされていないパッケージをプルすることもなくなったよ。

これは「隠蔽によるセキュリティ（security through obscurity）」だね（つまり、セキュリティではないということ）。マルウェアはすでに多くの攻撃ベクトルで、何年も休眠状態で待ち構えている。パッケージマネージャーへの攻撃には、既知のシンプルな修正策がある。不完全なハックじゃなく、それらの修正を実装すべきだよ。

NetBSDのpkgsrcが普及しなかったのは本当に残念だね。いくつかのLinuxディストリビューションでも使えるし、Minixも使っていたと思う。 pkgin(1) を使えば、何かが実行される前に何が起こるかを確認できる。パッケージを作るのは大変だけど、エンドユーザーとして pkgsrc を使うと、実行前に何をするか示してくれるんだ。 このバイナリパッケージインストールの例は、稼働中の NetBSD ワークステーションのもの。インストールしたいパッケージに必要な項目がすべて表示されるよ。 \n\n \n # pkgin install gnumeric-1.12.59nb2\n calculating dependencies...done.\n\n 4 packages to install:\n gnumeric-1.12.59nb2 goffice0.10-0.10.59nb2 lasem-0.6.0nb1 libgsf-1.14.54\n\n 0 to remove, 0 to refresh, 0 to upgrade, 4 to install\n 16M to download, 76M of additional disk space will be used\n\n proceed ? [Y/n] n\n