脆弱性スキャナが緑でも本番は古いことがある｜lockと実体がずれる原因と確認方法

依存の更新作業では、ロックファイルを見て、脆弱性スキャナを流して、どちらも問題なければ完了と判断するのが普通です。この判断はほとんどの場合は正しく、ある条件のときだけ静かに外れます。

外れるのは、ロックを通らない経路で何かが入っているときです。この記事では、その状態を手元で作って、各ツールが何と答えるかを測った結果をまとめます。

再現する

環境は Node.js 22.22.0 / npm 10.2.4 です。まず、ふつうに新しい版をインストールします。

npm install

この時点ではロックも実体も同じです。次に、ロックを使わずに古い版を入れる1行を足します。コンテナイメージのビルドで実際に書かれることがある形です。

npm install --no-package-lock sharp@0.35.1

この2つを実行した後の状態を、それぞれ別の方法で確認しました。

ロックとスキャナだけを見ていたら、この状態は「対応済み」に見えます。実際に読み込まれるのは 0.35.1 の方です。

実体を直接確認するには、置かれたファイルの情報を読みます。

node -e "console.log(require('./node_modules/sharp/package.json').version)"

なぜスキャナは気づかないのか

判定の材料が宣言の側だからです。npm の公式ドキュメントは npm audit を「プロジェクトに設定された依存の内容をレジストリへ送り、既知の脆弱性の報告を求める」コマンドだと説明しています。送るのは依存ツリーの名前とバージョンの一覧であって、ディスクに置かれたファイルそのものではありません。

上の再現はそれと一致しました。ロックには 0.35.4 と書いてあり、置かれているのは 0.35.1 で、答えは0件。実体は判定に使われていないことが、結果からはっきり分かります。

これは不具合ではありません。宣言を基準にするのは設計として自然で、しかも速いという利点があります。問題は、宣言と実体がずれうることを忘れて運用する側にあります。

ずれを作る3つの原因

2つ目についてはoverridesが上流のセキュリティ修正を打ち消す仕組みで詳しく測っています。3つ目は、除外の判断が正しいかを成果物の中身で確かめないと分かりません。

いずれも共通しているのは、紙の上の情報（ロック・依存の一覧・スキャナの出力）だけでは決着しないということです。

ロックを迂回する1行には理由がある

念のため書いておくと、この1行が書かれるのには理由があることが多いです。特定の構成では依存が正しく追跡されず、明示的に入れておかないと、エラーも出さずに機能だけが静かに落ちることがあります。そのために置かれた回避策であれば、構造としては正しく、古くなっているのはピンで留めた版だけです。

なので対応は「その1行を消す」ではありません。

確認コマンド自体にも盲点がある

実体を見ればよい、と書きました。ただしその確認方法にも同じ種類の落とし穴があります。

パッケージマネージャーによって、ファイルが置かれる場所の形が違います。実際に測ると次のようになりました。

つまり node_modules の直下を決め打ちで見る確認コマンドは、pnpm で間接依存のとき「入っていない」と答えます。実際には入っているのにです。

# 決め打ちしない。置かれている場所を探してから読む
find . -path "*node_modules/*/package.json" -path "*sharp*"

「スキャナが実体を見ていない」と指摘しながら、自分の確認コマンドが同じ形で実体を見落とす。これは実際に起きやすい失敗です。確認する側のコマンドも、パスを固定しない形にしておきます。

完了判定の置き場所を変える

ここまでをまとめると、依存の更新で「終わった」と言えるのは次のときです。

3番目だけが、ロックを迂回した経路も拾えます。1と2は必要ですが十分ではありません。

コンテナで動かしているなら、動いているコンテナの中で版を読みます。

# 動いているコンテナの中で、実際に置かれている版を読む
docker exec コンテナ名 node -e "console.log(require('sharp/package.json').version)"

確認した結果はどこかに残します。「確認した」と「確認しろと指示した」は別物なので、同じ場所に書くと区別がつかなくなります。

よくある質問

スキャナを使う意味がないということですか

逆です。ロックを基準にした検査は速くて確実なので、常時回す価値があります。言いたいのは役割の範囲です。スキャナは宣言の健全性を保証し、実体の一致までは保証しません。両方を別々に確認すれば、それぞれが得意な範囲をきちんと埋められます。

ロックが正しければ実体も正しくなるのでは

再インストールすれば一致します。問題は再インストールされない場所です。作り終えたコンテナイメージの中身は、次にビルドし直すまで固定されます。ロックを直しても、動いているものは古いままです。だから「直した」ではなく「入れ替わった」を確認の対象にします。

ロックファイルを消して作り直せば解決しますか

ずれの原因がロック側にあるなら有効ですが、今回の形では解決しません。迂回している1行はロックを参照していないので、ロックを作り直しても同じ結果になります。原因がロックの中にあるのか外にあるのかを先に切り分けてください。切り分けの方法は、実体とロックを両方読んで食い違うかを見るだけです。

確認はどのくらいの頻度でやるべきですか

更新作業のたびに、その対象についてだけ実施するのが現実的です。全部を毎回確認するのは続きません。ただし深刻度の高い勧告に対応したときだけは、対象を広げて全数で確認する価値があります。1件でも取りこぼすと対応そのものの意味が薄れるためです。

まとめ

ロックが新しく、スキャナが0件でも、実際に動いているものが古いことがあります。

• 脆弱性スキャナはロックを基準にしており、実体は見ていない（実測で確認）
• ロックを迂回して入れたものは、スキャナの視界に入らない
• 迂回する1行には理由があることが多い。消すのではなく、更新の網から外れる前提で扱う
• 実体を見る確認コマンドにも盲点がある。パスを決め打ちしない
• 完了の判定は「今動いているものを開いたか」に置く

依存の更新は、宣言を直す作業だと思われがちです。実際には宣言を直したうえで、実体が入れ替わったことまで見届ける作業です。この2段目を手順に入れておくと、静かにすり抜ける種類の見落としがなくなります。

参考リンク

• sharp の脆弱性勧告 GHSA-rgj7-g3m4-5g8c（GitHub Advisory）
• npm audit のリファレンス（npm 公式）
• overridesが上流のセキュリティ修正を打ち消す
• ロックファイルとは
• Docker本番運用でよくある事故と確認チェックリスト