Faire face à la hausse des CVE avec une petite équipe

Ce qui a changé : les chiffres des CVE

Les chiffres ci-dessous proviennent des enregistrements du CVE Program lui-même, reconstruits chaque jour sur notre page tendances de publication des CVE. D'après l'instantané du 12 nov. 2026 UTC :

• 47 801 enregistrements ont été publiés en 2025, soit 20 % de plus que l'année précédente.
• 95 494 enregistrements ont été publiés en 2026 à ce jour, soit 303 par jour, +131 % par rapport au rythme quotidien de 2025.
• 155 par jour sont classés High ou Critical.
• 17 % des enregistrements publiés depuis 2020 n'ont aucun score CVSS, ni de l'assigneur ni de l'enrichissement de la CISA. La couverture s'est améliorée : en 2026, la part est de 6 %.
• 505 organisations ont attribué ces enregistrements, et les 20 plus importantes en représentent 75 %.

• High ou Critical
• Autres sévérités et sans score

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Moyenne quotidienne des enregistrements publiés chaque année ; * indique l'année en cours à ce jour. Source : enregistrements cvelistV5 du CVE Program, instantané du 12 nov. 2026 UTC. Filtres par mois, sévérité et assigneur : tendances de publication des CVE.

Ce n'est pas un mauvais trimestre. Le nombre augmente chaque année depuis 2020, et plusieurs changements structurels le font continuer à augmenter :

