Correctifs de sécurité

Un correctif de sécurité transforme un résultat de dépendance en pull request. Cliquez sur Ouvrir une demande de correctif sur un résultat ou sur une carte de Recommandations, ou appelez l’API, et le bot de dépendances de votre organisation ouvre une pull request dans ce dépôt. Elle fait passer le paquet à la version publiée la plus basse qui corrige tous les avis ouverts le concernant. C’est le volet Correctifs de sécurité des Mises à jour des dépendances, sous Sécurité › Corriger › Mises à jour des dépendances.

Les correctifs de sécurité couvrent les dépendances npm (y compris Yarn, pnpm et Bun), Go, PyPI, Maven, Gradle, NuGet, Cargo, Composer, pub, RubyGems, Hex et CRAN (R), ainsi que les versions d’actions CI (GitHub Actions), dans les manifestes listés sous Écosystèmes et manifestes. Les autres écosystèmes répondent pas encore pris en charge. La liste complète figure sur Écosystèmes pris en charge. Aucun modèle d’IA n’intervient : la montée de version est calculée à partir des avis OSV.

Pour une vulnérabilité d’une image poussée dans votre registre et héritée de la base FROM de l’image, Ouvrir un correctif d’image de base fait monter cette base, une fois que fremforge a vérifié que la base plus récente n’en est plus affectée. Voir Mises à jour d’image de base. Tout corriger dans ce dépôt demande en une fois tous les paquets corrigeables d’un dépôt : voir Tout corriger dans un dépôt.

Les correctifs de sécurité s’appelaient AutoFix jusqu’au 2026-10-14. AutoFix n’est plus un nom de produit : les correctifs générés par IA pour les résultats SAST sont décrits dans Correctif IA. Les événements d’audit autofix.* et les chemins d’API obsolètes portent encore l’ancien nom. Les pull requests ouvertes avant le changement gardent leur branche autofix/ ; fremforge ajoute le label security-fix à celles qui sont encore ouvertes.

Paramètres

Un propriétaire les définit sous Sécurité › Corriger › Mises à jour des dépendances › Correctifs de sécurité, ou avec PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings. Chaque champ est facultatif dans un PUT ; un champ omis garde sa valeur, et rien n’est enregistré si un champ est refusé.

Les modes :

• Désactivé (off) : aucune pull request de correctif de sécurité, ni sur clic ni automatiquement.
• Sur clic (on_click) : une personne la demande, avec Ouvrir une demande de correctif, Tout corriger dans ce dépôt ou Ouvrir un correctif d’image de base, ou via l’API.
• Automatique pour les résultats importants (auto_important) : comme sur clic, et fremforge les ouvre aussi de lui-même pour les résultats élevés et critiques atteignables ou connus comme exploités. Avec Inclure aussi les résultats dont l’atteignabilité est inconnue activé, les résultats élevés et critiques sans verdict d’atteignabilité comptent aussi. Voir Correctifs de sécurité automatiques.
• Automatique pour tous les élevés et critiques (auto_high_critical) : fremforge les ouvre de lui-même pour chaque résultat élevé ou critique qu’il peut corriger, quelle que soit son atteignabilité.
• Automatique pour les critiques et les exploités connus (auto_critical_exploited) : fremforge les ouvre de lui-même pour chaque résultat critique, quelle que soit son atteignabilité, et pour chaque résultat connu comme exploité, quelle que soit sa sévérité. Un résultat élevé, moyen ou faible qui n’est pas connu comme exploité attend un clic. C’est le mode par défaut pour une organisation créée le 2026-10-27 ou après ; voir Nouvelles organisations.

La réponse contient aussi des champs en lecture seule. configured vaut false tant que l’organisation n’a jamais enregistré les paramètres et que les valeurs sont celles par défaut (pour une nouvelle organisation, celles avec lesquelles elle a été créée). lane_owner indique qui ouvre les pull requests de sécurité : renovate tant que les pull requests de sécurité propres à Renovate hébergé servent encore l’organisation, security_lane une fois que ce volet a pris le relais. high_blast_radius_exempt vaut true pour les organisations dont les pull requests de sécurité Renovate fusionnaient d’elles-mêmes avant le 2026-10-14 et qui ont été passées à Fusionner quand les vérifications passent ; voir Fusion.

Une modification est enregistrée dans le journal d’audit sous dependency-updates.security-fixes.updated, avec l’ancienne et la nouvelle valeur de chaque champ.

curl -X PUT -H "Authorization: Bearer ${FREMFORGE_PAT}" -H "Content-Type: application/json" \
  -d '{"mode": "auto_important", "max_per_day": 10}' \
  "https://frem.sh/_app/api/v1/orgs/acme/dependency-updates/security-fixes/settings"

Les correctifs de sécurité n’ont pas besoin des Mises à jour de version. La première demande de correctif (Ouvrir une demande de correctif, Tout corriger dans ce dépôt, Ouvrir un correctif d’image de base ou POST .../security-fixes/requests), ou l’enregistrement d’un mode automatique, provisionne le bot de dépendances de votre organisation <org>-fremforge-bot-deps en laissant les mises à jour de version désactivées. Un dépôt exclu des mises à jour des dépendances ne reçoit aucune pull request de correctif, et un dépôt archivé ou miroir est refusé (repo_archived).

Ce qui se passe quand vous cliquez sur Ouvrir une demande de correctif

