Mise en œuvre des exigences minimales pour VEX
Ingénierie
Le Bill of Materials Software (SBOM) est freiné par la qualité du SBOM et des bruits spécifiques aux vulnérabilités. La CISA a recommandé de créer des informations VEX avec les exigences minimales pour l'échange de l'exploitabilité des vulnérabilités pour s'attaquer à ce dernier.
Le document des exigences minimales VEX recommande d'inclure des champs dans le VEX intégré dans un SBOM ou en tant que document autonome.
Dans un post précédent, nous avons mis l'accent sur le détail de la situation de CycloneDX VEX, OpenVEX et CSAF en relation avec la divulgation des vulnérabilités.
Dans ce post, nous décomposons les mappages de champs des exigences minimales vers CycloneDX VEX et OpenVEX.
Exigences minimales pour VEX
VEX, un acronyme pour Vulnerability Exploitability eXchange, est un format de données structuré qui facilite l'échange d'informations sur les vulnérabilités entre les fournisseurs de logiciels, les analystes en sécurité et les consommateurs. Il vise à relever les défis associés aux avis de vulnérabilités hérités, qui manquent souvent de lisibilité machine et ne parviennent pas à indiquer si une vulnérabilité est réellement exploitable dans un produit ou un environnement donné.
Le document des exigences minimales de CISA pour VEX définit les éléments minimaux indépendamment du format ou de la spécification VEX, avec un accent sur la lisibilité machine.
Il décrit un document VEX divisé en Métadonnées du document VEX et au moins une Déclaration VEX, qui à son tour se compose de Métadonnées de la déclaration, Statut, Détails de la vulnérabilité et Détails du produit.
Métadonnées du document
DOIT inclure ID du document, une ou plusieurs versions du document, Auteur, Horodatage du premier émetteur, et Horodatage de la dernière mise à jour.
PEUT inclure Outils et Rôle de l'auteur
Métadonnées de la déclaration VEX
DOIT inclure ID de la déclaration, Version de la déclaration, Horodatage du premier émetteur, Horodatage de la dernière mise à jour
Produit de la déclaration VEX
DOIT inclure ID du produit et Fournisseur
PEUT inclure ID de sous-composant
Vulnérabilité de la déclaration VEX
DOIT inclure ID de la vulnérabilité et description
Statut de la déclaration VEX
DOIT inclure Statut de la vulnérabilité et conditionnellement DOIT inclure Justification (pour le statut Non concerné) ou Déclaration d'impact (pour le statut Non concerné mais sans Justification). Cela DOIT conditionnellement inclure une Déclaration d'action pour le statut Concerné.
PEUT inclure Horodatage de la déclaration d'impact ou d'action et PEUT inclure Notes de statut
Exigences minimales dans CycloneDX
CycloneDX a inclus des vulnérabilités et leur analyse en tant que champs avec la version 1.4 et les a élargis avec la version 1.5. Par conséquent, CycloneDX est une spécification naturelle pour intégrer les informations VEX avec le SBOM.
Cependant, certaines mappages de champs peuvent ne pas être évidents à première vue.
Interlynk recommande de mettre en œuvre les Exigences Minimales pour le VEX avec CycloneDX comme suit :
Métadonnées du document
ID du document : [Requis] Numéro de série
Version du document : [Requis] Version
Auteur : [Requis] Auteurs de métadonnées
Horodatage de la première émission : [Requis] Analyse de vulnérabilité première émission (Version 1.5+)
Horodatage de la dernière mise à jour : [Requis] Analyse de vulnérabilité dernière mise à jour (Version 1.5+)
Outils : [Optionnel] Outils de métadonnées (Remarque : CycloneDX a également une section Outils des vulnérabilités, mais celle-ci est conçue pour lister les outils d'identification et d'analyse des vulnérabilités).
Rôle de l'auteur : [Optionnel] Non mappé
Métadonnées de l'énoncé VEX
ID de l'énoncé : [Requis] Analyse des vulnérabilités Bom-Ref
Horodatage de la première émission : [Requis] Analyse de vulnérabilité première émission (Version 1.5+)
Horodatage de la dernière mise à jour : [Requis] Analyse de vulnérabilité dernière mise à jour (Version 1.5+)
Produit de l'énoncé VEX
ID du produit : [Requis] Analyse des vulnérabilités Affecte Ref
Fournisseur : [Requis] Fournisseur de composants où le bom-ref du composant est le même que l'ID du produit (Produit/Composant affecté)
ID du sous-composant : [Optionnel] Analyse des vulnérabilités Affecte Ref
Vulnérabilité de l'énoncé VEX
ID de vulnérabilité : [Requis] ID de vulnérabilité
Description de la vulnérabilité : [Requis] Description de la vulnérabilité
État de l'énoncé VEX [Requis]
État “Non affecté” : État de l'analyse de vulnérabilité : non_affecté
État “Affecté” : État de l'analyse de vulnérabilité : exploitable
État “Résolu” : État de l'analyse de vulnérabilité : résolu
État “En cours d'investigation” : État de l'analyse de vulnérabilité : en_triage
Notes sur l'état : [Optionnel] Détail de l'analyse de vulnérabilité
Justification de l'énoncé VEX [Conditionnellement Requis]
Justification “Composant_non_présent” : Justification de l'analyse de vulnérabilité : nécessite_dépendance
Justification “Code_vulnérable_non_présent” : Justification de l'analyse de vulnérabilité : code_non_présent
Justification “Code_vulnérable_non_dans_chemin_d'exécution” : Justification de l'analyse de vulnérabilité : code_non_atteignable
Justification “Code_vulnérable_ne_peut_pas_être_controlé_par_l'adversaire” : Justification de l'analyse de vulnérabilité : nécessite_environnement
Justification “Des_atténuations_en_ligne_existent_déjà” : Justification de l'analyse de vulnérabilité : protégé_par_un_controle_atténuant
Déclaration d'impact de l'énoncé VEX
Déclaration d'impact : [Conditionnellement Requis] Détail de l'analyse de vulnérabilité (Remarque : CycloneDX vulnérabilité>analyse>détail est décrit comme Description détaillée de l'impact y compris les méthodes utilisées lors de l'évaluation. Si une vulnérabilité n'est pas exploitable, ce champ doit inclure des détails spécifiques sur pourquoi le composant ou le service n'est pas affecté par cette vulnérabilité. Ceci correspond à la note CISA de la Déclaration d'impact : Pour [état] “non_affecté”, si [justification] n'est pas fournie, alors une déclaration VEX DOIT fournir un [déclaration_d'impact] qui explique comment ou pourquoi les [id_produit] listés sont “non_affectés” par [vul_id].)
Horodatage de la déclaration d'impact : [Optionnel] Analyse de vulnérabilité dernière mise à jour (Version 1.5+)
Déclaration d'action de l'énoncé VEX
Déclaration d'action : [Conditionnellement Requis] Recommandation de vulnérabilité (Remarque : CycloneDX vulnérabilité>recommandation est décrit comme Recommandations sur la manière dont la vulnérabilité peut être corrigée ou atténuée. Ceci correspond au rôle suggéré par la Déclaration d'action de CISA : Pour l'état “affecté”, une déclaration VEX DOIT inclure une [déclaration_d'action] qui DOIT décrire les actions à prendre pour remédier ou atténuer [vul_id].)
Horodatage de la déclaration d'action : [Optionnel] Analyse de vulnérabilité dernière mise à jour (Version 1.5+)
Exigences minimales dans OpenVEX
La spécification OpenVEX a été mise à jour en parallèle avec le groupe de travail CISA rédigeant le document des exigences minimales, et par conséquent OpenVEX fournit la correspondance la plus directe aux champs référencés.
Métadonnées du document
ID du document : [Requis] @id
Version du document : [Requis] version
Auteur : [Requis] auteur
Date de première publication : [Requis] timestamp
Date de dernière mise à jour : [Requis] last_updated
Rôle de l'auteur : [Optionnel] rôle
Outils : [Optionnel] outillage
Métadonnées de la déclaration VEX
ID de la déclaration : [Requis] statements:@id
Date de première publication : [Requis] statements:timestamp
Date de dernière mise à jour : [Requis] statements:last_updated
Produit de la déclaration VEX
ID du produit : [Exigence] products:@id
Fournisseur : [Requis] fournisseur
ID du sous-composant : [Optionnel] subcomponents:@id
Vulnérabilité de la déclaration VEX
ID de vulnérabilité : [Requis] vulnerbilities:@id
Description de la vulnérabilité : [Requis] vulnerabilities:description
État de la déclaration VEX [Requis]
État “Non affecté” : statements:status:not_affected
État “Affecté” : statements:status:affected
État “Fixé” : statements:status:fixed
État “En cours d'investigation” : statements:status:under_investigation
Notes d'état : [Optionnel] statements:status_notes
Justification de la déclaration VEX [Conditionnellement Requis]
Justification “Composant_non_present” : statements:justification:component_not_present
Justification “Code_vulnérable_non_present” : statements:justification:vulnerable_code_not_present
Justification “Code_vulnérable_non_dans_le_chemin_d_execution” : statements:justification:vulnerable_code_not_in_execute_path
Justification “Code_vulnérable_ne_peut_paas_être_controlé_par_l_adversaire” : statements:justification:vulnerable_code_cannot_be_controlled_by_adversary
Justification “Des_mitigações_inline_existent” : statements:vulnerable_code_cannot_be_controlled_by_adversary
Déclaration d'impact VEX
Déclaration d'impact : [Conditionnellement Requis] statements:impact_statement
Date de la déclaration d'impact : [Optionnel] statements:impact_statement_timestamp
Déclaration d'action VEX
Déclaration d'action : [Conditionnellement Requis] statements:action_statement
Date de la déclaration d'action : [Optionnel] statements:action_statement_timestamp
Une meilleure utilisation du SBOM pour la gestion des vulnérabilités et l'évaluation des risques nécessite une lisibilité machine basique du document VEX. Par conséquent, nous recommandons de créer VEX au sein de CycloneDX ou OpenVEX en utilisant une convention convenue d'un commun accord.
Interlynk essaie de rendre la divulgation de la sécurité facile, évidente et automatisée. Nous sommes heureux de répondre à toutes vos questions. N'hésitez pas à nous contacter à hello@interlynk.io ou via interlynk.io.