npm install を、私たちはもう少し疑ったほうがいい
依存パッケージを入れる。
開発者なら1日に何度も繰り返す動作です。
この何気ないコマンドが、実はかなり無防備な入口になっている、最近そう感じる出来事が続いています。
今日は、私たちが依存関係とどう付き合うべきかを、あらためて考えてみます。
きっかけは、人気のnpmパッケージが乗っ取られ、npm install しただけで認証情報が盗まれる攻撃が報告されたことです。
しかも仕込まれたコードは、インストールの最中に勝手に走ります。
「実行しなければ安全」という思い込みは、もう通用しません。
「入れただけ」で動く、という前提に立つ
多くの人は、悪意あるコードは自分が呼び出して初めて動くと考えています。
ですが実際には、パッケージのインストール時に自動で走る仕組みがいくつもあります。
ビルド設定ファイルや、インストール時フック。
攻撃者はこうした「正規の仕組み」に相乗りしてきます。
つまり、怪しいコードを実行した覚えがなくても、npm install を打った時点で被害が始まりうる。
この前提に立つだけで、身構え方が変わります。
盗まれるものは、想像より広い
一度侵入を許すと、狙われる範囲は驚くほど広いです。
GitHubやクラウド各社のトークン、SSHの秘密鍵、.envに書いた設定、
シェルの履歴に至るまで、開発機やCIには便利さのためにあらゆる鍵を置きがちで、
その便利さがそっくりそのまま被害の広さに直結します。
ここで一度、自分の手元を見直したくなります。
このマシンに、いくつのクラウドの鍵が平文で置いてあるだろうか。
そのうち、いま本当に必要なものはどれだろうか、と。
「新しい」は、必ずしも「安全」ではない
やっかいなのは、正規の署名や来歴証明が付いていても油断できない点です。
ビルドの仕組みそのものが乗っ取られれば、証明書は本物のまま、中身だけがすり替わります。
「公式が出した最新版だから安心」とは、単純には言えなくなっています。
私たちの現場で意識したいのは、更新のスピードです。
公開された直後の版に飛びつくほど、こうした攻撃を踏むリスクは上がります。
数日待つだけでも、多くのケースは避けられます。
明日からできる、小さな備え
大げさな仕組みを入れなくても、リスクは下げられます。
私たちが実践しようとしているのは、次のような地味な習慣です。
- CIやローカルでの
npm installは、インストール時スクリプトを無効化する（--ignore-scripts）ことをまず検討する
- 依存の更新は最新版に即飛びつかず、公開直後の版は少し寝かせる
- 開発機やCIに置く認証情報は、必要な分だけに絞る。権限も最小限にする
- 署名や来歴証明は「あれば安心」ではなく、判断材料の一つとして扱う
どれも派手さはありませんが、npm install という毎日の動作の裏で何が起こりうるかを一度知っておくと、こうした小さな備えの意味が変わって見えてきます。
便利なツールを一つ入れる。
その手軽さの裏側に、少しだけ想像力を働かせておきたいところです。
