依存関係の固定は実務でどこまで効くか：lockfile が守るもの、守らないもの

過度に信頼されている仕組み

「lockfile を使っているので依存関係は固定されています」。この一文はセキュリティ審査で頻繁に登場し、たいてい議論を終わらせる答えとして扱われます。

lockfile は確かに重要です。しかしそれが解決するのはビルドの一貫性です。今日のビルドと 3 か月後のビルドが、まったく同じ依存ツリーを取得するようにすること。そこから「依存関係が安全である」までの間には、いくつも別の問題が挟まっています。

lockfile が防げるもの

バージョンの漂流。 lockfile がない場合、^1.2.0 のようなセマンティックバージョンの範囲は、インストールのたびに最新の互換バージョンへ解決されます。開発者どうし、あるいは開発環境と CI で、異なるコードが入る可能性があるということです。lockfile はこの不確実性を取り除きます。

間接依存の予期しない変化。 直接依存は変えていないのに、その推移的依存が新版を公開した——lockfile がなければ、これは静かにビルドへ入り込みます。この種の変化は「昨日までは動いていた」障害の主要因の一つです。

一部の汚染シナリオ。 攻撃者が新しい悪性バージョンを公開する形で汚染する場合（最も一般的な手口の一つです）、古いバージョンに固定されたプロジェクトは自動的には影響を受けません。これは lockfile が提供する実際のセキュリティ価値です。ただし受動的で、条件つきのものです。

lockfile が防げないもの

すでに固定されている脆弱性。 最も直接的な点です。固定したそのバージョン自体に脆弱性があれば、lockfile は忠実に、再現可能に、毎回その脆弱性を導入します。固定は安全と同義ではなく、一貫性と同義です。さらに悪いことに、lockfile があると気づきにくくなります。バージョン変化という確認の契機がなくなるからです。

導入時点で悪性だったパッケージ。 lockfile が固定するのは、すでに使うと決めたものです。導入の判断そのものが誤っていた場合——タイポスクワッティングのパッケージ、AI が生成した実在しないパッケージ名——lockfile はその誤りを固めるだけです。

同一バージョン内での内容の差し替え。 多くの生態系では lockfile に完全性のハッシュが記録されます（npm の integrity フィールドなど）。これは改竄を防ぎます。しかし lockfile がすでに汚染された環境で生成されていたり、ハッシュ自体が悪性の内容から計算されていれば、固定は意味を失います。信頼の連鎖の起点が清潔でなければなりません。

依存ツリーの外側にある攻撃面。 ビルドスクリプト、CI の設定、レジストリのミラー、コンパイラそのもの。lockfile はこれらに一切関与しません。SolarWinds 型のビルド工程への攻撃は、依存ツリーに触れる必要すらありません。

古びること自体のリスク。 皮肉なことに、lockfile をうまく使うほど新しい問題が生じます。依存関係が長期間更新されず、セキュリティ修正が届かなくなるのです。固定と更新は両極から一つを選ぶものではなく、均衡させるべきものです。

あわせて必要な実務

1. 固定と継続的なスキャンは切り離せません。

lockfile は正確な依存関係の一覧を提供します。これは継続的な脆弱性照合にとって理想的な入力です。lockfile を SCA のスキャン対象とすれば、新しい脆弱性情報が届いたときに「自社は影響を受けるか」に即座に答えられます。固定の価値は監視と組み合わせて初めて完全に実現します。そうでなければ、リスクをその場に固めているだけです。

2. lockfile の変更をコードレビューに載せます。

lockfile の変更はすべて、依存ツリーが変わったことを意味します。これはビルド時の副産物ではなく、人の目に触れる明示的な判断であるべきです。レビューで問うべきことは、誰が導入したか、なぜか、推移的依存として何が入ってきたかです。

3. 段階的な更新方針。

パッチ版は自動更新（セキュリティ修正は通常この階層に来ます）、マイナーはテスト通過後、メジャーは必ず人が評価します。Dependabot や Renovate と組み合わせれば、更新は年に一度の大掃除ではなく日常の小刻みな歩みになります。

4. 内部ミラーと完全性検証。

すべての依存関係を内部の成果物レジストリ経由で取得し、lockfile の完全性ハッシュと組み合わせることで、「内容が確定していて、出所が統制されている」という二重の保証になります。これは依存混同攻撃への対策も兼ねます。

5. 開発依存と実行時依存を区別します。

lockfile には通常両方が含まれますが、リスクの性質は異なります。実行時依存は本番の攻撃面に直接入り、開発依存はビルド環境に影響します。更新頻度と審査の強度を分けて設定すれば、限られた注意をより重要な側へ向けられます。

期待値を正しく設定する

lockfile は再現可能ビルドの基盤であり、依存関係管理の必要条件です。しかし十分条件ではありません。これを「セキュリティの道具」ではなく「決定性の道具」として理解すれば、本当に足りていない部分——継続的な脆弱性監視、明示的な導入判断、そしてビルド環境そのものの保護——を自然に補いにいけるはずです。

一文にまとめるなら、lockfile は毎回同じものが入ることを保証し、そのものに問題があるかどうかを教えるのは SCA です。

---

関連記事：CI パイプラインでの SCA ゲート設定 · npm 悪性パッケージの 4 つの隠蔽手法 · OSS・SBOM 実践ガイドの依存関係管理項目