Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Vous est-il déjà arrivé de voir des codes « CVE- » défiler à l'écran lors de l'installation d'un logiciel et de vous demander ce qu'ils signifiaient ? Vous n'êtes pas le seul ; nous sommes tous passés par là. Ces codes constituent d'importants signaux d'alerte en matière de cybersécurité. Je vais vous présenter la composition d'un identifiant CVE, vous expliquer sa structure et aborder des concepts tels que les « dépendances transitives », ainsi que les bonnes pratiques en matière de correction des vulnérabilités.
Qu'est-ce qu'un CVE ?
Autrefois, les vulnérabilités portaient des noms spécifiques au bug, comme « IIS path traversal », mais au fil des décennies, à mesure que les vulnérabilités s'accumulaient, il est devenu nécessaire de mettre en place un identifiant standardisé.
Un identifiant CVE (Common Vulnerabilities and Exposures) attribue un nom normalisé aux failles de cybersécurité identifiées et connues du grand public. Ce langage commun permet aux professionnels de la sécurité et aux fournisseurs de communiquer rapidement et avec précision sur des vulnérabilités spécifiques. L'identification des CVE dans les logiciels est essentielle – en particulier dans les environnements comportant de nombreux composants externes – car elle permet aux équipes de sécurité de hiérarchiser les correctifs, d'évaluer les risques et de corriger rapidement les défauts avant qu'ils ne soient exploités, protégeant ainsi les données et la disponibilité des systèmes.
On peut considérer un CVE comme un numéro de suivi, un peu comme lorsque vous commandez un colis auprès de votre boutique préférée. C'est un moyen de suivre l'évolution du ou des bogues et de se tenir informé des versions d'un logiciel qui ont été touchées par la vulnérabilité.
Pour un aperçu complet des bonnes pratiques, vous pouvez en savoir plus sur l'application des correctifs CVE dans notre guide détaillé.
La structure d'un CVE
Un identifiant CVE se présente comme suit : «CVE-2025-1111» – le préfixe CVE, suivi de l'année de découverte de la faille, puis d'un identifiant unique.
Ce numéro est attribué par la société MITRE et un réseau mondial comptant plus de 490 CNA. Ces CNA (autorités de numérotation CVE) comprennent des fournisseurs informatiques tels que Microsoft, Red Hat et Oracle, ainsi que diverses organisations et chercheurs en sécurité.
La Base de données nationale sur les vulnérabilités (NVD) a pour mission d'enrichir chaque CVE dès sa publication dans la liste CVE. Concrètement, cela implique un transfert entre MITRE et la NVD, qui enrichit ensuite le CVE avec des métadonnées supplémentaires. Une fois ce transfert effectué, le CVE suit un processus bien défini. Selon NIST, ce processus comprend :
- Examen de la documentation fournie avec le CVE.
- Un CWE (CCommon Weakness Enumeration) est attribué à la vulnérabilité afin de la classer.
- Des indicateurs d'exploitabilité (selon les métriques CVSS v3.1 ou v4.0) et d'impact sont attribués.
- Une déclaration CPE (Common Platform Enumerator) est associée à cette vulnérabilité.
- Enfin, un analyste senior procède à un contrôle qualité avant la publication des données enrichies.
Une fois le CVE publié, d'autres opérations de maintenance pourraient être nécessaires. Il pourrait y avoir des modifications, l'ajout de documents de référence, la mise à jour des descriptions, etc.
Comprendre la vulnérabilité
Lorsque vous exécutez npm audit ou que vous installez simplement un paquet dans votre projet, vous pouvez obtenir un résultat similaire à celui-ci : 7 vulnérabilités de gravité élevée. Vous vous demandez peut-être : « Qu'est-ce que c'est et à quoi ça ressemble ? » Le résultat initial ne répertorie pas les CVE ; il répertorie plutôt les paquets affectés et leurs versions. Voici un exemple du résultat de npm audit lors de l'installation d'Angular v18 (l'image est plus chargée sur les anciennes versions comme Angular 16, où la détérioration des dépendances a eu plus d'un an pour s'accumuler) :
résumé 4.0.0 - 4.58.0 Gravité : élevée Rollup 4 présente une vulnérabilité d'écriture arbitraire de fichiers via un parcours de chemin - https://github.com/advisories/GHSA-mw96-cpmx-2vgc Correction disponible via `npm audit fix --force` Va installer @angular-devkit/build-angular@19.2.22, ce qui constitue une modification majeure node_modules/rollup @angular/build 18.1.0-next.0 - 19.2.21 || 20.0.0-suivant.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17 Dépend des versions vulnérables de rollup node_modules/@angular/build @angular-devkit/build-angular * Dépend de versions vulnérables de @angular/build Dépend de versions vulnérables de copy-webpack-plugin node_modules/@angular-devkit/build-angular
Cela signifie que le package a été installé en tant que dépendance transitive. Les versions concernées sont les suivantes : 4.0.0 à 4.58.0. Ces versions présentent une faille de sécurité de gravité élevée. Cette faille est appelée « Écriture arbitraire de fichiers via un parcours de chemin ». Cela signifie qu’un acteur malveillant peut créer une entrée qui trompe rollup afin qu’il écrive un fichier à des emplacements où vous n’aviez pas l’intention d’écrire. Il s’agit d’un exemple classique de faille de la chaîne d’approvisionnement logicielle. Vous avez installé un paquet, mais Rollup s'est glissé dans l'installation, alors que vous ne l'aviez pas installé intentionnellement.
@angular-devkit/build-angular └── @angular/build (versions vulnérables) └── rollup (4.0.0 - 4.58.0) ← le paquet vulnérable
Corriger les défauts
Si nous continuons à travailler à partir du exemple , il existe plusieurs façons de corriger cette vulnérabilité si vous ne rédigez pas activement de correctifs CVE en tant que développeur d'applications de sécurité. Vous pouvez exécuter npm audit fix –force, ce qui pourrait résoudre le problème, mais cette approche comporte ses propres inconvénients.
Si vous exécutez cette commande, cela mettra également à jour @angular-devkit/build-angular vers la version 19.2.22. Cette version est signalée comme une modification majeure et pourrait affecter les configurations de compilation et les API. Elle pourrait nécessiter des modifications du code par la suite, et qui a le temps pour ça ?
Voici quelques mesures que vous pouvez prendre pour voir comment résoudre le problème :
- Vérifiez votre version d'Angular pour évaluer l'ampleur du changement que représenterait le passage à la nouvelle version.
- Consultez le journal des modifications de @angular-devkit/build-angular pour la version mise à jour.
- Créez une nouvelle branche et appliquez le correctif dans celle-ci, jamais dans la branche principale.
- Prenez-en note et reportez la modification si elle présente un risque trop élevé.
Remplacements
Le recours à une dérogation est une solution temporaire qui peut vous permettre d'avancer, mais qui comporte également des risques. Cela peut imposer une version spécifique et corrigée du package sans avoir à recourir à la mise à niveau radicale de @angular-devkit/build-angular.
Vous pouvez ajouter la version corrigée dans votre package.jsoncomme indiqué ci-dessous. La version indiquée dans l'exemple JSON est la dernière version corrigée en date de février 2026.
{ "overrides": { "rollup": "^4.59.0" } }
Assurez-vous d'exécuter npm install pour installer la version corrigée, puis vérifiez qu'elle a bien été installée en exécutant npm audit. Vous devriez constater que la vulnérabilité a disparu.
Cette solution fonctionne parce que la remplace indique à npm : «quoi qu’il arrive, sans exception, installe ce paquet». Il contournera entièrement l'arborescence des dépendances transitives en utilisant le overrides.
Les redéfinitions constituent une bonne approche lorsque :
- Vous devez absolument livrer, mais vous êtes bloqué par la mise à jour en cours
- Étant donné que la vulnérabilité se trouve dans un outil de compilation et non dans un outil de production, le risque est moindre
- La version a été testée, et il a été confirmé qu'elle fonctionne correctement
Il existe de meilleures façons de procéder, car la champ n'est que temporaire. Vous pouvez accepter ce changement qui rompt la compatibilité tant que vous le testez dans une branche et que les tests sont réussis. S'il n'y a pas de problèmes et que le code a été revu, allez-y. S'il existe un correctif qui ne rompt pas la compatibilité, utilisez-le. Consultez le journal des modifications pour trouver des correctifs majeurs/mineurs qui ne rompront pas la compilation. Une dernière chose à faire est d'évaluer le risque réel.
Comme indiqué ci-dessus, rollup est un outil de build, et non un outil de production, le risque est donc moindre. Il ne s'exécute généralement pas dans les environnements de production. L'utilisation de des peut, au final, créer un faux sentiment de sécurité. Vous ne recevrez plus d'avertissements de la part de npm audit, mais vous introduisez également des modifications non testées dans votre projet/build.
La conclusion est simple : si vous pouvez accepter cette modification qui brise la compatibilité, n'hésitez pas. Si ce n'est pas le cas, utilisez des.
