Remédiation des CVE : de l'avis au build corrigé et livré

Le processus de remédiation des CVE

La remédiation des CVE consiste à retirer une vulnérabilité divulguée publiquement d'un logiciel que vous exploitez ou livrez. Pour votre propre code, cela passe par un correctif. Pour les dépendances open source, d'où provient l'essentiel des CVE d'un produit type, il s'agit d'atteindre une version où la vulnérabilité est corrigée. Dans les deux cas, les étapes sont les mêmes :

Trouver chaque produit, build et release qui contient le paquet et la version touchés.
Évaluer si la vulnérabilité vous touche, et à quel point.
Prioriser par rapport à tout ce qui reste ouvert.
Corriger par une mise à niveau, un correctif, un remplacement ou, s'il n'existe aucune correction, une atténuation.
Vérifier que la version corrigée est bien celle que contient le nouveau build.
Consigner ce qui était touché, ce que vous avez décidé et quand la correction a été livrée.

Étape 1 : trouver chaque build touché

La première question après un avis est de savoir où se trouve le paquet. Y répondre à partir des dépôts source est lent, et souvent faux : la version d'un lockfile, la version résolue par un build et la version d'une image de conteneur publiée peuvent toutes différer. Les dépendances transitives et les paquets qu'un build télécharge hors du gestionnaire de paquets n'apparaissent tout simplement pas dans les manifestes.

La réponse fiable vient d'une SBOM de chaque release, comparée en continu aux avis. Si cette SBOM est enregistrée pendant le build, elle liste ce que le build a réellement utilisé : la comparaison vous indique ainsi quels builds livrés contiennent la version vulnérable, et non quels dépôts la mentionnent.

Étape 2 : prioriser selon la gravité et l'exploitation

La gravité seule classe trop de vulnérabilités comme urgentes. La plupart des équipes combinent trois signaux :

Signal	Ce qu'il indique	Publié par
CVSS	La gravité de la vulnérabilité si elle est exploitée, notée de 0 à 10	FIRST (la norme) ; la NVD et les éditeurs publient les scores
EPSS	La probabilité estimée d'exploitation dans les 30 prochains jours	FIRST
KEV	Si la vulnérabilité est connue pour être exploitée en conditions réelles	Le catalogue Known Exploited Vulnerabilities de la CISA

Ajoutez ensuite votre propre contexte : le paquet touché est-il livré aux clients ou s'exécute-t-il seulement dans un job de test, et la fonction vulnérable est-elle réellement utilisée ? Une vulnérabilité connue pour être exploitée dans un paquet livré passe en tête de liste. La priorisation des vulnérabilités transforme ces signaux en méthode.

Délais de remédiation

CISA BOD 26-04. Depuis le 10 juin 2026, les agences fédérales américaines fixent chaque échéance à partir de quatre questions : l'actif est-il exposé publiquement, la vulnérabilité figure-t-elle dans le catalogue KEV, l'exploitation peut-elle être automatisée, et donne-t-elle un contrôle partiel ou total ? Les réponses vont de 3 jours, avec un triage forensique pour les cas les plus graves, à une correction lors de la prochaine mise à niveau du système. Cette directive a remplacé la BOD 22-01, qui accordait deux semaines pour la plupart des entrées du KEV.
Cyber Resilience Act de l'UE. Les fabricants doivent traiter et corriger les vulnérabilités sans délai, notamment par des mises à jour de sécurité (annexe I, partie II). Depuis le 11 septembre 2026, une vulnérabilité activement exploitée dans un produit déclenche aussi un délai de signalement : une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans les 14 jours suivant la disponibilité d'un correctif.
Votre propre politique. La plupart des programmes de sécurité fixent des objectifs internes par gravité. Quels qu'ils soient, vous ne pouvez les tenir que si l'étape 1 est rapide.

Étape 3 : choisir la correction

Option	Quand l'utiliser
Mise à niveau	Une version corrigée existe. Préférez la plus petite mise à niveau qui inclut la correction, pour limiter les changements incompatibles.
Mise à niveau du parent	Le paquet vulnérable est transitif. Une version plus récente de la dépendance directe apporte souvent la correction.
Forçage de version	Le parent n'a pas publié de correction. Forcez la version transitive avec les `overrides` de npm, les `resolutions` de Yarn ou `pnpm.overrides`, et testez-la.
Correctif ou backport	Vous ne pouvez pas encore passer à la version majeure corrigée. Appliquez la correction amont à la version que vous utilisez.
Remplacement	Le paquet n'est plus maintenu ou continue de produire des CVE. Passez à une alternative.
Atténuation et documentation	Il n'existe pas encore de correction, ou votre produit n'est pas touché. Réduisez l'exposition et consignez l'évaluation, par exemple sous forme de déclaration VEX.

