Recommandations OSV

L’analyse des dépendances fait remonter des CVE individuelles. L’onglet Recommandations de Sécurité › Résultats › Dépendances (/<org>/_admin/security/findings/dependencies?view=recommendations) transforme cette liste en liste de correctifs : chaque résultat ouvert disposant d’un correctif publié devient une carte, avec repo + package + current → fix + les CVE que cette seule mise à niveau résout.

Comment les recommandations sont calculées

La clé de regroupement est (repo_full_name, ecosystem, package_name, current_version, fixed_version). Les résultats qui partagent ces cinq valeurs sont réunis en une seule carte.

Le tri se fait en trois étapes :

1. Atteignabilité : une carte prend le verdict d’atteignabilité le plus atteignable parmi les résultats qu’elle corrige : d’abord atteignable, puis inconnu (y compris non analysé), puis non atteignable.
2. Gravité (à verdict égal) : critique → élevée → moyenne → faible.
3. Score EPSS (à gravité égale) : le score EPSS le plus élevé parmi les vulnérabilités regroupées l’emporte.

Ainsi, une alerte de faible gravité que votre code atteint passe avant une alerte critique non atteignable, et, à verdict et gravité égaux, une alerte activement exploitée passe avant une alerte théorique. Une carte non atteignable reste listée ; elle descend simplement dans la liste. Les principales recommandations de la vue d’ensemble et le récapitulatif hebdomadaire utilisent le même ordre.

Ce qu’affiche la carte

acme/api                                              critical
  npm:lodash 4.17.20 → 4.17.21
  3 vulns fixed · EPSS 23.4% · CVE-2021-23337, CVE-2020-8203 +1

Une carte dont le verdict est atteignable ou non atteignable affiche aussi Atteignable ou Non atteignable à côté de sa gravité.

• Chemins des manifestes : si le même paquet est épinglé dans package-lock.json et dans pnpm-lock.yaml, les deux sont listés.
• EPSS : la probabilité de prédiction d’exploitation la plus élevée parmi les CVE regroupées (0–100 %). La tâche d’actualisation quotidienne récupère les données EPSS auprès de FIRST.org.
• Identifiants de vulnérabilité : les trois premiers sont affichés en ligne ; les autres sont résumés par +N.

Obtenir la PR de mise à niveau

Chaque carte comporte un bouton Ouvrir une demande de correctif pour les paquets des écosystèmes qui bénéficient des correctifs de sécurité (voir Écosystèmes pris en charge). Il ouvre une pull request qui met à niveau ce paquet dans ce dépôt, sous l’identité du bot de dépendances de votre organisation, et celle-ci attend une relecture ou fusionne une fois ses vérifications réussies, selon le choix de votre organisation ; voir Fusion. Une fois la demande faite, la carte affiche Correctif proposé : n° N avec l’état de la pull request.

Autres moyens d’obtenir la mise à niveau :

