From 62cd23d5adf30944811ccf2130e818c16e406f85 Mon Sep 17 00:00:00 2001 From: Matthew Elwell Date: Fri, 4 Sep 2026 17:58:18 +0100 Subject: [PATCH] chore(renovate): enable lock file maintenance Renovate raises security PRs from manifest entries, so a CVE in a package that appears only in a lock file is never actioned. That is the bulk of our exposure: of 95 findings currently open against flagsmith-ee, which shares these four lock files, 69 are transitive pins and only 26 are declared in a manifest. There is no longer a dedicated option for this. transitiveRemediation, which handled exactly this case, was npm@6-only and has been removed from Renovate; it is absent from the current schema. Refreshing the lock file within existing ranges is the only remaining mechanism that reaches transitive pins. security:only-security-updates disables everything via a blanket matchPackageNames ['*'] rule, so lock file maintenance needs an explicit packageRule to escape it. The top-level block alone silently no-ops. Measured against the real backlog before committing: - frontend/ + docs/ `npm update --package-lock-only` clears 38 of 53 npm findings. The rest are pinned by a parent or capped by a declared range, and need an override or a manifest bump. - mcp/ `uv lock --upgrade` clears both open findings. - api/ see #8469, which lands the first refresh along with the constraints that keep it reviewable. api/ needs no special handling for CodeArtifact. renovate.yml already mints a token over OIDC and passes it as RENOVATE_HOST_RULES; Renovate's uv processor reads [[tool.uv.index]] from pyproject.toml, matches the host rule, and exports UV_INDEX_FLAGSMITH_PYPI_PRODUCTION_{USERNAME,PASSWORD} for the uv subprocess - precisely what `make codeartifact-login` writes. That path is already exercised in production, since it is how Renovate resolves flagsmith-private versions for the eager-bump rule. Verified with `renovate --platform=local --dry-run=full` on renovate/renovate:44.62.2-full: four lock file maintenance candidates, none filtered, grouped into a single renovate/lock-file-maintenance branch. Config validates against renovate 44.64.0. Co-Authored-By: Claude Opus 5 --- renovate.json | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/renovate.json b/renovate.json index 1ead2d69e0ac..330f05c06836 100644 --- a/renovate.json +++ b/renovate.json @@ -4,7 +4,16 @@ "security:only-security-updates", ":semanticCommitTypeAll(deps)" ], + "lockFileMaintenance": { + "enabled": true, + "schedule": ["before 4am on monday"] + }, "packageRules": [ + { + "description": "Re-enable lock file maintenance, which security:only-security-updates disables via its blanket matchPackageNames ['*'] rule. Renovate raises security PRs from manifest entries, so a CVE in a package that appears only in a lock file is never actioned; refreshing the lock file within existing ranges is the only mechanism that reaches transitive pins.", + "matchUpdateTypes": ["lockFileMaintenance"], + "enabled": true + }, { "matchManagers": ["pep621"], "matchFileNames": ["api/**"],