L'essentiel de cette étape peut être automatisé, du choix de la version à l'ouverture de la pull request. La remédiation automatisée des vulnérabilités précise ce qu'il faut automatiser et ce qu'il faut laisser à une personne.

Étape 4 : une correction fusionnée n'est pas une correction livrée

La pull request est fusionnée, donc la CVE est close. Pas forcément. La correction est dans le dépôt, mais un build restaure un cache obsolète, une image de base contient encore l'ancien paquet, ou une branche de release n'a jamais reçu la modification. Le ticket indique que c'est corrigé alors que le produit livre toujours la version vulnérable.

Bouclez la boucle par l'autre bout : contrôlez la SBOM du build suivant et confirmez que la version vulnérable a disparu. Lorsque cette SBOM enregistre ce que le build a réellement récupéré, y compris les paquets restaurés depuis les caches, ce contrôle répond à la question que posent vraiment le client, l'auditeur et le régulateur.

Comment CRACI soutient la remédiation des CVE

Trouver. CRACI enregistre les paquets récupérés par chaque job GitHub Actions, y compris les dépendances transitives et les paquets restaurés depuis les caches, et réévalue en continu les SBOM surveillées. Les vues d'organisation agrègent les résultats entre builds et dépôts : vous voyez ainsi quels builds une nouvelle CVE touche.
Attribuer. Les équipes de sécurité trient chaque résultat et le transmettent à l'équipe responsable de la correction. CRACI prend en charge VEX pour consigner la façon dont une vulnérabilité touche votre produit.
Vérifier. Chaque nouveau build obtient sa propre SBOM avec un état de complétude : vous pouvez confirmer que la version corrigée est bien celle utilisée par le build.
Signaler. Pour les vulnérabilités activement exploitées relevant du CRA, CRACI soumet les notifications aux autorités au nom du fabricant.

Consultez le suivi des vulnérabilités pour découvrir toutes les capacités.

Remédiation des CVE : questions fréquentes

Qu'est-ce que la remédiation des CVE ?

La remédiation des CVE consiste à retirer une vulnérabilité divulguée publiquement, identifiée par son identifiant CVE, d'un logiciel que vous exploitez ou livrez. Pour une dépendance, cela signifie généralement passer à une version où la vulnérabilité est corrigée. Pour votre propre code, cela signifie le corriger.

Comment prioriser les CVE à corriger en premier ?

Combinez la gravité et les preuves d'exploitation. CVSS décrit la gravité d'une vulnérabilité, EPSS estime la probabilité qu'elle soit exploitée dans les 30 prochains jours, et le catalogue Known Exploited Vulnerabilities de la CISA liste celles qui sont déjà exploitées. Une vulnérabilité connue pour être exploitée dans un paquet que vous livrez passe en tête.

En combien de temps faut-il corriger une CVE ?

Cela dépend de qui le demande. La Binding Operational Directive 26-04 de la CISA donne aux agences fédérales américaines entre 3 jours et la prochaine mise à niveau du système, selon que la vulnérabilité figure ou non dans le catalogue KEV, que l'actif est exposé publiquement ou non, que l'exploitation peut être automatisée ou non, et selon le degré de contrôle qu'elle donne à un attaquant. Le Cyber Resilience Act de l'UE demande aux fabricants de corriger les vulnérabilités sans délai et, depuis le 11 septembre 2026, une vulnérabilité activement exploitée dans un produit déclenche un délai de signalement de 24 heures.

Que faire s'il n'existe pas encore de version corrigée ?

Atténuez et documentez. Désactivez la fonctionnalité touchée, bloquez le chemin d'attaque ou remplacez le composant si vous le pouvez, et consignez votre évaluation, par exemple sous forme de déclaration VEX. Surveillez ensuite la sortie de la version corrigée et appliquez-la dès qu'elle est disponible.

Comment corriger une CVE dans une dépendance transitive ?

Essayez d'abord de mettre à niveau la dépendance directe qui l'amène, car une version plus récente intègre souvent la correction. S'il n'en existe pas encore, la plupart des gestionnaires de paquets permettent de forcer la version d'un paquet transitif : overrides dans npm, resolutions dans Yarn, pnpm.overrides dans pnpm. Testez le résultat, car le paquet parent n'a pas été construit avec cette version.