Renovate self-hosted : automatiser les mises à jour de dépendances

Les CVE qui dorment dans les package.json, requirements.txt, go.mod ou Dockerfile ne se patchent pas toutes seules. Sur 50 repos d'une équipe, le suivi manuel des versions est un travail à temps plein qui personne ne fait. Résultat : les libs accumulent du retard, les CVE s'empilent, la dette technique s'aggrave.

Dependabot (GitHub) et Renovate (Mend, anciennement WhiteSource) automatisent le job. Ouvrir une PR par mise à jour, avec changelog, tests CI, merge automatique sur les patches, escalade sur les majors. Renovate, plus configurable que Dependabot et compatible GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, est devenu le standard côté self-hosted.

Pour une équipe qui veut rester en avance sur les CVE sans perdre de capacité dev, Renovate self-hosted est l'outil. Pas un confort optionnel.

• Renovate vs Dependabot : ce qui les distingue
• Architecture : runner, configuration, presets
• Déploiement self-hosted GitLab et GitHub
• Configuration de base et patterns courants
• Auto-merge, escalade, scheduling
• Sécurité : secrets, supply chain, vetting
• Gouvernance et adoption équipe
• Pièges et limites

Dependabot est le natif GitHub. Activable en deux clics, intégration native PR, alertes vulnerabilities incluses, gratuit. Limites : configuration moins fine, pas de support multi-plateforme (lié à GitHub), pas de "presets" partageables entre orgs.

Renovate est l'option configurable et plate-forme-agnostique. Forks supportés : GitHub, GitLab self-managed et SaaS, Bitbucket, Azure DevOps, Gitea, Forgejo. Configuration JSON5 ou YAML très expressive, presets partageables, dashboard d'état, batch automatique, support de 90+ gestionnaires de packages.

Pour une organisation avec un GitLab CE en docker compose ou un Forgejo/Gitea, Renovate est le seul choix. Pour du GitHub pur, Dependabot suffit pour les besoins simples ; Renovate s'impose dès qu'on veut de la finesse.

Renovate fonctionne en mode "scan + propose". Cycle :

