RenovateのlockFileMaintenanceの利用シーン
Renovateを導入してパッケージを更新しても、GitHubの脆弱性検知数が減少しないことがあります。これは、リポジトリの脆弱性検知が間接的にインストールされるパッケージも対象とする一方で、デフォルトのRenovateの挙動では間接依存のパッケージを対象にしないためです。この記事ではRenovateで間接依存パッケージ更新も行うオプションを紹介します。
lockFileMaintenanceの説明
RenovateにはlockFileMaintenanceという一見わかりづらい機能があります。ドキュメントには以下の説明があります。
When Renovate performs lockFileMaintenance it deletes the lock file and runs the relevant package manager. That package manager creates a new lock file, where all dependency versions are updated to the latest version.
簡単にいうとpackage-lock.jsonなど、パッケージマネージャーのロックファイルを削除して、npm installなどでロックファイルを再作成する機能です。Renovateはさまざまなパッケージマネージャーとそのロックファイルに対応していますが、この記事では代表例としてnpmを例にします。
Renovateパッケージ更新とlockFileMaintenanceによるロックファイル更新の違い
通常のパッケージ更新の際はRenovateはpackage.jsonを更新し、npm installなどを実行するので、package-lock.jsonの更新は最小限です。
例えばpackage-Aパッケージの1.0.1をインストールするとします。そしてpackage-Aはpackage-Bの2.0.*へ依存しているとします。そしてpackage-lock.jsonでは、package-Aの1.0.1と依存パッケージのpackage-Bの2.0.2が記述されています。
その後、package-Bの2.0.3がリリースされてもpackage.jsonに記述されない依存パッケージなので、Renovateは更新を検知しません。そのため、間接依存パッケージに脆弱性が発見されても更新が取り残されるリスクがあります。
さらにpackage-Aが更新されても、package-Aが指定する依存関係のバージョン指定が変わらなければ、package-Bは更新されません。
ここでpackage-Bを更新するのがlockFileMaintenanceです。先述の通り、ロックファイルを削除して再度npm installなどを実行するので、その時点で依存関係を満たす最新のpackage-Bが導入されます。通常のRenovate PRと異なり、package.jsonは変更しないので、package-Aの更新はpackage.jsonで指定されたバージョンの範囲内で行われます。
lockFileMaintenanceはminimumReleaseAgeを利用しない
OSSサプライチェーン攻撃対策として、RenovateのminimumReleaseAgeをオプションで、リリース直後のパッケージを一時保留することがあります。しかしlockFileMaintenanceはminimumReleaseAgeパラメータを利用しないので、リリース直後のパッケージでもインストールされてしまいます。Renovateは内部的にnpmを実行しているので、npm側で保留期間を設定する必要があります。npmなら11.10.0でmin-release-ageが実装されています。
min-release-ageでnpm更新を5日待機させたい場合、.npmrcファイルに以下の記述を行います。
min-release-age=5
RenovateのminimumReleaseAgeパラメータはRenovateのPR作成を待機させるために引き続き必要です。min-release-ageのみだとRenovateはPR作成を試みてしまいます。npmエラーでPR作成は失敗しますが、無駄な処理が発生するため両方設定しましょう。
lockFileMaintenanceがminimumReleaseAgeを使わない仕様については、RenovateリポジトリのDiscussionでも提起されています。
minimumReleaseAge is not working with lockFileMaintenance and transitive Dependencies
lockFileMaintenanceの運用
実行スケジュール
lockFileMaintenanceは、PRが何度も生えてきてノイズにならないよう、標準では毎週月曜日の午前0-4時台のみPRが作成されます。scheduleパラメータを使えば時間帯を変更できます。
対応ロックファイル
2026/04/23現在、以下のロックファイルに対応しています。
| Manager | Lockfile |
|---|---|
| bazel-module | MODULE.bazel.lock |
| bazelisk | MODULE.bazel.lock |
| bun | bun.lockb, bun.lock |
| bundler | Gemfile.lock |
| cargo | Cargo.lock |
| composer | composer.lock |
| conan | conan.lock |
| devbox | devbox.lock |
| gleam | manifest.toml |
| gradle | gradle.lockfile |
| helmfile | helmfile.lock |
| helmv3 | Chart.lock |
| jsonnet-bundler | jsonnetfile.lock.json |
| mix | mix.lock |
| nix | flake.lock |
| npm | package-lock.json, pnpm-lock.yaml, yarn.lock |
| nuget | packages.lock.json |
| pep621 | pdm.lock, uv.lock |
| pip-compile | requirements.txt |
| pipenv | Pipfile.lock |
| pixi | pixi.lock |
| poetry | poetry.lock |
| pub | pubspec.lock |
| terraform | .terraform.lock.hcl |
| terragrunt | .terraform.lock.hcl |
| vendir | vendir.lock.yml |
CIと自動マージ対応
ロックファイルは人間が読むことを想定していないので、人間が差分を判断するのは困難です。実際GitHubでもロックファイルの差分はデフォルトで非表示になります。人間がPRをレビューする運用にしても、レビューしきれずにPRを滞留させてしまうリスクが高いです。そのためCIでテストが全て通ったら自動マージする運用が現実的でしょう。下記のようにautomerge: trueオプションを設定すると自動マージ対象になります。
{
lockFileMaintenance: {
enabled: true,
automerge: true,
},
}
直接指定するパッケージの更新は意識しても、ロックファイル内部で指定されているパッケージの更新は漏れがちです。lockFileMaintenanceを利用して、漏らさずに更新していきましょう。
担当：松浦