• Laisser les mises à jour des dépendances ouvrir les PR. Lorsque les mises à jour des dépendances sont activées, Renovate ouvre une PR de mise à jour de sécurité lors de son exécution nocturne suivant la publication d’une alerte (OSV) pour une dépendance, sans tenir compte de votre schedule ni du délai d’ancienneté de version. Lorsqu’une PR Renovate ouverte met déjà à niveau un paquet, le résultat de l’onglet Résultats renvoie vers elle (Renovate PR #n).
• Déclencher une exécution maintenant. L’onglet Recommandations comporte un bouton Déclencher une exécution de mise à jour des dépendances qui lance une exécution de Renovate hors cycle pour toute l’organisation, au plus une fois par heure. Si les mises à jour des dépendances ne sont pas activées, l’onglet renvoie vers la page où vous pouvez les activer.
• Faire la mise à niveau vous-même. Chaque carte nomme le paquet, la version installée et la version corrigée suggérée : vous pouvez donc faire la modification dans votre propre branche et laisser l’analyse de la PR confirmer que les résultats ont disparu.

L’ancien point de terminaison Ouvrir la PR de mise à niveau reste retiré et répond 410 Gone ; le bouton Ouvrir une demande de correctif le remplace.

Migration nécessaire : le correctif se trouve dans un autre paquet

Certaines alertes n’ont pas de correctif pour le paquet que vous utilisez, mais sont corrigées dans un successeur que l’alerte elle-même nomme : un nouveau chemin de module ou une nouvelle version majeure, ou un paquet renommé. Exemples tirés d’alertes réelles :

Un tel résultat affiche Migration nécessaire vers <package> (corrigé dans <version>) au lieu de « pas encore de correctif », dans les onglets Résultats et Par paquet, dans l’API (needs_migration, voir API des résultats) et dans le récapitulatif hebdomadaire. Il n’apparaît pas dans Recommandations et n’a pas de bouton Ouvrir une demande de correctif : passer à un autre module ou paquet modifie les imports et souvent l’API, c’est donc une modification de code qui vous revient, pas une simple montée de version.

Comment le successeur est choisi :

• L’alerte doit concerner la version installée, et ne lister aucune version corrigée de votre paquet au-dessus de celle-ci. Si votre propre paquet a un correctif, le résultat reçoit ce correctif comme d’habitude.
• Le successeur est un autre paquet du même écosystème que l’alerte liste avec une version corrigée. La version affichée est la plus basse que l’alerte ne concerne pas. Les alias d’une alerte (par exemple un enregistrement Go GO-… et son jumeau GHSA-…) sont lus ensemble.
• Lorsque plusieurs sont listés, Go privilégie la même version majeure que la vôtre (go-jose.v2 vers go-jose/go-jose.v2, pas go-jose/v4), puis la version majeure supérieure la plus basse, et ne propose jamais une version majeure inférieure du même module. Les autres écosystèmes privilégient un nom qui se termine par le vôtre (request vers @cypress/request).
• Lorsque les versions ne peuvent pas être ordonnées, ou qu’aucun autre paquet n’est corrigé, le résultat conserve « pas encore de correctif ». Une alerte qui n’est corrigée nulle part, comme golang.org/x/crypto/openpgp (non maintenu), n’est jamais présentée comme une migration.

Pourquoi ce n’est pas la même chose que l’onglet Résultats

L’onglet Résultats est la source de référence : une ligne par (CVE × manifeste). Les recommandations en sont le résumé exploitable :

• Un paquet sans correctif publié n’apparaît jamais dans Recommandations (il n’est pas encore exploitable).
• Un paquet corrigeable par une seule mise à niveau apparaît une fois dans Recommandations et N fois dans Résultats (une par CVE).
• Un résultat ignoré n’apparaît dans aucun des deux.

Utilisez Résultats pour trier les CVE une à une et les ignorer ; utilisez Recommandations pour piloter le vrai travail de correction de la journée.

Via l’API REST

GET /_app/api/v1/orgs/:slug/security/recommendations (findings:read) renvoie les recommandations elles-mêmes, dans l’ordre de l’onglet : une entrée par dépôt, paquet et version actuelle, avec fixed_version, highest_severity, vulnerability_count, vulnerability_ids, manifest_paths, max_epss, reachability, known_exploited et finding_id, le résultat de la branche par défaut que nomme une demande de correctif de sécurité (null lorsque tous les résultats du groupe se trouvent sur une pull request).

Les résultats CVE sous-jacents, c’est-à-dire les données brutes que regroupent les recommandations, sont disponibles via l’API publique. Utilisez-les pour construire un tableau de bord personnalisé, exporter vers un système de tickets ou piloter la priorisation depuis un agent d’IA.

• Lister les résultats de dépendances GET /_app/api/v1/orgs/:slug/code-security/deps/findings : une ligne par (CVE × manifeste), avec package_name, current_version, fixed_version, severity, vulnerability_id, manifest_path. Regroupez côté client par (repo_full_name, ecosystem, package_name, current_version, fixed_version) pour reproduire le regroupement des recommandations.
• Ignorer un résultat POST /_app/api/v1/orgs/:slug/code-security/deps/findings/:id/dismiss corps : { "reason": "..." }

Le point de terminaison de liste nécessite un jeton d’accès personnel (PAT) avec la portée findings:read ; ignorer un résultat nécessite findings:write :

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  "https://frem.sh/_app/api/v1/orgs/acme/code-security/deps/findings?include_dismissed=false"

Consultez la référence de l’API REST publique pour la spécification OpenAPI complète.

Voir aussi

• Délai de correction (SLA) : comment est calculée la pastille SLA de l’onglet Résultats.
• Récapitulatif de sécurité : envoie chaque lundi par e-mail les 5 principaux résultats corrigeables, les atteignables en premier.
• Protection au push : les secrets bloqués au moment du push, la moitié en amont de la même triade de la chaîne d’approvisionnement.