Le rythme auquel de nouvelles vulnérabilités sont révélées ne cesse d’augmenter. Il s'élève actuellement à une moyenne de 15,000 2022 CVE par an. L’année 26,000 se démarque avec plus de XNUMX XNUMX nouveaux CVE signalés. Évidemment, toutes les vulnérabilités ne concernent pas votre logiciel. Pour déterminer si une vulnérabilité particulière pose problème, vous devez d'abord déterminer si vous utilisez la bibliothèque ou le produit qui contient la vulnérabilité, puis déterminer si vous utilisez la version et le module problématiques de cette bibliothèque. Enfin, vous devez consulter votre équipe de développement pour voir si cette vulnérabilité est pertinente pour votre produit particulier et la manière dont vous avez utilisé cette bibliothèque ou ce produit vulnérable.
Le processus pour comprendre tout cela n’est pas simple et peut prendre beaucoup de temps. Tom Alrich, un expert bien connu en cybersécurité, estime que environ 95 % de tous les CVE présents dans un produit logiciel particulier ne sont pas exploitables. Mais si vous êtes un utilisateur final ou une entreprise sur le point d'intégrer un logiciel tiers dans son système, comment pouvez-vous identifier les 5 % problématiques afin de pouvoir demander une correction ou un correctif approprié ?
C'est là que l'idée de Vulnerability Exploitability Exchange (VEX) arrive. L'objectif de VEX, tel que défini par l'orientation de la National Telecommunications and Information Administration (NTIA) des États-Unis en 2021, est de « fournir aux utilisateurs (par exemple, les opérateurs, les développeurs et les fournisseurs de services) des informations supplémentaires indiquant si un produit est affecté par une vulnérabilité spécifique dans un composant inclus et, s'il est affecté. , si des mesures correctives sont recommandées.
En ce moment, vous vous demandez probablement : comment puis-je obtenir ces documents VEX et commencer à vérifier mes composants ? Eh bien, la réalité de l’utilisation de VEX est, comme d’habitude, compliquée.
Découvrez le but de VEX
En termes simples, VEX est censé répondre rapidement et facilement à la question « ma version de ce logiciel est-elle exploitable par ce logiciel ? vulnérabilité?'.
La réponse à cette question est censée être l’une des quatre options principales :
- Pas affecté: Aucune correction n’est requise concernant cette vulnérabilité.
- Affecté: Des actions sont recommandées pour corriger ou résoudre cette vulnérabilité.
- Fixé: Ces versions de produit contiennent un correctif pour la vulnérabilité.
- Sous enquête : On ne sait pas encore si ces versions de produits sont affectées par la vulnérabilité. Une mise à jour sera fournie dans une version ultérieure.
Étant donné que VEX est censé être à la fois lisible et généré par une machine, l'idée est de disposer d'une base de données consultable de ces documents quelque part afin que toute partie intéressée puisse l'interroger et obtenir la réponse nécessaire.
Puisque l'hypothèse est que 95 % des vulnérabilités ne sont pas exploitables dans un produit logiciel donné, ce système est destiné à réduire les listes massives de vulnérabilités trouvées pour chaque produit à celles que l'utilisateur doit surveiller ou demander une correction ou un correctif. pour.
Il existe un certain nombre de faits intéressants sur l'histoire de VEX
En 2020, la NTIA (l'Administration nationale des télécommunications et de l'information des États-Unis) a commencé à discuter de l'idée de VEX comme outil d'accompagnement du SBOM (Nomelle de matériel du logiciel). En septembre 2021, la NTIA a publié une introduction et une explication d'une page sur ce que VEX est censé faire.
Plus tard, les efforts visant à affiner les exigences du nouveau format consultatif se sont déroulés sous les auspices de la CISA – l'Agence américaine de cybersécurité et de sécurité des infrastructures, qui a publié son propre document début 2022, nous aborderons un peu plus en détail ainsi que certains cas d'utilisation pour lesquels le document VEX était censé aider. Le document, un projet, définissait les champs minimum requis du document VEX de la même manière que la NTIA définissait les champs minimum requis du SBOM.
Depuis lors, il y a eu 2 tentatives majeures pour créer un format de documentation VEX lisible par machine :
- VOTRE Cadre consultatif commun de sécurité (CSAF) était le premier format disponible. Ce format a été publié fin 2022 par OASIS Open, une organisation internationale à but non lucratif dédiée à la production de normes open source pour la cybersécurité, la blockchain, l'IoT et d'autres domaines.
- CycloneDX, un format standardisé pour les SBOM lancé par OWASP (Open Web Application Security Project), qui a été adapté pour créer également des documents VEX.
CSAF est un format complet, mais pour pouvoir l'utiliser avec succès, vous devez inclure plusieurs champs et de nombreuses méta-informations, ce qui rend son adoption réelle peu probable. L'initiative CyclonDX VEX est beaucoup plus mince, donc si l'on considère quelle norme VEX utiliser le plus, il serait probablement préférable de l'utiliser. au format CyclonDX.
Pourquoi VEX a rencontré un obstacle – Découvrir les problèmes qui sabotent son succès
VEX est une bonne idée et pourrait offrir la possibilité précieuse de vérifier rapidement si une vulnérabilité particulière est effectivement exploitable dans un produit logiciel particulier.
Il existe cependant plusieurs problèmes qui étouffent jusqu’à présent sa mise en œuvre :
- Responsabilité du dépôt – qui devrait être chargé du dépôt des documents VEX requis ? Est-ce les producteurs de logiciels ? Entreprises de sécurité tierces ou organisations à but non lucratif ? Une agence gouvernementale ? Que se passerait-il si plusieurs sources déposaient des informations contradictoires ?
- Base de données VEX – qui ou quoi doit sauvegarder et catégoriser les informations VEX ? En supposant que certains documents décrivent des problèmes exploitables dans les logiciels, n'y a-t-il pas un risque que les informations tombent entre de mauvaises mains (malveillantes) ?
- Les formats actuels ne couvrent pas correctement la question des versions et encore moins le problème du versioning combiné.
Les versions combinées de logiciels/packages font référence à la pratique consistant à regrouper plusieurs packages logiciels ou composants dans une seule version ou un seul package d'installation.
En ce qui concerne la correction des vulnérabilités, les versions combinées de logiciels/packages peuvent à la fois faciliter et entraver le processus. D'une part, disposer d'un package d'installation unique comprenant tous les composants nécessaires peut simplifier le processus d'identification et de correction des vulnérabilités. Au lieu de devoir identifier et corriger manuellement chaque composant individuel, vous pouvez simplement appliquer le correctif à l’ensemble du package.
Cependant, le revers de la médaille est que si un composant du package est vulnérable, l’ensemble du logiciel est vulnérable. Cela signifie que même si certains composants du package ont été corrigés, l'ensemble du package peut toujours être menacé si un seul composant non corrigé est présent.
Disons que la version 1 de la bibliothèque A de votre logiciel présente une vulnérabilité. Ce problème ne se manifeste que lorsque la bibliothèque A est présente avec la version 2 de la bibliothèque B. Il existe un correctif de sécurité mais tout le monde ne l'aurait pas installé. Cela signifie que le document VEX relatif à cette vulnérabilité dans votre logiciel doit couvrir toutes les combinaisons possibles du produit, de ses versions, de ses bibliothèques contenues, de leurs versions et des éventuels correctifs publiés. Cela représente beaucoup d’informations complexes qu’il n’est pas facile d’exprimer simplement.
- Comment VEX couvrirait-il les logiciels intégrés au matériel avec toutes les versions et correctifs possibles qui y sont disponibles ? À qui incomberait la responsabilité de corriger ce logiciel étant donné que vous ne pouvez pas facilement ouvrir le matériel et corriger les choses vous-même ?
Ce ne sont là que quelques-uns des problèmes que tout outil automatique permettant de gérer VEX devrait comprendre et prendre en compte.
Ne serait-il pas plus facile si vous pouviez demander et obtenir des informations sur n'importe quelle version ?
L’hypothèse selon laquelle la meilleure façon de partager ces informations importantes consiste à utiliser un document est peut-être erronée. Produire suffisamment de documents VEX pour couvrir toutes les combinaisons de versions, de correctifs et de vulnérabilités est une tâche capitale que, bien entendu, personne ne veut entreprendre.
Scribe a construit une plate-forme pour suivre et partager des informations liées à la sécurité pour chaque version d'un projet ou d'un produit logiciel particulier. Dans ce cadre, chaque build génère un SBOM précis et une liste des vulnérabilités découvertes dans le produit.
Scribe permet au producteur du logiciel d'ajouter des avis au format VEX à chacune de ces vulnérabilités pour indiquer si elles ne sont pas exploitables, font l'objet d'une enquête, etc. Une fois qu'une version est publiée, toutes les informations de sécurité concernant cette version peuvent être partagées avec des tiers intéressés, les utilisateurs. , les régulateurs, etc. L'inclusion de la liste des vulnérabilités ainsi que de la liste consultative VEX signifie que le destinataire doit pouvoir examiner uniquement les vulnérabilités qui constituent un problème potentiel dans ce produit particulier. Cela allège considérablement le fardeau du producteur de logiciels qui peut « mettre son produit sur liste blanche » et du consommateur de logiciels qui comprend exactement quel niveau de risque est impliqué dans un produit logiciel spécifique.
Comme le producteur du logiciel est le seul à pouvoir dire avec certitude si une vulnérabilité particulière est effectivement pertinente pour une version particulière du produit, il est le seul à pouvoir ajouter et modifier des avis sur ses propres produits. Le jugement de l'éditeur du logiciel à cet égard est définitif et incontestable. La décision de savoir avec qui partager ces informations relève également de la prérogative du producteur du logiciel.
Étant donné que l'historique complet des builds du produit, des SBOM et des informations de sécurité est enregistré par Scribe, les utilisateurs peuvent facilement demander et obtenir ces informations pour n'importe quelle version qu'ils pourraient utiliser tout au long du cycle de vie du logiciel.
Conclusion
N’oubliez pas que de nos jours, toute analyse décente d’un produit logiciel produirait des centaines, voire des milliers de vulnérabilités possibles. La plupart des gens ne peuvent pas gérer un tel nombre. La lassitude face aux alertes s’installe et le nombre de vulnérabilités ne devient plus qu’un chiffre.
La possibilité de réduire le nombre de problèmes détectés à un niveau gérable serait une aubaine pour les producteurs et les utilisateurs de logiciels. L’objectif est de se concentrer uniquement sur les problèmes réels afin que le producteur du logiciel puisse les corriger et y remédier le plus rapidement possible.
Des outils automatisés, comme Scribe offrent un moyen simple de voir uniquement les vulnérabilités pertinentes pour chacun de vos projets et builds, des informations que vous pouvez facilement partager, ce qui rend la montagne de vulnérabilités considérablement plus petite et beaucoup plus gérable.
Une mise en garde importante est cependant que cet avenir, dans lequel nous pouvons facilement détecter et répondre uniquement aux vulnérabilités pertinentes, ne serait pas possible sans la participation active de la communauté open source. De nos jours, la plupart du code est composé d'une quantité importante de logiciels open source. Nous avons donc besoin que les responsables et les développeurs de ces bibliothèques participent à la découverte et à la correction des vulnérabilités exploitables qui affectent leur code.
Le problème des vulnérabilités pertinentes et exploitables ne disparaîtra pas, il nous incombe donc à tous de trouver le moyen le plus efficace et le plus rentable d'obtenir la réponse à la question : « ma version de ce logiciel est-elle exploitable pour cette raison ? vulnérabilité'.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