1. fremforge rassemble tous les résultats ouverts sur la branche par défaut pour le même paquet dans le même dépôt. Une seule pull request les clôt tous.
2. Il calcule la version cible. Pour chaque version installée, c’est la version publiée la plus basse située hors de toutes les plages affectées de tous les avis ouverts. La pull request retient la plus haute de ces versions, afin de corriger tout le groupe.
3. Une exécution ciblée de Renovate hébergé démarre, sous l’identité du bot de dépendances de votre organisation. Elle se limite à ce seul paquet et à cette seule version. Toutes les autres dépendances restent inchangées.
4. Renovate ouvre la pull request sur une branche security-fix/<package>-<version>. Les exécutions de correctifs de sécurité passent avant les exécutions Renovate ordinaires, si bien que cela prend généralement moins de 15 minutes. La pull request porte le label security-fix. Si le dépôt n’a pas encore ce label, fremforge le crée avant l’exécution, une seule fois ; un label déjà existant est laissé tel quel. Si un label ne peut pas être créé, la pull request est ouverte sans lui.
5. fremforge vérifie la pull request avant de la garder ouverte. Elle ne peut modifier que les manifestes et fichiers de verrouillage de l’écosystème (voir le tableau ci-dessous), et dans un manifeste, uniquement l’entrée de ce paquet. Une modification de tout autre fichier, une nouvelle dépendance directe, la montée de version d’un autre paquet, une version partagée, ou un fichier de verrouillage dont les paquets proviennent désormais d’un autre index ferme la pull request et supprime sa branche. Il en va de même d’un échec de rafraîchissement du fichier de verrouillage : une pull request avec un fichier de verrouillage obsolète ne compilerait pas.

Le résultat affiche alors Correctif proposé : n° N avec l’état de la pull request : ouverte, fusionnée ou fermée.

Chaque copie, au niveau du correctif. Un fichier de verrouillage peut contenir plusieurs copies d’un même paquet : une copie directe, et des copies plus anciennes imbriquées sous d’autres dépendances. Avant qu’une pull request compte comme correctif, fremforge lit ses fichiers de verrouillage à la tête de la pull request et compare chaque copie du paquet qu’ils enregistrent à la version corrigée. Cela s’applique à package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock, Cargo.lock, go.mod et au packages.lock.json de NuGet, pour les correctifs simples comme pour les correctifs regroupés. Une préversion de la version corrigée compte comme inférieure à celle-ci.

• Toutes les copies au niveau du correctif ou au-dessus : la pull request corrige le paquet.
• Certaines copies corrigées, une plus ancienne restante : la pull request reste ouverte, et la console nomme les copies restantes (dans l’API, lock_copies_left de la demande, avec reason target_partly_reached). Correctif proposé n’apparaît que sur les résultats des copies qu’elle corrige ; les autres gardent leur bouton Correctif.
• Aucune copie au niveau du correctif, par exemple une copie transitive qui a suivi son parent mais vers une version encore vulnérable : le paquet ne fait pas partie de la pull request. Sa demande se termine par target_not_reached, et le correctif transitif l’épingle séparément. Une pull request qui ne corrige plus aucun paquet est fermée.

Un format de fichier de verrouillage non listé ici est vérifié comme auparavant : la pull request doit modifier le paquet dans le fichier de verrouillage.

Ce que cette vérification ne fait pas :

• Seuls les fichiers de verrouillage modifiés par la pull request sont lus. Si un autre fichier de verrouillage du dépôt, que la pull request ne touche pas, contient encore une version vulnérable, ce résultat reste ouvert après la fusion. Il n’est pas déclaré corrigé : son bouton Correctif reste affiché.
• Une copie laissée de côté est corrigée après la fusion, pas en même temps. Tant que la pull request est ouverte, une nouvelle demande pour le même paquet est refusée parce qu’une demande est déjà ouverte ; Correctif sur une copie que la pull request laisse de côté ne lance donc encore rien. Après la fusion et l’analyse suivante, refaites la demande.
• La même version, directe et imbriquée. Un résultat est identifié par paquet et version, pas par l’emplacement de la copie dans l’arbre. Si la pull request fait monter la copie directe mais que la même ancienne version reste imbriquée sous une autre dépendance, ce résultat n’est pas corrigé : la demande se termine par target_not_reached et sa pull request est fermée. Le correctif transitif refuse un paquet que votre manifeste nomme directement ; épinglez donc vous-même la copie imbriquée (par exemple avec une entrée npm overrides).

Les paramètres Renovate de votre dépôt

Le renovate.json propre à un dépôt (ou .renovaterc, ou la clé renovate de package.json) façonne ses mises à jour de version. Il ne retient pas un correctif de sécurité. Une exécution de correctif de sécurité ignore, dans le dépôt :

• packageRules, y compris une règle avec "enabled": false pour le paquet ;
• ignoreDeps ;
• ignorePaths et includePaths. Seuls node_modules et bower_components sont ignorés ;
• enabledManagers. L’exécution utilise les gestionnaires de l’écosystème du résultat.

Pour exclure un paquet des correctifs de sécurité, enregistrez une exception pour ses résultats : rejetez-les avec un motif et, de préférence, une date d’expiration, ou demandez une exception approuvée. Un résultat faisant l’objet d’une exception n’est pas ouvert : aucune demande de correctif n’est donc faite pour lui, et Ouvrir une demande de correctif répond security-fix-not-open. Contrairement à une règle de blocage dans un fichier, une exception est visible sur la page Exceptions, indique qui l’a créée et pourquoi, et expire à sa date d’expiration.

Deux paramètres s’appliquent toujours :

• Un "enabled": false de premier niveau dans renovate.json désactive Renovate pour tout le dépôt, correctifs de sécurité compris.
• Les packageRules d’un dépôt qui définissent registryUrls ou d’autres paramètres de recherche ne s’appliquent pas à une exécution de correctif de sécurité. L’exécution recherche les paquets via les paramètres propres à votre organisation et le proxy de dépendances.

Les vulnérabilités connues comme exploitées en premier

Lorsqu’un avis corrigé par une demande a un CVE répertorié comme exploité dans la nature, par la base européenne de vulnérabilités de l’ENISA (EUVD) ou par le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, le correctif est traité comme le plus urgent :

