SBOM et VEX : composants et impact des vulnérabilités
Sytance · Mis à jour
Une SBOM identifie les composants logiciels d’un produit. Vulnerability Exploitability eXchange (VEX) indique si une vulnérabilité donnée affecte ce produit. L’évaluation dépend de la version du produit, de sa configuration et de la manière dont il utilise le composant.
Inventaire des composants, correspondance et impact
L’inventaire indique si un composant est présent. Une correspondance de vulnérabilité montre qu’un avis mentionne le composant ou sa version. L’analyse d’impact vérifie ensuite si le code vulnérable est présent et exploitable dans le build et l’utilisation réels du produit.
CycloneDX utilise VEX pour communiquer l’évaluation d’un produit donné. Par exemple, un composant peut être présent alors qu’une fonctionnalité vulnérable facultative a été exclue lors du build. Cette distinction nécessite des informations sur le build et une analyse.
Les quatre statuts OpenVEX
OpenVEX définit quatre statuts. Chacun s’applique à la version du produit et à la vulnérabilité identifiées dans la déclaration.
| Statut OpenVEX | Signification |
|---|---|
| under_investigation | L’impact est encore en cours d’évaluation |
| affected | Le produit identifié est concerné |
| fixed | La version identifiée inclut un correctif |
| not_affected | Le produit identifié n’est pas concerné |
Un décodeur facultatif dans une passerelle
Considérez une passerelle fictive contenant une bibliothèque d’analyse syntaxique dotée d’un décodeur facultatif. Supposons qu’une vulnérabilité affecte ce décodeur. L’évaluation commence par déterminer quel build de la bibliothèque est inclus dans l’image livrée et si le décodeur a été compilé dans celle-ci.
Si les paramètres de build et l’analyse du binaire confirment que le décodeur vulnérable est absent, ils peuvent étayer une déclaration de statut `not_affected` avec le motif `vulnerable_code_not_present`. Cette déclaration s’applique à ce build.
Si le code est présent, mais que son exécution reste incertaine, maintenez l’évaluation au statut « en cours d’investigation » tout en vérifiant les points d’entrée et les chemins d’exécution. Si le produit est concerné et qu’une version ultérieure comprend le correctif, la version précédente reste concernée ; la version ultérieure fait l’objet de sa propre déclaration.
Motifs du statut « non concerné »
OpenVEX exige qu’une déclaration de statut `not_affected` contienne une justification ou une déclaration d’impact. Les justifications lisibles par machine distinguent les composants manquants, l’absence du code vulnérable, le code hors du chemin d’exécution, les limites du contrôle par l’attaquant et les mesures d’atténuation intégrées.
Chaque motif répond à des conditions différentes. Une restriction réseau ne supprime pas le code vulnérable. Pour le motif d’atténuation intégrée, OpenVEX précise qu’il s’agit d’une protection qui empêche l’exploitation et que l’utilisateur ne peut ni désactiver ni reconfigurer.
Pour conclure sur un chemin de code, identifiez la fonction affectée, les chemins vérifiés et les limites de configuration. Réexaminez l’évaluation si ces conditions changent. Si la conclusion dépend d’un paramètre contrôlé par le client, indiquez clairement cette dépendance.
Utiliser la déclaration VEX d’un fournisseur
La déclaration VEX d’un fournisseur peut aider à filtrer des alertes ou à modifier leur priorité. Avant de l’utiliser, vérifiez la fiabilité de la source et la correspondance de la version du produit. Vérifiez également la date de publication, les révisions, la configuration applicable et les actions recommandées.
Si les informations d’un fournisseur de confiance contredisent votre propre analyse, conservez les deux dossiers et résolvez l’écart. Une déclaration générale sur une famille de produits peut ne pas couvrir un build personnalisé comportant des composants ou options différents.
Une SBOM reste utile après la publication d’une déclaration VEX. De nouveaux avis peuvent modifier les investigations nécessaires, et une version révisée du produit peut invalider une ancienne conclusion. Conservez les liens entre les mises à jour d’inventaire et les évaluations d’impact tout en gardant leurs historiques distincts.