依存パッケージ — 自分が書いていないコードが、本番で動く

What — 入れた数と、動く数は違う

package.json に書く依存は「直接の依存」です。その各々にも依存があり、その依存にも依存があります（推移的な依存）。

直接の依存         40 個   ← 自分で選んだ
実際に入るもの    900 個   ← 選んでいない。全部が本番で動く

選んでいない 860 個も、自分のコードと同じ権限で動きます。ファイルを読み、ネットワークに出て、環境変数を読めます。「そのパッケージを信頼するか」は、その作者を信頼するかであり、さらにその作者が依存している人たちを信頼するかでもあります。

推移的な依存

自分が入れた依存が、さらに依存しているパッケージ。数はこちらのほうが桁違いに多い。

lockfile

実際に入れたバージョンを固定して記録するファイル。package-lock.json など。

インストール時スクリプト

パッケージのインストール中に実行されるコマンド。postinstall など。

セマンティックバージョニング

メジャー・マイナー・パッチで互換性を表す約束。守るかどうかは作者しだい。

範囲指定と lockfile

^1.4.0 は「1.x.x の範囲で、新しいものを使ってよい」という指定です。便利さと引き換えに、何が入るかを毎回ゆだねています。

"date-lib": "^1.4.0" → npm install

Why — なぜ「使っていないコード」から漏れるのか

冒頭の事故で、そのユーティリティの機能は一度も呼ばれていません。それでも資格情報は漏れました。

インストールの時点で、コードが実行されるからです。

多くのパッケージ管理の仕組みには、インストール中に任意のコマンドを走らせる機能があります（postinstall など）。ネイティブのビルドや初期設定のための正当な機能ですが、任意のコマンドである以上、何でもできます。

npm ci
  → 依存を展開
  → 各パッケージの postinstall を実行   ← ここ。自分のコードは1行も動いていない
  → 完了

そして CI の環境には、たいてい強い権限があります。デプロイ用の資格情報、レジストリのトークン、署名鍵。開発者の手元の端末にも、クラウドの認証情報があります。

気づきにくい理由

このたぐいの事故は、動作としては何も壊れません。テストは通り、ビルドも通り、アプリも正常に動きます。壊れないので、CI の結果からは何も分かりません。

気づく経路は限られます。

• 請求やリソースの異常（冒頭はこれ。4日後）
• 依存の脆弱性を知らせる仕組み（公表されてから）
• 通信の監視（普段と違う送信先）

「壊れないこと」を前提に備えるのが、この領域の考え方です。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。