• Il passe en premier. Son exécution Renovate est prise avant toutes les autres demandes de correctif de sécurité en file d’attente, quel que soit l’ordre dans lequel elles ont été faites.
• Il est en tête de Tout corriger. Un lot Tout corriger dans ce dépôt admet les paquets connus comme exploités avant les autres, puis par sévérité ; lorsqu’une limite est atteinte, c’est donc un paquet moins urgent qui est laissé de côté.
• Il n’attend pas l’âge de la version. Votre Âge de la version retient les autres correctifs, mais une version qui corrige une vulnérabilité connue comme exploitée est proposée immédiatement.
• La pull request l’indique. Le titre se termine par known exploited, par exemple fix(security): bump log4js 1.0.0 to 1.0.1 (1 advisory, known exploited), la description commence par les CVE et les listes qui les citent, et la pull request porte aussi le label known-exploited, créé de la même façon que security-fix.

Un CVE compte lorsqu’il est l’identifiant de l’avis lui-même ou l’un de ses alias (un avis GHSA ou PYSEC a généralement un alias CVE). Les deux listes sont mises en miroir et rafraîchies chaque jour. Le caractère « connu comme exploité » d’une demande est déterminé au moment où elle est faite ; l’API le renvoie dans known_exploited_cves. Avec Fusionner quand les vérifications passent, la fusion automatique est aussi armée en dehors de votre fenêtre de fusion ; voir Fusion. Les limites s’appliquent toujours.

Correctifs de sécurité automatiques

Avec Automatique pour les résultats importants, Automatique pour tous les élevés et critiques ou Automatique pour les critiques et les exploités connus, fremforge ouvre les mêmes pull requests qu’un clic sur Ouvrir une demande de correctif ou Ouvrir un correctif d’image de base, sans que personne ne clique, pour chaque résultat qui remplit toutes ces conditions :

1. Il est ouvert sur la branche par défaut : ni rejeté, ni signalé sur une pull request.
2. Sa sévérité est élevée ou critique. Les résultats moyens et faibles ne sont corrigés automatiquement qu’avec Automatique pour les critiques et les exploités connus, et uniquement s’ils sont connus comme exploités.
3. Avec Automatique pour les résultats importants : il est atteignable (son verdict d’atteignabilité est reachable) ou il est connu comme exploité (l’un de ses CVE est répertorié par l’EUVD de l’ENISA ou le KEV de la CISA), ou, avec Inclure aussi les résultats dont l’atteignabilité est inconnue activé, il n’a pas de verdict ou un verdict inconnu. Un résultat connu comme exploité est retenu même s’il est inatteignable. Avec Automatique pour tous les élevés et critiques, tout résultat élevé ou critique est retenu. Avec Automatique pour les critiques et les exploités connus, un résultat critique est retenu quelle que soit son atteignabilité, un résultat connu comme exploité est retenu quelle que soit sa sévérité, et rien d’autre ne l’est.
4. fremforge peut le corriger de façon déterministe : une dépendance d’un écosystème et manifeste couvert avec un correctif publié, ou un résultat d’image corrigé par une mise à jour de l’image de base.

Pour l’essayer d’abord sur quelques dépôts, listez-les sous Dépôts. Une liste vide couvre tous les dépôts de l’organisation. Le dépôt d’exemple de sécurité n’est jamais corrigé automatiquement ; un clic sur Ouvrir une demande de correctif y fonctionne toujours.

Nouvelles organisations

Une organisation créée le 2026-10-27 ou après démarre avec Automatique pour les critiques et les exploités connus, et Quand les correctifs sont fusionnés sur Attendre la revue : les pull requests de correctif s’ouvrent d’elles-mêmes, et aucune n’est fusionnée sans intervention humaine. Les limites, le regroupement et l’âge de la version gardent leurs valeurs par défaut. Rien n’est inscrit aux Mises à jour de version : le bot de dépendances <org>-fremforge-bot-deps n’est créé que lorsque le premier résultat est retenu. Un propriétaire peut passer à tout autre mode, y compris Désactivé, ou l’élargir, à tout moment. Les organisations créées avant le 2026-10-27 conservent leur paramètre.

Quand il agit

fremforge vérifie toutes les 10 minutes. Un résultat est proposé peu après qu’il est retenu : lorsqu’une analyse signale un nouveau résultat, lorsque son verdict devient atteignable, ou lorsque le rafraîchissement quotidien des vulnérabilités connues comme exploitées ajoute l’un de ses CVE. Les résultats déjà retenus au moment où vous l’activez sont aussi inclus, dans les limites.

Ce qui ne change pas

Chaque demande automatique suit exactement le chemin d’un clic : une pull request par paquet (ou par image de base), la version corrigée la plus basse, les limites de votre organisation, l’attente liée à l’âge de la version, le refus des versions partagées et les vérifications de périmètre. Dans la liste des demandes, une telle demande porte "trigger": "policy", et sa pull request indique qu’elle a été ouverte automatiquement.

• Elle est fusionnée selon votre réglage. Comme toute pull request de correctif de sécurité, elle suit Quand les correctifs sont fusionnés ; voir Fusion.
• Elle n’utilise jamais l’IA. Seul le moteur déterministe s’exécute automatiquement. Le Correctif IA démarre toujours par le clic d’une personne sur un résultat.
• Un afflux attend son tour. Lorsque la liste des vulnérabilités connues comme exploitées ajoute un CVE présent dans beaucoup de vos dépôts, fremforge ouvre ce que vos limites permettent, les vulnérabilités connues comme exploitées et critiques d’abord, et le reste plus tard, à mesure que des pull requests sont fusionnées ou fermées et que la fenêtre de 24 heures avance. Il ne dépasse jamais les limites.
• Une pull request fermée reste fermée. Si quelqu’un ferme une pull request de correctif de sécurité sans la fusionner, fremforge ne la rouvre pas pour les mêmes résultats et la même version cible. Un nouveau résultat retenu sur ce paquet, ou une version cible plus récente, constitue une nouvelle raison et peut être proposé. Une demande terminée sans pull request (par exemple En attente de l’âge de publication) est retentée au bout de 24 heures.

