Les comptes CVE sont-ils un bon indicateur de la sécurité d'un logiciel?
En regardant le nombre de rapports CVE par produit , je suis tenté de l'utiliser comme indicateur des programmes les plus sécurisés et de choisir ceux que j'installe en conséquence.
Mais je me demande si ces chiffres sont trompeurs. Par exemple, le noyau Linux est deuxième dans la liste et Windows 10 n'est même pas mentionné. Je suppose que c'est en partie à cause de la nature open source de Linux, ce qui rend la recherche et la correction des failles plus faciles et plus rapides, augmentant le nombre de CVE.
Une autre chose que je trouve intéressante est que, alors que Chrome a plus de vulnérabilités répertoriées en 2016 que Firefox, il y a beaucoup plus de failles d'exécution de code dans Firefox, tandis qu'une grande partie des failles de Chrome sont des attaques DoS , qui sont beaucoup moins graves.
Peut-on dire qu'un logiciel est "plus sécurisé" qu'un autre, en fonction du nombre de CVE que possèdent ces logiciels?
Peut-on dire qu'un logiciel est "plus sécurisé" qu'un autre, en fonction du nombre de CVE que possèdent ces logiciels?
Non. Les entrées CVE ne sont pas une bonne source pour classer les produits en fonction de leur "sécurité globale".
L'idée principale derrière le système CVE est de créer des identifiants uniques pour les vulnérabilités logicielles. Il n'est pas conçu pour être une base de données complète et vérifiée de toutes les vulnérabilités connues d'un produit. Autrement dit, un fournisseur ou un chercheur pourrait simplement décider de ne pas demander un numéro CVE pour un défaut donné. De plus, les entrées combinent parfois des bogues liés sous un seul ID ou ne divulguent pas l'impact exact, faisant du simple "décompte des bogues" un critère de sécurité plutôt dénué de sens. En outre, pour un classement, vous devez trouver des mesures raisonnables pour comparer les différentes gravités. (Combien de bogues DoS équivalent à une exécution de code à distance ...?)
Cela dit, les CVE vous donnent certainement une idée du type de vulnérabilités détectées dans un produit et constituent un bon point de départ pour la recherche. Mais le montant dépend fortement de l'âge du logiciel et de l'attention qu'il reçoit grâce à l'audit de sécurité. Vous ne pouvez pas vraiment raisonner si un grand nombre d'affectations CVE signifie que le logiciel est mal écrit ou s'il signifie en fait qu'il est particulièrement sécurisé car, de toute évidence, de nombreuses vulnérabilités sont corrigées. Personnellement, j'ai tendance à trouver suspect un produit plus ancien ayant un dossier très court de vulnérabilités corrigées car cela pourrait indiquer qu'il n'a pas été audité à fond.
Vous devriez donc considérer CVE comme n dictionnaire plutôt qu'une base de données qui attribue simplement des poignées aux vulnérabilités afin que vous puissiez les référencer plus facilement - ne l'utilisez pas comme un outil pour comparer la sécurité.
Voici de meilleurs indicateurs pour un produit sécurisé:
- Le logiciel est utilisé et développé activement.
- Le vendeur encourage les gens à rechercher des vulnérabilités (et peut-être même à offrir des primes).
- De nouveaux bogues de sécurité sont traités et corrigés rapidement.
En tant que système volontaire, CVE est aussi ouvert aux abus que les produits logiciels qu'il suit et est souvent très subjectif. Ceci est quelque peu aggravé par le mécanisme de notation utilisé pour suivre la gravité qui est généralement CVSSv2.
Dans un monde idéal, lorsqu'une vulnérabilité est découverte dans un produit, les développeurs enregistrent un CVE, le publiant plus tard avec le correctif qu'ils ont produit pour leur produit.
Cependant, comme d'autres l'ont souligné, parfois les CVE ne sont tout simplement pas créés ou les développeurs prennent un tas de vulnérabilités, coupent une version qui les corrige tous et créent en accompagnant CVE.
Si je suis intéressé par l'utilisation d'un certain produit logiciel et que j'avais des réserves concernant sa sécurité, je suis plus susceptible de regarder comment ils gèrent les problèmes de sécurité, de recevoir des rapports, etc. que de regarder spécifiquement leur base de données CVE.
Une exception à ce qui précède est les produits logiciels qui utilisent d'autres composants, dans ces cas, regarder le temps qu'il a fallu à un produit pour rattraper les CVE émis contre ses produits/services constitutifs peut être instructif. Les logiciels commerciaux qui reconditionnent les composants open source peuvent souvent accuser un retard de plusieurs mois sur les correctifs de sécurité. C'est probablement la chose la plus utile pour laquelle j'utilise la base de données CVE.
CVE ne représente que les bogues des applications que les gens essaient activement d'exploiter. Bien que l'open source puisse ou non être soumis à un volume plus ou moins élevé de CVE, on pourrait raisonnablement supposer qu'il n'implique pas qu'une application est plus ou moins sujette à l'exploitation. Considérez que de nombreux exploits/vulnérabilités sont souvent vendus comme 0 jour avant même d'être considérés comme une entrée CVE. Considérez également que de nombreuses personnes dans la communauté open source tendent davantage vers une divulgation raisonnable que vers le profit. Dans tous les cas, je mesurerais la vulnérabilité de deux applications en fonction de quelques mesures:
- Quelle est la gravité des impacts exploités du passé?
Volume de CVE: comme vous l'avez laissé entendre, plus de CVE impliquent probablement que l'application est auditée plus fréquemment par la recherche sur la sécurité.
Open source: personnellement, je considère l'open source "généralement" plus sûr. Affichez le code source par vous-même et examinez le style de codage. Vous pouvez peut-être trouver vous-même une vulnérabilité.
Peut-être légèrement, mais la relation entre le nombre et la qualité est complexe, voire significative. Les questions utiles à poser concernant le nombre de CVE et leurs implications sur la sécurité/qualité d'un logiciel sont:
Y a-t-il des CVE du tout? Sinon, cela signifie probablement que personne ne se soucie suffisamment de rechercher des bogues de sécurité (c'est-à-dire faible pertinence, pas de haute qualité).
Y a-t-il des CVE répétées pour les mêmes types de bugs année après année? Si c'est le cas, cela signifie que les développeurs/mainteneurs font probablement au maximum le minimum nécessaire pour corriger un bogue spécifique plutôt que de réparer leur base de code dans son ensemble et de réparer les processus qui ont conduit au bogue.
Les CVE sont-elles jugées comparables aux CVE pour d'autres programmes similaires au cours des mêmes années, et sont-elles même raisonnables pour les années où elles ont été trouvées? Par exemple, pour la plupart des langues utilisées pour les applications Web, l'existence de bogues d'injection SQL indique que des API/frameworks complètement incorrects/rétrogrades sont utilisés (c'est-à-dire d'anciens sans instructions préparées). Pour les programmes C, cependant, c'est beaucoup plus difficile à juger; Les résumés CVE sont peu susceptibles de vous dire si un bogue était subtil (et donc "raisonnable" d'apparaître) ou provenait de quelque chose d'idiot et contraire aux pratiques modernes.
Etc. La plupart de ces questions dépendent de plus qu'un simple décompte (bien que certaines puissent éventuellement être modélisées comme des "décomptes dans différentes classes"), donc je suis sceptique que les décomptes aient beaucoup de valeur.