Suport technique et veille technologique

LinuxFr.org : les journaux  -  En sécurité informatique, que valent les identificateurs CVE et les évaluations CVSS ?

 -  Septembre 2023 - 

Un débat (assez récurrent) agite en ce moment le monde de la sécurité informatique à propos de deux choses, les CVE et les CVSS. Commençons par expliquer. Un CVE (« Common Vulnerabilities and Exposures ») est juste un identificateur (par exemple, CVE-2022-4269 désigne une faille de sécurité du noyau Linux permettant à un utilisateur de planter le système). Ce sont juste des identificateurs. Ils permettent de référencer une faille de manière non ambigue et facilitent donc la communication. (« As-tu bien patché les noyaux contre CVE-2022-4269 ? ») Mais il est important de noter qu'ils ne constituent pas une évaluation de la faille ou de son importance. (CVE-2022-4269, par exemple, nécessite une configuration particulière, ne se déclenche pas toute seule et est donc assez peu grave.) Mieux, et c'est un des éléments du débat, on peut créer un CVE même pour une bogue qui n'est pas une faille de sécurité. « Avoir un CVE » n'a donc pas de valeur en soi, c'est juste déclaratif.

On notera qu'il n'existe pas de base unique d'information sur les CVE, il existe de nombreux sites, pas forcément à jour, ne donnant pas forcément beaucoup de détails.

CVSS (Common Vulnerability Scoring System) vise au contraire à fournir une évaluation de la faille. On voit tout de suite qu'on rentre dans un domaine bien plus délicat, où une certaine subjectivité est inévitable.

Le débat est ancien sur ces deux mécanismes, que beaucoup d'experts en sécurité jugent peu efficaces pour leur travail. Certains souhaiteraient par exemple qu'une vraie évaluation soit faite avant d'allouer un CVE (c'est certainement irréaliste, vu le travail que cela représenterait, d'autant plus qu'il faudrait des compétences couvrant tous les aspects de l'informatique). D'autres réclament que seul le fournisseur d'un logiciel puisse fournir une évaluation (comme le CVSS). On voit bien quelle seraient les conséquences, puisque beaucoup de fournisseurs nieraient le problème de sécurité, ou le relativiseraient (cela concerne surtout le logiciel privateur, mais le logiciel libre n'est pas à l'abri de ce risque). À l'inverse, les gens de la sécurité peuvent être tentés de gonfler la gravité d'une faille, qui justifie leur travail (pensez au battage médiatique de vulnérabilités présentées comme « on va tous mourir » et qui ont finalement fait pschiiit).

Le débat a par exemple été relancé par Daniel Stenberg (l'auteur de curl) qui a fulminé contre la « faille »
CVE-2020-19909 alors que cette bogue (bien réelle) n'a aucune conséquence en terme de sécurité. (Déjà discuté sur LinuxFr, hélas avec une traduction de l'anglais faite par une IA ivre.)

Mais je suis sûr que tout·tes les lecteurices de LinuxFr ont un avis sur comment faire mieux :-)

• Le site relativement officiel des CVE,
• L'article de Daniel Stenberg sur CVE-2020-19909 et sa suite,
• Sa critique contre l'organisation NVD et ses évaluations,
• PostgreSQL a râlé aussi,
• Le site de CVSS,
• Une analyse scientifique des incohérences dans l'attribution des CVSS.

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Stéphane Bortzmeyer