Les demandes faites automatiquement sont enregistrées sous autofix.proposed avec source: policy, l’acteur system:autofix-policy et qualifiedBy (known_exploited, reachable, unknown ou severity).

Écosystèmes et manifestes

Pas encore couverts, et signalés comme tels sur le résultat :

• Les autres outils de build JVM (Ivy, sbt) : le résultat affiche Manifeste non couvert.
• bun.lockb, le fichier de verrouillage binaire de Bun, que seul Bun peut réécrire. Exécutez une fois bun install --save-text-lockfile pour passer à bun.lock.
• Les paquets Bun que le manifeste ne nomme pas : l’exécution se termine par aucune modification.
• Les paquets pub que le manifeste ne nomme pas : l’exécution se termine par aucune modification.
• Les résultats issus d’un SBOM téléversé (manifeste sbom:<name>) : il n’y a aucun fichier du dépôt à modifier. Le résultat affiche Issu d’un SBOM.
• Conan (conan.lock) : OSV, où l’analyse des dépendances lit ses avis, n’en publie aucun pour les paquets Conan ; il n’y a donc aucune vulnérabilité Conan à corriger.

Un paquet qui n’est qu’une dépendance transitive (présent dans le fichier de verrouillage, mais pas dans un manifeste) est épinglé depuis la racine de votre projet : une entrée npm overrides, une entrée Maven <dependencyManagement>, ou la ligne // indirect de go.mod. Voir Dépendances transitives.

Rafraîchissement des fichiers de verrouillage

Le fichier de verrouillage est rafraîchi par le gestionnaire de paquets lui-même (uv lock, poetry lock, dotnet restore, cargo update, composer update --no-scripts --no-plugins, dart pub upgrade, bun install --ignore-scripts, etc.), sans jamais exécuter les scripts ou plugins propres au dépôt, sous l’identité du bot Renovate de votre organisation, dans le même bac à sable Renovate hébergé que ses mises à jour ordinaires. Un rafraîchissement ne déplace jamais des paquets vers un autre index : un fichier de verrouillage Python ou Cargo dont les paquets proviendraient ensuite d’un autre index est refusé. Si le rafraîchissement échoue, par exemple parce que le dépôt nomme un index privé que le bot ne peut pas lire, la pull request est fermée avec PR fermée : verrouillage en échec plutôt que laissée ouverte avec un fichier de verrouillage obsolète.