1. Renovate cron (ou trigger event) clone tous les repos cibles.
2. Pour chaque repo, lit les manifestes (package.json, requirements.txt, Dockerfile, helm charts, etc.).
3. Pour chaque dépendance, vérifie les versions disponibles upstream (registry npm, PyPI, Docker Hub, etc.).
4. Si nouvelle version conforme aux règles, ouvre une PR / MR avec le bump.
5. Met à jour le "Dependency Dashboard" issue dans le repo (vue d'ensemble).

Composants :

• Renovate runner : binaire Node.js (renovate npm package) ou image Docker.
• Configuration : renovate.json ou .gitlab/renovate.json5 au root du repo, ou config globale via config.js.
• Token : token API GitLab/GitHub avec scopes api ou repo, gardé en variable d'env.
• Presets : configurations partagées (par exemple config:base, :semanticCommits). Importables via extends.

Sur GitLab CE/EE, le pattern recommandé est un job CI scheduled qui exécute Renovate runner.

Repo dédié infra/renovate-runner avec ce .gitlab-ci.yml :

include:
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-config-validator.gitlab-ci.yml'
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-dind.gitlab-ci.yml'

variables:
  RENOVATE_TOKEN: $RENOVATE_TOKEN # PAT avec scope api
  RENOVATE_AUTODISCOVER: 'true'
  RENOVATE_AUTODISCOVER_FILTER: 'mygroup/**'
  GITHUB_COM_TOKEN: $GITHUB_COM_TOKEN # pour fetch changelogs

renovate-schedule:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Schedule pipeline GitLab : toutes les 4h ou 2x par jour selon le volume.

Sur GitHub, utiliser l'app officielle Mend Renovate (managé) ou self-host via GitHub Actions sur cron.

# .github/workflows/renovate.yml
on:
  schedule:
    - cron: '0 */4 * * *'
jobs:
  renovate:
    runs-on: ubuntu-latest
    steps:
      - uses: renovatebot/github-action@v40
        with:
          token: ${{ secrets.RENOVATE_TOKEN }}

Sur Forgejo / Gitea, le runner Docker se lance avec RENOVATE_PLATFORM=gitea et un token applicatif.

Configuration recommandée pour un repo standard :

{
	extends: ['config:base', ':dependencyDashboard', ':semanticCommits', 'schedule:nonOfficeHours'],
	labels: ['dependencies'],
	rangeStrategy: 'bump',
	lockFileMaintenance: {
		enabled: true,
		schedule: ['before 5am on monday'],
	},
	vulnerabilityAlerts: {
		labels: ['security'],
		automerge: true,
	},
	packageRules: [
		{
			matchUpdateTypes: ['minor', 'patch'],
			matchCurrentVersion: '!/^0/',
			automerge: true,
		},
		{
			matchManagers: ['dockerfile'],
			pinDigests: true,
		},
	],
}

Cette config :

• Étend les presets de base et active le Dependency Dashboard.
• Schedule en dehors des heures ouvrées pour éviter le bruit.
• Auto-merge des patches et minors (sauf 0.x où chaque minor peut casser).
• Auto-merge agressif des CVE.
• Pin par digest des images Docker (sécurité supply chain).
• Maintenance lockfile hebdomadaire le lundi à l'aube.

Pour un repo avec une CI lente, l'auto-merge évite que les développeurs perdent du temps à approuver manuellement des bumps triviaux. Pour un pipeline qui suit la pratique drone CI ou Jenkins, Renovate s'intègre par PR, pas par triggers spécifiques.

L'art de configurer Renovate : automatiser ce qui doit l'être, escalader le reste.

Auto-merge sûr :

• Patches et minors sur des libs maintenues (semver respecté).
• Bumps de digest Docker pour images officielles (alpine, postgres, node).
• CVE de sévérité High ou Critical qui passent les tests.

Escalade humaine obligatoire :

• Majors (changement d'API potentiel).
• Bumps de runtimes (Node 18 → 20, Python 3.10 → 3.11).
• Bumps de bases de données ou caches (PostgreSQL major, Redis 6 → 7).
• Bumps de framework (Next.js 13 → 14, Spring Boot 2 → 3).

Scheduling : éviter les bumps le vendredi soir. La règle d'or : schedule:earlyMondays pour les libs critiques. Pour les libs internes ou de moindre impact, schedule:weekly suffit.

Group dependencies : grouper les bumps liés (par exemple tous les @types/* npm dans une seule PR) pour réduire le nombre de PRs ouvertes.

Quelques pratiques non négociables.

Token Renovate isolé. Le token utilisé par Renovate a un scope api complet sur GitLab ou repo sur GitHub. Si compromis, l'attaquant peut pusher du code malveillant via PR auto-mergées. Stocker le token dans un secret manager (Vault, Doppler, secret CI), rotation tous les 6 mois.

Vetting des registries. Si on tire des deps depuis un registre privé, vérifier que Renovate utilise les bonnes URLs. Sinon, attaquant peut pousser un package du même nom sur un registre public et Renovate proposera la mise à jour.

Manifests de confiance. Activer extends: ["security:openssf-scorecard"] pour vérifier que les nouvelles versions des libs ont un score OpenSSF correct.

Pas d'auto-merge sur des deps non vérifiées. Si une lib n'a pas de CI ou pas de release notes, ne pas auto-merger les bumps. Garder en revue humaine.

Supply chain au build. Renovate met à jour le manifest. Le pipeline CI doit verrouiller les versions exactes (lockfile) et signer les artefacts. Voir sigstore-cosign-images pour la signature post-build, et sbom-supply-chain-security pour les SBOM.

Le risque principal de Renovate sur un parc immature : la "PR fatigue". Une équipe qui reçoit 30 PRs Renovate par jour finit par toutes les ignorer.

Stratégies pour absorber le bruit :

• Démarrer petit : activer Renovate sur 2-3 repos pilotes, ajuster la config, étendre.
• Schedule restrictif au début : schedule:earlyMondays pour ne recevoir que le lundi matin.
• Auto-merge agressif sur le premier mois : laisser la machine absorber le retard sur les patches accumulés.
• Dependency Dashboard issue : un seul ticket par repo qui résume l'état. Plus lisible que 50 PRs ouvertes.
• Owner par repo : chaque repo a un owner désigné qui revue les bumps majors. Sans owner, les bumps stagnent.
• Métriques : suivre le temps moyen entre disponibilité d'une CVE patchée et merge dans le repo (objectif : sous les 7 jours).

Sur un parc immature avec du CI/CD GitLab ou GitHub Actions, le déploiement initial Renovate prend 2 sprints : un pour le runner et la config standard, un pour l'adoption équipe et le tuning des presets.

Renovate consomme du CI. Chaque PR Renovate déclenche le pipeline. Sur un parc 100 repos × 20 bumps/semaine, ça compte. Prévoir le budget runners.

Conflits de PRs. Plusieurs PRs Renovate ouvertes simultanément peuvent créer des conflits. La feature rebaseLabel (rebase auto) résout, mais charge encore plus la CI.

Dépendances internes. Renovate scanne les registries publics. Si on a un registre interne (Verdaccio, Nexus, JFrog), il faut configurer hostRules pour les credentials. Sans ça, les libs internes ne sont pas mises à jour.

Lockfile drift. Sur des projets multi-langages (mono-repo Python + Node + Go), Renovate peut avoir du mal à orchestrer les bumps cohérents. Tester en lab avant prod.

Latence de release. Renovate détecte les nouvelles versions avec une latence de quelques heures. Pour un CVE critique 0-day, ne pas compter sur Renovate seul. Prévoir des canaux d'alerte parallèles (CVE feeds, ANSSI alerts).

Bumps qui cassent les tests. Une lib qui change un comportement subtil sans bump major. Renovate ouvre la PR, la CI verte mais l'app casse en prod. C'est un signal que la couverture de tests est insuffisante, pas un défaut Renovate.

Sur les déploiements Renovate qu'on opère pour nos clients, le ROI sécurité est immédiat : les CVE backlog passent de 200 à moins de 20 en deux mois. Le ROI dev est plus diffus mais réel : moins de "merge hell" lors des migrations majeures, parce que les bumps mineurs sont en continu. Si vous avez un parc 50+ repos qui accumulent du retard de dépendances et que vous voulez basculer sur Renovate sans submerger l'équipe, on peut auditer votre cible et installer le bot avec presets adaptés.

• Renovate documentation officielle : configuration, presets, plateformes.
• Renovate self-hosted runner GitLab : templates et exemples.
• GitHub renovatebot/renovate : code, releases, issues.
• OpenSSF Scorecard : score de qualité utilisé pour le vetting.
• Mend.io Renovate enterprise : version managed du même bot.
• Dependabot documentation - GitHub : alternative native pour repos GitHub seuls.