VDR, VEX, OpenVEX et CSAF
26 juin 2023
Interlynk
La transparence des logiciels a reçu une impulsion tant attendue et nécessaire. La Software Bill of Materials (SBOM) vise à devenir l'artéfact clé pour la transparence des logiciels et la coordination des vulnérabilités au sein et entre les organisations. Alors que les formats SBOM contiennent des détails nécessaires, y compris les composants logiciels et leurs origines, un bon SBOM peut être utilisé pour suivre et surveiller les vulnérabilités connues dans le logiciel.
La liste des composants SBOM peut être utilisée avec des bases de données de vulnérabilités (par exemple, NVD) pour créer une liste de vulnérabilités pour le produit.
Cependant, le SBOM à lui seul peut ne pas encoder suffisamment de détails pour séparer les vulnérabilités non exploitables de celles exploitables. Cela peut mener à un nouveau flux de bruit dans un environnement déjà bruyant de points de données de sécurité.
Les premiers adopteurs du SBOM ont compris cela et ont proposé de nouvelles normes ainsi que des mises à jour aux normes existantes pour spécifier le statut de chaque vulnérabilité aux côtés du SBOM lui-même. Dans ce contexte, des pratiques existantes telles que VDR, CSAF, et les normes émergentes VEX et OpenVEX jouent un rôle clé.
VDR : Rapport de divulgation de vulnérabilité
Le VDR est la liste des vulnérabilités connues publiées par le fournisseur de logiciels. Un document typique liste les vulnérabilités, les CVE associés, le CVSS, l'impact, le calendrier et les stratégies d'atténuation, ainsi que les informations de contact au sein du fournisseur. Le VDR n'est pas conçu pour une consommation programmatique, et le format réel (HTML, Excel, PDF, CSV) peut varier selon l'organisation.
Exemple de rapport de divulgation de vulnérabilité chez Invicti
NIST-800–161r1 : Pratiques de gestion des risques liés à la chaîne d'approvisionnement en cybersécurité pour les systèmes et les organisations recommande le rôle suivant pour le VDR afin de démontrer une compréhension détaillée et une gestion proactive des vulnérabilités.
Les entreprises, lorsque cela est applicable et approprié, peuvent envisager de fournir
aux clients un rapport de divulgation de vulnérabilité (VDR) pour démontrer
des évaluations correctes et complètes des vulnérabilités pour les composants listés dans
les SBOM. Le VDR devrait inclure l'analyse et les conclusions décrivant l'
impact (ou l'absence d'impact) que la vulnérabilité signalée a sur un
composant ou un produit. Le VDR devrait également contenir des informations sur les plans
pour traiter le CVE. Les entreprises devraient envisager de publier le VDR
dans un portail sécurisé accessible aux clients et de signer le VDR avec
une clé privée vérifiable et de confiance qui inclut un horodatage indiquant
la date et l'heure de la signature du VDR et du VDR associé. Les entreprises
devraient également envisager d'établir un canal de notification séparé pour
les clients dans les cas où des vulnérabilités surviennent qui ne sont pas divulguées
dans le VDR. Les entreprises devraient exiger de leurs principaux sous-traitants d'
implémenter ce contrôle et de transmettre cette exigence aux sous-traitants concernés.
Les rapports de VDR signalent les vulnérabilités connues du produit mais n'ont pas de relation directe avec le SBOM
Alors qu'en théorie, le VDR peut décrire l'état de chaque vulnérabilité, l'absence de norme de reporting commune rend son utilisation moins pratique pour une consommation programmatique et, par conséquent, un goulet d'étranglement dans l'évaluation de l'exploitabilité des vulnérabilités.
VEX : Échange sur l'exploitabilité des vulnérabilités
Le concept de VEX a évolué au sein du même groupe multistakeholder de la NTIA qui a formalisé les recommandations SBOM dans L'encadrement des SBOM et Les Éléments Minimaux de SBOM. VEX n'est pas encore formalisé, mais sa proposition vise à partager une assertion sur le statut d'une vulnérabilité dans des produits ou versions spécifiques. Le statut peut être - Non Affecté, Affecté , Réparé , En Cours d'Investigation.
VEX : Document Unique couvrant Plusieurs Produits, Plusieurs Vulnérabilités, Plusieurs Statuts
Plus tôt cette année, le groupe de travail a également convenu des Exigences Minimales pour VEX, où chaque document VEX est décrit comme un ensemble d'énoncés VEX, chaque énoncé ayant un statut pour une vulnérabilité.
Document VEX et Énoncés des Exigences Minimales pour VEX
En d'autres termes, lorsque SBOM et VEX sont utilisés ensemble, un SBOM bien décrit peut être cartographié à des composants et des vulnérabilités possibles, tandis que VEX peut être utilisé pour réduire le nombre de vulnérabilités réellement applicables. Un membre de la communauté l'a bien décrit comme “D'abord, SBOM allume tous les feux pertinents, et VEX éteint tous ceux qui ne sont pas nécessaires.”
Variétés VEX : VEX1 intégré dans SBOM pour éteindre certains statuts, VEX2 publié plus tard pour éteindre une vulnérabilité nouvellement découverte, VEX3 publié plus tard pour déclarer un travail en cours sur une vulnérabilité différente
Bien que ce ne soit pas strictement nécessaire, un document VEX est destiné à être un compagnon direct au SBOM. VEX peut être directement intégré dans CycloneDX 1.4 et est inclus dans le profil Sécurité de la version candidate SPDX 3.0. VEX est également un profil dans la version 2.0 de CSAF (voir CSAF ci-dessous).
OpenVEX : échange d'exploitation de vulnérabilité ouverte
OpenVEX est une implémentation de VEX conçue pour être interopérable et intégrable. Bien que VEX, en principe, ait fourni un mécanisme pour communiquer l'état des vulnérabilités aux côtés du SBOM lui-même, l'intégration de ces états n'était pas possible en dehors de CycloneDX ou CSAF. OpenVEX vise à être agnostique par rapport à la spécification du SBOM et agit comme une alternative à VEX avec un schéma formel déjà en place.
Exemple OpenVEX
CSAF : Cadre commun des avis de sécurité
OASIS CSAF est une spécification ouverte pour la "création, la mise à jour et l'échange interopérable d'avis de sécurité sous forme d'informations structurées sur les produits, les vulnérabilités et le statut de l'impact et de la remédiation."
En d'autres termes, CSAF rend la divulgation des vulnérabilités et leur impact accessible de manière programmatique. Cependant, CSAF vise à être significativement plus qu'une divulgation et une coordination des vulnérabilités. Depuis la version 2.0, approuvée en novembre 2022, CSAF prend en charge cinq profils différents :
CSAF de base (par défaut)
Réponse aux incidents de sécurité (pour des incidents de sécurité tels que des fuites)
Avis d'information (pour des informations non liées aux vulnérabilités comme la mauvaise configuration)
Avis de sécurité (pour des informations sur les vulnérabilités)
VEX (pour des informations sur l'exploitabilité des vulnérabilités)
Un CSAF Avis de RedHat déclarant une vulnérabilité dans OpenShift
Meilleures pratiques
La divulgation des vulnérabilités par le biais de VDR est une pratique bien établie, et CSAF s'est amélioré depuis 2017 également (par exemple, Red Hat CSAF). VEX et OpenVEX visent à être des compagnons directs de SBOM pour contrôler le bruit de vulnérabilité. Cependant, il n'y a pas de spécification formelle pour VEX (en dehors des exemples de CISA), et OpenVEX est toujours v0.0.0 à la fin de juin 2023. En d'autres termes, la divulgation du statut des vulnérabilités aux côtés de SBOM reste un domaine actif.
Chez Interlynk, nous recommandons les processus suivants pour démontrer les meilleures pratiques de sécurité et limiter le bruit de vulnérabilités dans l'organisation :
1. Construire SBOM par version : De nombreux outils générateurs de SBOM, y compris ceux en open-source, peuvent générer SBOM à partir de graphiques de dépendance, CI/CD, analyses d'images ou analyses de composition logicielle. Pour les produits assemblés avec des projets sous-jacents, utilisez un outil tel que sbom-assemble pour assembler et suivre le SBOM pour le produit final.
2. Stocker et suivre le SBOM : Bien qu'il soit possible d'obtenir une certaine valeur à partir des SBOM à travers des outils tels que sbom-grep, un système formel (tel que SBOM Link) peut faciliter la connexion du SBOM aux vulnérabilités connues et conserver les artefacts pour l'avenir.
3. Enregistrer le statut des vulnérabilités : Pour chaque version de produit, utilisez un système pour enregistrer le statut des vulnérabilités clés identifiées par l'analyse du SBOM. La définition de vulnérabilité clé variera en fonction de la portée de l'application et de la tolérance au risque de l'organisation. Cependant, au minimum, les organisations devraient se préparer à avoir un enregistrement des vulnérabilités signalées comme Critique ou Élevé. L'objectif final devrait être de capturer l'état de chaque vulnérabilité clé en un seul endroit agnostique aux spécifications. Cela facilitera la traduction vers des normes telles que CycloneDX VEX, OpenVEX et SPDX3.0 ou CSAF si nécessaire.
4. Publier le produit avec le SBOM ET les statuts de vulnérabilités/VDR : Une version de produit incluant SBOM devrait également inclure un document de statut de vulnérabilité. Un SBOM sans la divulgation du statut de vulnérabilité est susceptible de créer un bruit inutile. Si l'organisation produit des avis de sécurité via CSAF, alors c'est un excellent endroit pour les divulgations de statut de vulnérabilité. Sinon, les statuts peuvent être intégrés dans CycloneDX 1.4, SPDX 3.0 (bientôt disponible), ou inclus avec le SBOM avec OpenVEX.
5. Publier VEX pour les vulnérabilités récemment découvertes : Si une vulnérabilité nouvellement signalée s'applique à un produit précédemment publié, une ou plusieurs nouvelles VEX doivent être générées pour enregistrer l'analyse de la vulnérabilité par rapport au produit. Nous recommandons de commencer par « En cours d'étude » dès que possible et de mettre à jour à mesure que la portée de la vulnérabilité est trouvée. Notez que nous NE RECOMMANDONS PAS de générer un statut de vulnérabilité pour toutes les vulnérabilités nouvellement signalées. Au lieu de cela, nous recommandons de se concentrer sur les vulnérabilités découvertes dans l'un des composants inclus dans le SBOM précédemment publié. C'est pourquoi le stockage et le suivi du SBOM sont une partie vitale de la pratique.
La transparence logicielle via SBOM a le potentiel d'attirer l'attention et les ressources nécessaires aux pratiques de sécurité pendant le développement. Cependant, la gestion des vulnérabilités a été un problème gourmand en ressources même avant que le SBOM ne devienne partie de la conversation. VEX et les spécifications liées visent à ne pas causer de stress supplémentaire aux équipes de sécurité et à désactiver des alertes inutiles. Cela reste un travail en cours, mais les organisations peuvent toujours construire des pratiques robustes autour de cela pour minimiser les distractions.