Le proxy de dépendances de votre organisation comme index. Lorsque les manifestes, fichiers de verrouillage ou la configuration d’outils du dépôt nomment le proxy de dépendances de votre organisation (https://frem.sh/_app/proxy/<org>/pypi/..., .../nuget/..., .../cargo/..., .../maven/...), le rafraîchissement s’y authentifie en tant que votre bot Renovate. Cela s’applique à toutes les exécutions Renovate de ce dépôt, pas seulement à celles de fremforge. L’identifiant est fourni exactement pour les chemins du proxy de votre organisation que le dépôt nomme, et pour rien d’autre : un index uv, Poetry ou Pipenv et une source nuget.config le reçoivent via la gestion des identifiants propre à Renovate, Cargo via un fournisseur d’identifiants qui ne répond que pour le proxy Cargo de votre organisation. (Un build Gradle n’est pas du tout rafraîchi ici ; voir Gradle.) L’identifiant réside dans des fichiers propres à cette exécution, jamais dans le dépôt, jamais dans l’environnement et jamais dans les journaux.

Gradle

fremforge n’exécute jamais le build de votre dépôt. Rafraîchir un fichier de verrouillage Gradle implique d’exécuter votre wrapper Gradle et vos scripts de build ; pour un résultat Gradle, le travail est donc partagé :

1. fremforge ne modifie que la version. Renovate modifie build.gradle(.kts), le catalogue de versions ou gradle.properties, avec les mêmes vérifications de périmètre et de version partagée que toute pull request de correctif de sécurité, et ouvre la pull request sans toucher aux fichiers de verrouillage. Aucune exécution Renovate, de fremforge ou ordinaire, n’exécute de code du dépôt.
2. Votre propre CI rafraîchit les fichiers de verrouillage. Si le build a des fichiers *.lockfile ou gradle/verification-metadata.xml, fremforge commite un workflow généré, .forgejo/workflows/fremforge-autofix-relock.yaml, sur une branche jetable autofix-relock/<request> (avec [skip ci], pour qu’aucun de vos propres workflows ne s’y exécute) et le lance une fois sur le runner hébergé de votre organisation (runs-on: fremforge) : une VM éphémère de ce commit. Cela ne compte pas dans les minutes CI de votre organisation : fremforge enregistre l’exécution qu’il a lancée et l’exclut de votre consommation et de votre facture. Elle occupe en revanche l’un de vos créneaux de tâches simultanées pendant son exécution. Vous n’avez rien à modifier dans votre dépôt. L’exécution apparaît dans l’onglet Actions du dépôt.
3. La tâche exécute les mêmes commandes que le gestionnaire Gradle de Renovate : gradlew :dependencies <subproject>:dependencies --update-locks <group:artifact>, et --write-verification-metadata lorsque le build vérifie les dépendances. Elle choisit un JDK du runner (21, sinon 17), transmet le proxy de sortie du runner à la JVM, et lit le proxy de dépendances de votre organisation avec le jeton propre à la tâche via les propriétés fremforgeUsername et fremforgePassword. Elle ne détient aucun identifiant en écriture : ses permissions sont contents: read, packages: read et id-token: write.
4. fremforge vérifie et commite le résultat. La tâche envoie les fichiers de verrouillage et de vérification modifiés à fremforge avec un jeton de tâche pour l’audience fremforge:autofix-relock, que fremforge n’accepte que de cette exécution précise. fremforge refuse tout ce qui n’est pas un fichier de verrouillage ou de vérification Gradle du build reverrouillé, un fichier de verrouillage qui verrouille encore la version vulnérable, ou une branche modifiée entre-temps. Il ajoute ensuite les fichiers à la pull request de correctif de sécurité en un seul commit de votre bot Renovate, de sorte que la CI de votre pull request s’exécute dessus, vérifie que la pull request ne modifie que des fichiers de build Gradle et des fichiers de verrouillage, et supprime la branche jetable. Le statut fremforge/autofix-relock de la pull request renvoie vers l’exécution.

Un build sans fichiers de verrouillage ne reçoit que la modification de version, et aucune tâche ne s’exécute.

Si la tâche échoue, est annulée, ne rend pas compte, ou n’est pas terminée 90 minutes après son lancement (par exemple lorsque les minutes de runner de l’organisation sont épuisées), la pull request est fermée avec PR fermée : verrouillage en échec et un lien vers l’exécution. Relisez une pull request Gradle une fois le commit des fichiers de verrouillage arrivé ; d’ici là, ses fichiers de verrouillage sont obsolètes. Avec Fusionner quand les vérifications passent, la fusion automatique d’un correctif Gradle n’est pas armée tant que le rafraîchissement de son fichier de verrouillage est en attente ou en cours de commit ; elle l’est une fois le commit du fichier de verrouillage arrivé et ses vérifications passées. Si vous la fusionnez à la main, attendez le commit du fichier de verrouillage.

RubyGems, Hex, CRAN et paquets Composer que composer.json ne nomme pas

Bundler lit le Gemfile et Mix lit mix.exs pour les verrouiller, et tous deux sont du code (Ruby, Elixir) ; fremforge n’exécute donc jamais lui-même Bundler ni Mix. Mettre à jour renv.lock nécessite R, que ni fremforge ni Renovate n’exécutent. Renovate ne met à jour que les paquets Composer que composer.json nomme. Pour ces correctifs, le fichier de verrouillage est mis à jour dans votre propre CI, de la même manière qu’un rafraîchissement Gradle, et la pull request n’est ouverte qu’une fois celui-ci arrivé :

1. Votre propre CI met à jour le fichier de verrouillage. fremforge commite le workflow généré .forgejo/workflows/fremforge-autofix-relock.yaml sur une branche jetable autofix-relock/<request> créée depuis la tête de la branche de base (avec [skip ci]), et le lance une fois sur le runner hébergé de votre organisation, sans le décompter de vos minutes CI. Dans le répertoire du fichier de verrouillage, il exécute bundle lock --update <gem> --conservative --patch|--minor|--major --strict (le plus petit niveau qui atteint le correctif, avec le Ruby de .ruby-version ou du fichier de verrouillage et la version de Bundler avec laquelle le fichier de verrouillage a été écrit), mix deps.update <package> dans l’image officielle elixir (la version que nomme votre .tool-versions, sinon la version actuelle ; vos runners n’embarquent pas Elixir), le script R de fremforge dans l’image rocker/r-ver à la version de R enregistrée dans renv.lock (voir CRAN ci-dessous), ou composer update <package> --with <package>:<version> --minimal-changes --no-scripts --no-plugins --no-install. Rien n’est installé et aucun script de gem ou de paquet ne s’exécute. Il ne détient aucun identifiant en écriture. Pendant son exécution, le résultat affiche Correctif demandé.
2. L’âge de la version est vérifié dans la tâche. Sauf si le correctif concerne une vulnérabilité connue comme exploitée, la tâche lit la date de publication de la version qu’elle a verrouillée sur rubygems.org, hex.pm ou repo.packagist.org, ou, pour CRAN, dans le champ Date/Publication du paquet lui-même ; une version plus récente que l’âge de la version de votre organisation termine la demande par Pas encore de PR : trop récente, et elle est retentée au bout de 24 heures.
3. fremforge vérifie le fichier de verrouillage et ouvre la pull request. La tâche renvoie l’unique fichier de verrouillage avec un jeton de tâche propre à cette exécution. fremforge refuse un fichier de verrouillage dans lequel quoi que ce soit d’autre que les versions verrouillées a changé (sources, plateformes, dépendances, version de Bundler, content-hash de Composer, une dépendance git ou de chemin dans mix.lock, dans renv.lock tout ce qui n’est pas l’enregistrement propre à ce paquet), un fichier qui ne verrouille pas la version corrigée, ou un fichier qui verrouille encore la version vulnérable. Il le commite ensuite sous l’identité de votre bot Renovate sur la branche du correctif de sécurité, créée depuis la branche de base, ouvre la pull request avec le titre, la description et les labels habituels, et supprime la branche jetable. À partir de là, c’est une pull request de correctif de sécurité ordinaire.

Si la tâche échoue, est annulée, ne rend pas compte, ou n’est pas terminée 90 minutes après son lancement, aucune pull request n’est ouverte et la demande se termine par Pas de PR : mise à jour du verrouillage en échec, avec la raison et un lien vers l’exécution.

CRAN

Un correctif CRAN modifie un seul enregistrement de renv.lock et rien d’autre. La tâche installe la version de renv avec laquelle renv.lock a été écrit, afin que le fichier garde son format, et lit le DESCRIPTION de la version corrigée dans le dépôt de paquets que renv.lock nomme. Elle n’installe jamais votre projet et n’exécute jamais son code. Elle refuse, en expliquant pourquoi, lorsque :

• la version corrigée a besoin d’un paquet (Depends, Imports ou LinkingTo) que renv.lock ne verrouille pas, ou verrouille à une version inférieure à celle requise ;
• la version corrigée a besoin d’une autre version de R que celle enregistrée dans renv.lock ;
• le DESCRIPTION de votre projet borne le paquet en dessous du correctif, par exemple Imports: commonmark (<= 1.8) ;
• la version corrigée est plus récente que l’âge de la version de votre organisation.

Dans chacun de ces cas, mettez à jour les paquets ensemble avec renv dans votre projet (renv::update() puis renv::snapshot()). Sinon, l’enregistrement reçoit la nouvelle version, ses dépendances et le hash de renv, et fremforge n’accepte le fichier que si tous les autres enregistrements, la version de R et les dépôts sont inchangés.

Versions partagées

Une version définie à un seul endroit et lue par plusieurs dépendances, comme une propriété pom.xml (<logback.version>), une variable Gradle dans gradle.properties ou une entrée de catalogue de versions ([versions] logback = "1.5.12"), fait monter toutes ces dépendances lorsqu’elle change. fremforge lit chaque pom.xml, ou chaque fichier de build et catalogue Gradle, de la pull request.

Une propriété pom.xml est montée lorsque la montée convient à chacun de ses lecteurs. Chaque autre dépendance qui la lit doit avoir des vulnérabilités ouvertes dans le dépôt (sur la branche par défaut), être corrigée à la nouvelle version ou en dessous, et être publiée à cette version sur le proxy Maven de votre organisation. La pull request liste alors ces dépendances sous Also updated by this pull request et clôt leurs résultats lors de sa fusion. Si deux demandes de correctif aboutissaient à la même montée, celle du paquet qui vient en premier dans l’ordre de tri la conserve et l’autre se termine par PR fermée : version partagée, en le nommant.

Sinon, et toujours pour une variable Gradle ou une entrée de catalogue, un correctif de branche de version ou une version lue d’une manière que fremforge ne peut pas rattacher à une dépendance, la pull request est fermée avec PR fermée : version partagée, et le detail de la demande indique quel lecteur ne remplit pas quelle condition (pas de vulnérabilité ouverte, pas de version corrigée, nécessite une version plus haute, non publiée à la nouvelle version). Montez alors vous-même la version partagée, afin de choisir la version pour toutes : la version corrigée du paquet vulnérable peut ne pas exister comme version publiée des autres (une famille de bibliothèques publie souvent un correctif d’un seul artefact). Une version lue uniquement par le paquet vulnérable est montée normalement.

Tout corriger dans un dépôt

Sur Recommandations, chaque dépôt comptant au moins deux paquets que fremforge peut corriger dès maintenant a un bouton Tout corriger dans ce dépôt. Il demande une pull request par paquet (et par image de base, voir ci-dessous), ou, dans un dépôt qui regroupe ses correctifs, une par fichier de verrouillage, les vulnérabilités connues comme exploitées d’abord, puis la sévérité la plus haute. Les demandes sont admises ensemble dans le cadre de vos limites : dès qu’un dépôt a 3 pull requests de correctif de sécurité ouvertes, ou que votre organisation a utilisé ses 20 demandes de la journée, les autres ne sont pas demandées, et le résultat indique combien l’ont été. Un paquet qui a déjà une demande est ignoré.

Avec l’API : POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests avec {"repo": "<name>"} répond 202 avec un résultat par paquet (queued, ou refused avec une reason), ou 200 lorsqu’aucun n’a été mis en file d’attente.

Correctifs regroupés

Dans un dépôt listé sous Dépôts regroupés (grouped_repos), les correctifs d’un même fichier de verrouillage vont dans une seule pull request, comme les groupes Dependabot, au lieu d’une par paquet. Tous les autres dépôts gardent une pull request par paquet, et c’est aussi le comportement par défaut de chaque dépôt.

• Ce qui est regroupé : les paquets d’un même fichier de verrouillage (un écosystème, un manifeste, une branche de base) dont le correctif reste dans la version majeure installée, en npm (avec pnpm et Yarn), PyPI, Go, Cargo et NuGet. Un groupe compte au plus 20 paquets ; au-delà, un second groupe est créé.
• Ce qui ne l’est pas : un correctif qui nécessite une nouvelle version majeure, une image de base, un épinglage d’action CI, et les paquets Gradle, Maven, Composer, RubyGems, Hex et CRAN. Chacun d’eux reste une pull request distincte, comme avant.
• Quand : Tout corriger dans ce dépôt et les correctifs de sécurité automatiques. Un simple Ouvrir une demande de correctif sur un résultat reste une seule pull request pour ce paquet.
• Limites : un groupe compte comme une pull request pour Pull requests de correctif ouvertes par dépôt et comme une demande pour Pull requests de correctif par jour. Un paquet qui a déjà sa propre demande, ou qui a été tenté au cours des 10 dernières minutes, est exclu du groupe plutôt que répété.
• Chaque paquet garde sa propre demande. La pull request liste chaque paquet avec sa version corrigée, et les résultats de chacun sont clos à la fusion, comme pour un correctif simple. Un paquet que l’exécution n’a pas pu mettre à jour avec les autres, ou seulement vers une version inférieure à son correctif (voir Chaque copie, au niveau du correctif sous Ce qui se passe quand vous cliquez sur Ouvrir une demande de correctif), est exclu et nommé sur la pull request. Il garde sa propre demande : celle qui attend son âge de version est redemandée plus tard, et un paquet que le manifeste ne nomme pas (une dépendance transitive) est épinglé séparément par le correctif transitif. Un paquet exclu ne retient jamais le groupe.
• Dans la console, Activité affiche une pull request regroupée une seule fois, sous la forme Regroupé · N paquets avec chaque paquet et sa version. Dans l’API, chaque demande d’un groupe porte le même group_id (sur POST .../requests avec repo, et sur GET .../requests).

Mises à jour d’image de base

Pour une vulnérabilité d’une image poussée dans le registre de votre organisation, fremforge peut faire monter la base FROM de l’image dans le Dockerfile qui l’a construite. Ouvrir un correctif d’image de base sur le résultat (sous Sécurité › Résultats › Images de conteneurs) est disponible lorsque toutes ces conditions sont réunies :

1. fremforge sait quel dépôt et quel commit ont construit l’image, de l’une de deux façons :

   • l’image les nomme, avec les labels OCI org.opencontainers.image.source et org.opencontainers.image.revision (docker/metadata-action définit les deux). Les labels l’emportent lorsqu’ils sont présents ;
   • ou, sans ces labels, l’image a été poussée par une exécution fremforge Actions d’un dépôt de votre organisation : le registre de fremforge enregistre quelle exécution a poussé chaque manifeste, et le dépôt et le commit sont ceux de cette exécution. Chaque push de l’image doit provenir d’exécutions Actions de ce seul dépôt ; une image aussi poussée d’ailleurs (un ordinateur portable, une autre CI), ou par une exécution d’un dépôt d’une autre organisation, n’est pas attribuée de cette façon.

   Le résultat indique quel dépôt et quel Dockerfile ont construit l’image et comment fremforge le sait (« d’après ses labels d’image » ou « d’après l’exécution Actions qui l’a poussée »), tout comme l’API (base_attribution sur chaque résultat d’image).

2. fremforge a trouvé dans ce commit le Dockerfile dont la base FROM sert de fondation à l’image : les couches de l’image de base sont les premières couches de votre image.

3. Trivy situe le paquet vulnérable dans l’une de ces couches de base, et non dans une couche ajoutée par votre Dockerfile.

4. La base la plus récente de la même lignée (même version majeure et même forme de tag, ou le digest plus récent du même tag pour un tag flottant), analysée par fremforge avec la même base de vulnérabilités, n’en est plus affectée.

Cette analyse s’exécute avec l’analyse quotidienne des images. La pull request ne modifie que cette ligne FROM : le tag, et le digest que fremforge a analysé pour lui. Une modification de toute autre ligne ou de tout autre fichier, ou un digest autre que celui analysé par fremforge, la ferme. Tous les résultats ouverts de l’image que la même base corrige sont listés dans une seule pull request.

Lorsqu’il n’y a pas de bouton, le résultat en indique la raison :

Après avoir fusionné la pull request et poussé l’image reconstruite sous le même tag, fremforge compare la nouvelle image à l’ancienne une fois la nouvelle analysée. Chaque résultat de l’ancien digest que la nouvelle image n’a plus est clos comme corrigé par fremforge (fixed_source: security_fix), à condition que l’ancien digest ne soit plus utilisé : il ne porte plus aucun tag, il ne figure pas dans le dernier déploiement actif d’un dépôt et d’un environnement, et personne d’autre que les bots de fremforge ne l’a tiré par digest au cours des 7 derniers jours. Les résultats de l’ancien digest restent listés sous ce digest tant que l’image existe dans votre registre.

Si l’ancien digest est encore utilisé, rien n’est clos : le résultat affiche Corrigé dans une image plus récente avec le nouveau digest, et indique pourquoi il reste ouvert (toujours tagué, toujours déployé, ou tiré récemment). Il est clos dès que l’ancien digest n’est plus utilisé, et rouvert si ce digest est de nouveau utilisé.

Après la fusion

Lorsque la pull request est fusionnée et que l’analyse suivante de la branche par défaut ne signale plus un résultat, ce résultat est clos. Son historique dans le rapport de conformité l’enregistre comme corrigé par un correctif de sécurité (fixed_source: security_fix ; les lignes enregistrées avant le 2026-10-14 indiquaient autofix). Un résultat clos par l’une des pull requests de sécurité propres à Renovate hébergé est enregistré sous fixed_source: renovate. Les indicateurs de remédiation comptent les deux.

Limites

• Une seule demande active par (dépôt, paquet) sur chaque branche. Une seconde demande pour le même paquet sur la même branche répond déjà demandé. Un correctif sur une branche de version protégée est une demande distincte de celle de la branche par défaut.
• Au plus 3 pull requests de correctif de sécurité ouvertes par dépôt, par défaut ; de 0 à 10.
• Au plus 20 demandes par organisation sur toute période de 24 heures, par défaut ; de 0 à 50.
• Une pull request regroupée compte pour une dans les deux cas.

Elles s’appliquent ensemble aux clics et aux correctifs de sécurité automatiques. Le Correctif IA a ses propres limites. Lorsqu’aucune pull request n’est ouverte, voir Dépannage.

API

• Demander un correctif POST /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, portée dependency-updates:write (findings:write est aussi accepté). Le corps nomme exactement un élément parmi :

  • finding_id : un résultat de dépendance. Une pull request pour son paquet. Répond 202 avec l’identifiant de la demande, la version cible, les clés des résultats couverts, known_exploited_cves (les identifiants des CVE connus comme exploités qu’elle corrige ; vide s’il n’y en a pas) et automerge.
  • repo : chaque paquet corrigeable de ce dépôt, une pull request chacun, ou une par fichier de verrouillage dans un dépôt regroupé. Répond 202 avec un résultat par paquet (queued avec son group_id, null s’il n’est pas regroupé, ou refused avec une reason), ou 200 lorsqu’aucun n’a été mis en file d’attente.
  • image_finding_id : une mise à jour d’image de base. Les refus incluent image_not_from_base, image_no_base_fix, image_source_unknown et image_not_attributed.

  Un refus est un problem+json dont le type est security-fix-<reason> et qui porte reason, par exemple no_fixed_version, ecosystem_not_supported, manifest_not_supported ou sbom_finding. Chacun est décrit sous Erreurs de l’API.

• Lister les demandes GET /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/requests, portée dependency-updates:read, avec le statut et la pull request de chaque demande.

• Paramètres GET et PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/settings ; voir Paramètres.

• Qui ouvre les pull requests de sécurité GET et PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane ; voir Prendre le relais de Renovate.

• GET /_app/api/v1/orgs/{org}/dependency-updates porte security_fixes_bot, true lorsque le bot de dépendances existe pour les correctifs de sécurité. Son champ enrolled signifie que les mises à jour de version sont activées.

• Compteurs GET /_app/api/v1/orgs/{org}/code-security/autofix/metrics : demandes, pull requests ouvertes, fusionnées et fermées, taux d’acceptation, pull requests fusionnées sans revue d’approbation, et résultats corrigés par un correctif de sécurité.

Chaque résultat de dépendance renvoyé par GET /_app/api/v1/orgs/{org}/code-security/deps/findings porte autofix_eligible, autofix_unavailable_reason (pourquoi un résultat disposant d’un correctif n’est pas couvert) et autofix, la dernière demande le couvrant. Chaque résultat d’image de GET .../code-security/images/findings porte les trois mêmes champs pour les mises à jour d’image de base.

curl -X POST -H "Authorization: Bearer ${FREMFORGE_PAT}" -H "Content-Type: application/json" \
  -d "{\"finding_id\": \"${FINDING_ID}\"}" \
  "https://frem.sh/_app/api/v1/orgs/acme/dependency-updates/security-fixes/requests"

API obsolète

Ces chemins, champs et portées continuent de fonctionner jusqu’au 2027-10-15. D’ici là, chaque réponse d’un chemin obsolète porte Deprecation, Sunset: Fri, 15 Oct 2027 00:00:00 GMT et un en-tête Link avec rel="successor-version" nommant son successeur.

Prendre le relais de Renovate

Tant qu’une organisation n’a pas basculé, les pull requests d’alerte de vulnérabilité propres à Renovate hébergé la servent en parallèle de ce volet (lane_owner: renovate). Lorsque le volet Correctifs de sécurité prend le relais (lane_owner: security_lane), Renovate n’ouvre plus que des mises à jour de version, si bien que chaque correctif n’est proposé qu’une fois. Les pull requests de sécurité Renovate ouvertes sont fermées, avec un commentaire renvoyant vers la pull request de correctif qui les remplace, dès que ce volet a une pull request de correctif pour chaque paquet qu’elles font monter ; d’ici là, elles restent ouvertes.

Pour les clients, la bascule se fait pour l’instant sur demande : contactez le support. fremforge bascule ses propres organisations. L’API est PUT /_app/api/v1/orgs/{org}/dependency-updates/security-fixes/lane avec {"lane_owner": "security_lane"} (ou "renovate" pour revenir en arrière), portée dependency-updates:write ; GET sur le même chemin renvoie la valeur actuelle, ainsi que unsupported_ecosystems (un objet associant chaque écosystème au nombre de résultats corrigeables ouverts que le volet ne corrige pas) et unsupported_total, afin que vous puissiez voir à l’avance si une bascule serait refusée. La prise de relais est refusée tant que le volet ne peut pas agir :

• Les correctifs de sécurité sont désactivés : 409 security-lane-lane-off. Choisissez d’abord un mode autre que Désactivé, ou envoyez "acknowledge": ["no_security_prs"] pour accepter qu’aucune pull request de sécurité ne soit ouverte.
• Des résultats ouverts dans des écosystèmes que le volet ne corrige pas (par exemple CRAN ou Conan, que couvrent les alertes de Renovate) : 409 security-lane-unsupported-ecosystems, dont unsupported_ecosystems liste les résultats corrigeables ouverts par écosystème. Envoyez "acknowledge": ["unsupported_ecosystems"] pour basculer malgré tout ; ces résultats ne reçoivent alors aucune pull request automatique.

Lors de la bascule, les pull requests de correctif de sécurité commencent à suivre Quand les correctifs sont fusionnés, dans les organisations où elles attendaient jusque-là une revue ; voir Fusion.

La bascule est enregistrée dans le journal d’audit sous dependency-updates.security-lane.enabled, et le retour en arrière sous dependency-updates.security-lane.disabled.

Audit

Chaque étape figure dans le journal d’audit : autofix.proposed, autofix.pr_opened, autofix.rejected (avec le motif), autofix.relocked (un commit de fichier de verrouillage depuis votre propre CI, avec l’exécution), autofix.relock_refused (un jeton de tâche qui n’était pas celui de l’exécution lancée), autofix.merged et autofix.closed, chacun avec les clés des résultats et engine: deterministic. Le autofix.proposed d’un correctif connu comme exploité porte aussi knownExploitedCves. Une modification des paramètres est enregistrée sous dependency-updates.security-fixes.updated.

Correctifs IA pour les résultats SAST

Les correctifs générés par IA pour les résultats SAST ont désormais leur propre page : Correctif IA.

Voir aussi

• Mises à jour des dépendances : les deux volets et le bot.
• Fusion : revue, fusion quand tout est vert, fenêtre de fusion et gel des versions.
• Dépannage : lorsqu’aucune pull request n’est ouverte.
• Recommandations OSV : les cartes sur lesquelles se trouve le bouton Ouvrir une demande de correctif.
• Liste de contrôle de mise en place : vos limites et options d’un coup d’œil sous Sécurité › Vue d’ensemble.