• Plus d'assigneurs, qui attribuent plus largement. Le projet du noyau Linux est devenu CVE Numbering Authority en février 2024. Sa politique documentée consiste à attribuer une CVE à toute correction de bug susceptible d'être une vulnérabilité dès que la correction arrive dans un noyau stable, car l'exploitabilité est souvent incertaine au moment du correctif. La CNA du noyau a publié à elle seule 18 221 enregistrements depuis.
• La découverte assistée par IA. En novembre 2024, Project Zero et DeepMind, chez Google, ont annoncé que leur agent Big Sleep avait trouvé un bug de sécurité mémoire exploitable dans SQLite avant qu'il n'atteigne une version publiée, ce qui constitue selon eux le premier exemple public d'un agent IA y parvenant dans un logiciel largement utilisé. Ce type d'outil augmente ce qu'un seul chercheur peut trouver.
• La NVD ne peut plus tout enrichir. Le NIST indique que la National Vulnerability Database a accumulé à partir de début 2024 un retard de CVE non enrichies, qu'elle n'a pas pu résorber face à la hausse continue des soumissions. En avril 2026, elle est passée à un modèle fondé sur le risque : les CVE du catalogue Known Exploited Vulnerabilities de la CISA et celles qui touchent des logiciels fédéraux ou critiques sont enrichies en priorité, et les autres sont marquées comme non planifiées pour un enrichissement immédiat. Un processus qui dépend des données de produits affectés d'une seule base attend désormais, ou passe à côté.
• Moins de temps pour réagir. Mandiant mesurait un délai moyen d'exploitation de 63 jours en 2018 et 2019. Son rapport M-Trends 2026 l'estime à moins sept jours pour 2025 : l'exploitation commence désormais couramment avant la publication d'un correctif.
• Les échéances réglementaires. Avec le Cyber Resilience Act de l'UE, les fabricants signalent une vulnérabilité activement exploitée par une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final dans les 14 jours suivant la disponibilité d'un correctif (ce qu'exige le CRA). Le délai est le même pour une équipe de trois personnes que pour une équipe de trois cents.

Rien de tout cela ne signifie que les logiciels deviennent moins sûrs. Cela signifie que le nombre d'éléments à examiner augmente chaque année, alors que l'équipe, elle, n'augmente pas.

Ce qui casse dans le processus d'une petite équipe

La hausse des chiffres ne casse pas la gestion des vulnérabilités parce qu'il y a plus de vulnérabilités à corriger. Elle la casse parce que chaque étape manuelle se répète pour chaque CVE.

Étape manuelle	Pourquoi elle échoue avec les volumes actuels
Construire l'inventaire à la main	Un tableur, ou une SBOM produite avant un audit, est périmé dès le lendemain de la release suivante.
Lire le flux	À 155 enregistrements High ou Critical par jour, personne ne suit.
Demander à l'ingénierie « est-ce qu'on utilise X ? »	La même question pour chaque CVE, aux mêmes personnes déjà débordées. C'est la question elle-même qui fait goulot d'étranglement.
Un ticket par CVE et par dépôt	La CVE d'une bibliothèque partagée devient des dizaines de tickets en double qui noient le backlog.
Répondre à chaque client un par un	Les demandes croissent avec la base de clients, pas avec le nombre de vulnérabilités.
Des documents en PDF ou dans un wiki	Les outils des clients ne peuvent pas rapprocher un PDF de leur inventaire : chaque lecteur pose donc à nouveau la question.
Des échéances qui ne bougent pas	Le délai d'exploitation se réduit, tandis qu'un processus manuel ralentit à mesure que le volume augmente.

L'inventaire. La plupart des équipes qui tiennent une liste de composants à la main la mettent à jour avant un audit ou un questionnaire client. Entre ces dates, elle décrit un logiciel qui n'est plus livré. Chaque question sur une CVE commence alors par la reconstitution du contenu de la release.

Le flux. Lire les avis de sécurité est l'étape par laquelle les équipes commencent, et la première à s'effondrer. Des équipes nous disent le faire encore à la main, dont une où le scan des vulnérabilités consiste à lire des forums sur les CVE. Cela fonctionne jusqu'au jour où cela ne fonctionne plus, et rien ne signale ce jour-là.

La question à l'ingénierie. « Est-ce qu'on utilise cette bibliothèque, et dans quelle version ? » interrompt un développeur pour chaque CVE potentiellement concernée. Une équipe de sécurité produit de deux personnes nous a décrit son travail comme du presse-bouton juste pour suivre le rythme, sans aucun temps pour améliorer le processus.

Les tickets. Quand une bibliothèque partagée a une CVE et que chaque dépôt ouvre son propre ticket, le backlog compte plusieurs fois la même décision. Les équipes apprennent à ignorer le backlog, puis ratent le ticket qui comptait.

Les réponses aux clients. Après une vulnérabilité très médiatisée ou une attaque de la chaîne d'approvisionnement, les clients demandent « sommes-nous concernés ? ». Répondre à chacun séparément coûte le plus de temps le jour où l'on en a le moins.

Les documents. Une déclaration en PDF ou une page de wiki doit être lue par une personne côté client. Les scanners des clients, et de plus en plus les régulateurs, attendent des SBOM, des VEX et des avis dans des formats qu'une machine peut rapprocher.

Les échéances. Une alerte précoce due sous 24 heures, ou un exploit qui apparaît avant le correctif, n'attend pas que la file se vide.

Quoi automatiser, dans l'ordre

Chaque étape retire du travail à la suivante : l'ordre compte donc davantage que le choix des outils.

1. Savoir ce que vous livrez. Une SBOM pour chaque build transforme « sommes-nous concernés ? » en simple recherche.
2. Rapprocher en continu, avec plus d'une source. Les nouvelles CVE sont confrontées à chaque SBOM stockée : personne ne lit le flux.
3. Réduire le bruit. Les résultats concernant ce que vous ne livrez pas, et les doublons, n'atteignent jamais un humain.
4. Trier de façon semi-automatique. Les faits sont renseignés ; une personne prend la décision.
5. Tout rendre lisible par machine. Chaque décision est prise une fois et réutilisée par chaque lecteur.
6. Répondre une fois, publiquement. La demande qui n'arrive jamais ne coûte rien.

1. Générer automatiquement une SBOM pour chaque build

Ce que cela remplace : le tableur, et la question à l'ingénierie. Une SBOM générée au moment du build décrit ce que le build a réellement utilisé, et en conserver une par version livrée vous permet de répondre pour la release de l'an dernier comme pour main. Les clients utilisent d'anciennes versions ; votre inventaire doit les couvrir.

Version minimale : une SBOM générée en CI pour chaque build de release, stockée à côté de l'artefact de la release. Mieux : une SBOM enregistrée à partir du build lui-même plutôt que déduite des lockfiles après coup, afin d'inclure aussi les composants récupérés en dehors du gestionnaire de paquets (SBOM générées au build, automatisation des SBOM).

Coût : un ou deux jours de travail sur le pipeline pour la version minimale, puis plus rien par release. Signe que cela fonctionne : pour n'importe quelle release, vous pouvez lister ses composants sans demander à personne.

2. Rapprocher en continu avec plusieurs sources de vulnérabilités

Ce que cela remplace : la lecture du flux. Le rapprochement est le travail d'une machine : chaque nouvelle CVE contre chaque SBOM stockée, pas seulement la SBOM du build qui vient de s'exécuter. Une ancienne release saine au moment de sa livraison devient concernée le jour où une CVE est publiée pour l'un de ses composants.

Une seule source ne suffit pas. Le retard d'enrichissement de la NVD signifie que les données de produits affectés peuvent arriver tard, voire jamais. Les avis des écosystèmes, comme la GitHub Advisory Database et OSV, sont souvent plus rapides et indiquent quelles versions de paquets sont affectées dans les termes propres à l'écosystème. L'EU Vulnerability Database de l'ENISA ajoute le contexte européen.

Version minimale : une tâche planifiée qui rescanne chaque jour toutes les SBOM stockées contre une source agrégée et signale les nouvelles correspondances. Signe que cela fonctionne : vous apprenez qu'une release est concernée avant qu'un client ne vous le dise. Consultez le suivi des vulnérabilités pour voir à quoi cela ressemble dans CRACI.

3. Réduire le bruit avant que quiconque regarde

Ce que cela remplace : l'examen manuel de résultats sans importance. L'essentiel du bruit est produit en amont : par des inventaires qui listent ce que vous ne livrez pas, par plusieurs outils qui signalent la même CVE, et par des dépendances dont personne n'a besoin. Corrigez l'inventaire, comptez chaque résultat une seule fois par package URL (PURL), version et CVE, livrez moins de dépendances, puis ajoutez le contexte d'exploitabilité de CISA KEV, d'EPSS et de VEX. Réduire le bruit des vulnérabilités passe ces leviers en revue un par un. Signe que cela fonctionne : le nombre de résultats par release livrée baisse, et les raisons sont consignées.

4. Trier de façon semi-automatique

Ce que cela remplace : une personne qui rassemble les faits pour chaque résultat. Répartissez le travail précisément :

• Automatique : la sévérité, l'exploitation connue ou non, les produits et versions qui contiennent le composant, l'équipe responsable, une priorité proposée et une échéance.
• Humain : la décision. Corriger, atténuer, accepter avec une date d'expiration, ou marquer comme non concerné avec une justification.

Ce qu'il n'est pas sûr d'automatiser : clore un résultat comme non concerné sans raison consignée. C'est de la suppression, et elle ressurgit lors d'un audit ou d'un incident. Les règles de classement sont traitées dans priorisation des vulnérabilités.

Version minimale : 15 minutes par jour sur une file déjà triée et renseignée. Signe que cela fonctionne : chaque décision a une raison consignée, et rien n'attend que quelqu'un aille chercher une information.

5. Tout rendre lisible par machine

Ce que cela remplace : les PDF, pages de wiki et e-mails qu'une personne doit lire. Publiez les SBOM en CycloneDX ou SPDX (CycloneDX ou SPDX), les décisions « non concerné » en VEX, et les avis en CSAF. Les scanners des clients et les régulateurs peuvent alors les exploiter sans intervention humaine : chaque décision est prise une fois et réutilisée par tous ceux qui la demandent.

Version minimale pour une petite équipe : des SBOM et des VEX sur demande, depuis un emplacement stable ; du CSAF quand les clients commencent à le demander. Signe que cela fonctionne : les outils des clients cessent de signaler ce à quoi vous avez déjà répondu.

6. Répondre une fois, publiquement

Ce que cela remplace : un fil d'e-mails par client. Publiez un avis ou une page de statut pour chaque CVE importante, avec les versions affectées et corrigées, et gardez un modèle de réponse qui y renvoie. Le guide répondre à « sommes-nous concernés par cette CVE ? » montre comment établir la réponse. Pour la réponse elle-même, comment répondre aux clients après une attaque de la chaîne d'approvisionnement propose des modèles de réponse. La demande la moins chère est celle qui n'arrive jamais. Signe que cela fonctionne : la plupart des demandes reçoivent un lien pour réponse.

Ensuite, corriger

Les pull requests automatiques de mise à jour des dépendances font avancer le travail de routine ; regroupez-les par semaine ou par release pour que la revue reste gérable. Mettre à niveau un paquet en amont élimine souvent plusieurs dépendances transitives vulnérables d'un coup, et coûte moins cher que de corriger chacune d'elles (remédiation automatisée des vulnérabilités). Empêchez ensuite les composants connus comme vulnérables de revenir grâce à des policy gates qui bloquent le build.

Un plan selon la taille de l'équipe

Les heures sont des estimations illustratives pour la planification, pas des benchmarks.

	Une personne, à temps partiel	Une fonction sécurité ou PSIRT de 2 à 5 personnes	Une équipe plus grande
À automatiser d'abord	Étapes 1 et 2 : une SBOM par build et un rapprochement continu	Étapes 1 à 3, puis l'attribution aux responsables de l'étape 4	Les six, avec des policy gates dans chaque pipeline
Reste manuel	La décision sur chaque résultat High ou Critical ; les réponses aux clients à partir d'un modèle	Les décisions, les justifications VEX, les avis pour les CVE importantes	Les décisions, les exceptions et le processus lui-même
Temps hebdomadaire, illustratif	2 à 4 heures	4 à 8 heures par personne	Déterminé par le volume de décisions, pas par le flux

Si vous avez déjà un PSIRT, le même ordre s'applique ; le modèle de processus complet se trouve dans le cycle de vie de la gestion des vulnérabilités. Pour les demandes de clients qui se multiplient à chaque CVE, consultez faire passer un PSIRT à l'échelle.

Comment savoir si cela fonctionne

• Le délai entre la publication d'une CVE et le verdict « concerné » ou « non concerné », par produit.
• La part des demandes clients traitées à partir de contenus publiés.
• Le nombre de résultats par release livrée, pas par scan.
• La part des décisions assorties d'une raison consignée.
• Les heures hebdomadaires consacrées aux vulnérabilités, et si elles diminuent.

Mesurez d'abord votre propre point de départ. Il n'existe pas de benchmark sectoriel fiable pour ces indicateurs, et nous n'en citons aucun.

Recruter, acheter ou changer le processus ?

• Recrutez quand le travail consiste à corriger des vulnérabilités dans votre propre code, ou à mener un travail de sécurité face aux clients qui demande du discernement.
• Achetez des outils pour les étapes qui se répètent pour chaque CVE : les étapes 1, 2, 3 et 5.
• Changez le processus pour la responsabilité et les échéances : qui décide, et pour quand.

Soyez honnête sur ce dernier point. Un outil sans responsable produit un tableau de bord que personne ne lit.

La place de CRACI

CRACI automatise les étapes 1 et 2, et une partie des étapes 3 et 4, pour les logiciels construits dans GitHub Actions. Il remplace vos runners hébergés par GitHub et, à l'exécution de chaque job, enregistre les paquets que le job a réellement récupérés, y compris les paquets restaurés depuis les caches CI et les dépendances cachées qu'aucun lockfile ne liste.

• Une SBOM pour chaque build. La SBOM de chaque job identifie chaque composant par son PURL et porte un état de complétude : vous savez quand quelque chose n'a pas pu être vu. L'historique des builds conserve chaque build passé avec sa SBOM, pour que vous puissiez voir quels builds contenaient une dépendance vulnérable, directe ou transitive.
• Rapprochement continu. Les SBOM surveillées sont réévaluées en continu, et les résultats sont agrégés entre builds et dépôts : la CVE d'une bibliothèque partagée apparaît comme un seul problème, pas quarante.
• Notifications et gates. CRACI informe les personnes concernées d'une vulnérabilité et de sa sévérité, et les policy gates peuvent arrêter un build en temps réel, y compris un build qui contient une CVE précise.
• Tri et attribution. Les équipes de sécurité trient les résultats dans CRACI et transmettent chacun à l'équipe responsable de la correction.
• Des SBOM lisibles par machine. Les SBOM s'exportent en CycloneDX ou SPDX, et CRACI prend en charge VEX.

CRACI ne publie pas d'avis, ne propose pas d'analyse d'atteignabilité et ne scanne pas votre propre code. Il facture uniquement les minutes de build : $0.002 par minute de vCPU ($0.004 pour un runner par défaut de 2 vCPU), mesurées à la seconde, sans abonnement mensuel, sans frais par SBOM et sans frais de licence pour le moment. Consultez les tarifs.

Automatisez les deux premières étapes dès aujourd'hui : exécutez vos builds sur CRACI. Nous accompagnons personnellement chaque équipe lors de son onboarding avant la disponibilité générale.

Quand CRACI n'est pas la bonne réponse

• Votre logiciel n'est pas construit dans GitHub Actions. GitLab CI et Jenkins figurent sur la roadmap.
• Votre exposition concerne surtout l'infrastructure : serveurs, postes de travail et configuration cloud. Les outils de gestion des vulnérabilités d'infrastructure conviennent mieux.
• Vous intégrez un firmware tiers que vous ne construisez pas. Les outils d'analyse binaire conviennent mieux.
• Votre backlog est surtout composé de résultats réels et exploitables dans votre propre code. C'est un problème de capacité de remédiation, pas un problème d'automatisation.

Automatisation de la gestion des vulnérabilités : questions fréquentes

Pourquoi y a-t-il tellement plus de CVE aujourd'hui ?

Davantage d'organisations attribuent des CVE, et certaines les attribuent largement : le noyau Linux est devenu CVE Numbering Authority en 2024 et en attribue une à toute correction de bug susceptible d'être une vulnérabilité. Les outils assistés par IA trouvent plus de bugs par chercheur. 47 801 enregistrements ont été publiés en 2025, et 2026 en compte 303 par jour. La tendance dure depuis des années.

Comment une petite équipe peut-elle suivre les nouvelles CVE ?

En ne les lisant pas. Générez une SBOM pour chaque build, rapprochez automatiquement les nouvelles CVE de chaque SBOM stockée, réduisez le bruit, et laissez les humains prendre uniquement les décisions sur ce qui reste. Une petite équipe suit le rythme en supprimant les étapes qui se répètent pour chaque CVE, pas en travaillant plus vite.

Que faut-il automatiser en premier dans la gestion des vulnérabilités ?

L'inventaire : une SBOM générée en CI pour chaque build de release, stockée avec la release. Toutes les étapes suivantes en dépendent, et elle transforme « sommes-nous concernés ? » d'une question à l'ingénierie en simple recherche. Le rapprochement continu avec ces SBOM vient en second.

Faut-il une équipe sécurité pour gérer les vulnérabilités ?

Pas pour commencer. Une personne responsable du processus à temps partiel peut le faire tourner si l'inventaire, le rapprochement et la réduction du bruit sont automatisés. Il vous faut un responsable nommé et des échéances plus qu'une équipe. Recrutez quand le travail devient la correction de votre propre code ou un travail de sécurité face aux clients.

Comment savoir quelles nouvelles CVE touchent notre produit ?

Conservez une SBOM pour chaque version livrée et revérifiez-les toutes à chaque publication de nouvelles CVE, avec plus d'une source de vulnérabilités. Une CVE vous concerne lorsqu'elle correspond à un composant et à une version que vous livrez réellement. Le contexte d'exploitabilité et VEX indiquent ensuite si elle compte.

Que signifie « lisible par machine » pour les SBOM, les VEX et les avis, et pourquoi est-ce important ?

Cela désigne un format structuré standard qu'un outil peut analyser : CycloneDX ou SPDX pour les SBOM, VEX pour les déclarations « non concerné », CSAF pour les avis. Le scanner d'un client peut les rapprocher de son inventaire sans que personne ne les lise : une décision prise une fois est réutilisée par chaque client et chaque outil.

Quelle part du tri peut-on automatiser sans risque ?

La collecte des faits : la sévérité, le statut d'exploitation, les produits et versions qui contiennent le composant, le responsable, une priorité proposée et une échéance. La décision elle-même doit rester à une personne. Ne clôturez jamais automatiquement un résultat comme non concerné sans raison consignée.

De combien de temps dispose-t-on pour réagir à une CVE critique ?

Moins que ce que la plupart des processus supposent. Le rapport M-Trends 2026 de Mandiant estime le délai moyen d'exploitation en 2025 à moins sept jours, c'est-à-dire une exploitation avant l'existence d'un correctif. Avec le Cyber Resilience Act de l'UE, une vulnérabilité activement exploitée exige une alerte précoce sous 24 heures. Fixez votre propre échéance selon la sévérité et l'exploitation, et mesurez-vous par rapport à elle.