VEX et CSAF : éléments probants auditables sur les vulnérabilités

L’avis de 07 h 40 qui transforme un SBOM en sujet de conseil d’administration

À 07 h 40, un mardi matin du début 2026, Anya, RSSI d’une plateforme fintech en forte croissance, reçoit un avis fournisseur critique au format CSAF. Une vulnérabilité d’exécution de code à distance a été découverte dans une bibliothèque open source largement utilisée. Sa nomenclature logicielle, ou Software Bill of Materials, confirme que la bibliothèque est intégrée dans l’application phare de traitement des paiements, dans deux services internes et dans un composant d’analyse externalisé.

À 08 h 10, son téléphone n’arrête plus de vibrer. L’ingénierie veut savoir si la fonction vulnérable est joignable. La conformité veut savoir si cela concerne ISO/IEC 27001:2022, NIS2 ou DORA. Le juridique demande si le Cyber Resilience Act pourrait imposer une communication aux clients ou aux autorités. Un membre du conseil d’administration, récemment formé à la responsabilité des organes de direction au titre de NIS2, pose la question que tout le monde a en tête :

Sommes-nous affectés ?

La première réponse de l’ingénierie est techniquement honnête : le paquet existe, mais la fonction vulnérable pourrait ne pas être appelée en production. En 2026, cette réponse ne suffit plus.

Le conseil d’administration veut des preuves. Les clients attendent une réponse claire. Les achats veulent savoir si le fournisseur a respecté ses obligations contractuelles de divulgation. Le délégué à la protection des données (DPO) veut savoir si des données à caractère personnel pourraient être exposées. Un auditeur ISO 27001 n’acceptera pas « le développeur l’a dit » comme élément probant conservé. Un auditeur DORA s’attendra à ce que la vulnérabilité soit reliée aux actifs TIC, aux fonctions critiques et aux dépendances vis-à-vis de tiers.

C’est à ce stade que VEX et CSAF cessent d’être de simples formats techniques et deviennent une infrastructure de gouvernance.

CSAF, le Common Security Advisory Framework, structure les avis de vulnérabilité afin que les personnes comme les machines puissent traiter les produits affectés, les versions, les recommandations de remédiation, les références et les informations de statut. VEX, le Vulnerability Exploitability eXchange, fournit la couche décisionnelle. Il indique aux parties prenantes si une vulnérabilité connue est effectivement exploitable dans un produit, un service ou un environnement spécifique.

Les résultats pratiques de statut VEX sont simples : affecté, non affecté, corrigé et en cours d’investigation. La gouvernance qui les sous-tend ne l’est pas. Chaque statut nécessite des éléments probants, un responsable, une justification, une approbation et un déclencheur de revue.

L’écart de conformité ne réside plus dans l’absence de SBOM. De nombreuses organisations disposent désormais de SBOM. L’écart réside dans la capacité à démontrer comment chaque avis de vulnérabilité a été trié, qui a approuvé la décision de statut, quels éléments probants ont soutenu une conclusion « non affecté », comment la remédiation a été priorisée lorsque le produit était « affecté » et comment l’organisation a conservé cette piste pour les auditeurs, les autorités de régulation, les clients et la direction.

Clarysec traite VEX et CSAF comme une composante du modèle opérationnel du SMSI. Dans Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, ce sujet relève des phases de gestion des risques, de sécurité des fournisseurs, de contrôles technologiques et d’éléments probants. Dans Zenith Controls : guide de conformité croisée, le même thème relie les contrôles ISO/IEC 27001:2022 à la sécurité de la chaîne d’approvisionnement TIC, à la gestion des vulnérabilités, au traitement des éléments probants, ainsi qu’aux attentes NIS2, DORA, GDPR et NIST.

Pourquoi les SBOM produisent des signaux, tandis que VEX produit des éléments probants

Un SBOM est une liste d’ingrédients. Il indique ce qui se trouve dans un produit ou un service. Lorsqu’une CVE apparaît dans l’un de ces ingrédients, le SBOM indique que vous pourriez être affecté.

Ce signal est utile, mais ce n’est pas une conclusion.

Un environnement logiciel mature peut générer des milliers de correspondances entre SBOM et vulnérabilités. Beaucoup correspondent à de vrais risques. Beaucoup ne sont pas exploitables parce que le code vulnérable n’est pas livré, pas importé, pas joignable, pas configuré, pas exposé à des entrées non fiables ou est atténué par des contrôles compensatoires. Sans processus formel pour consigner l’investigation, les équipes tombent généralement dans l’un des deux mauvais schémas suivants.

Le premier est l’épuisement lié au triage. Les ingénieurs traitent chaque correspondance de vulnérabilité avec la même urgence, même lorsque le composant est une dépendance utilisée uniquement au moment du build, un chemin de code dormant ou une fonctionnalité réservée à l’interne et protégée par des contrôles en couches.

Le second est l’acceptation du risque non documentée. Les équipes clôturent les tickets avec de courts commentaires comme « non applicable » ou « faux positif ». Cela peut sembler efficace, mais, pour un auditeur, il s’agit d’une décision non maîtrisée. Pour une autorité de régulation, cela peut ressembler à une vulnérabilité non gérée.

VEX et CSAF répondent à ce problème en transformant le bruit lié aux vulnérabilités en éléments probants structurés et auditables.

Un processus de gouvernance VEX et CSAF défendable répond à cinq questions :

1. Avons-nous reçu ou identifié l’avis ?
2. L’avons-nous relié aux produits, aux actifs, aux fournisseurs, aux clients et aux flux de données à caractère personnel ?
3. Avons-nous déterminé le statut de la vulnérabilité à l’aide de critères définis ?
4. Avons-nous documenté la décision, les éléments probants, le responsable, l’approbation et le déclencheur de revue ?
5. Avons-nous réalisé la remédiation, communiqué, surveillé ou conservé les éléments probants en fonction du risque ?

La différence entre « non affecté » et « ignoré » réside dans les éléments probants.

Un statut VEX « non affecté » doit être étayé par une justification, par exemple lorsque le composant vulnérable n’est pas présent, que la version vulnérable n’est pas déployée, que le chemin de code vulnérable n’est pas exécuté, que la configuration vulnérable est désactivée ou qu’un contrôle compensatoire empêche l’exploitation. « En cours d’investigation » doit être assorti d’un suivi limité dans le temps, et non devenir un cimetière d’arriéré. « Corrigé » doit renvoyer à un correctif, une mesure d’atténuation, une mise à jour de version, un résultat de tests et un enregistrement de déploiement. « Affecté » doit entrer dans les processus de traitement des risques, de planification de la remédiation, de notification au fournisseur, de communication client et, le cas échéant, d’évaluation d’incident ou de violation.

Le modèle de gouvernance Clarysec pour les décisions de statut VEX

Chaque avis CSAF et chaque déclaration VEX doivent être traités comme un enregistrement maîtrisé dans le SMSI, et non comme un livrable d’ingénierie isolé. Le processus peut résider dans une plateforme GRC, un outil de gestion des vulnérabilités, un système de tickets, un processus de contrôle du code source ou un classeur d’éléments probants Clarysec. Le point essentiel est que le statut, les éléments probants, l’approbation et le traitement des risques restent liés.

Ce tableau paraît simple, mais il modifie l’environnement de contrôle. Une déclaration « non affecté » devient une mini-décision de risque pour un produit et un environnement donnés. Un statut « corrigé » relie la gestion des vulnérabilités à la gestion des changements et aux tests. Un statut « affecté » déclenche un traitement, une escalade et une possible divulgation. Un statut « en cours d’investigation » donne à la direction une visibilité sur un risque limité dans le temps.

Zenith Blueprint renforce cette approche à l’étape 13, consacrée à la planification du traitement des risques et à la déclaration d’applicabilité. Il explique que les décisions relatives aux contrôles doivent être justifiées par le traitement des risques, les exigences légales ou contractuelles, la pertinence du périmètre et le contexte organisationnel :

« Dans la feuille SoA, marquez chaque contrôle comme “Oui” (applicable) ou “Non” (non applicable). Fournissez une justification/des notes. »

Pour VEX, « non affecté » suit la même discipline. Ce n’est pas une clôture de ticket informelle. C’est une décision justifiée qui doit résister à une revue.

L’étape 19 de Zenith Blueprint traite de la gestion des vulnérabilités techniques :

« Restez informé des nouveaux défauts de sécurité (via les alertes des fournisseurs, les flux CVE, etc.) concernant vos logiciels et matériels. Évaluez ceux qui sont pertinents (utilisons-nous ce logiciel ? quelle est la criticité du défaut ?) et appliquez rapidement les correctifs ou les mesures d’atténuation. »

CSAF aide à recevoir des avis structurés. Les SBOM aident à déterminer la présence des composants. VEX aide à documenter l’exploitabilité et le statut. Le SMSI gouverne la décision.

Éléments probants de politique avant l’arrivée de l’avis critique

Un programme VEX échoue lorsque le premier avis critique arrive avant que les rôles, les critères et les exigences en matière d’éléments probants aient été définis. Les politiques doivent déjà encadrer la réception des vulnérabilités, l’escalade, l’enregistrement, les obligations des fournisseurs, la gestion des exceptions et la conservation des éléments probants.

Pour les PME, la Politique de gestion des vulnérabilités et des correctifs - PME établit l’obligation de surveillance :

« Surveille les systèmes afin d’identifier les vulnérabilités et les correctifs disponibles à l’aide des alertes des fournisseurs, des avis de renseignement sur les menaces et des notifications des systèmes d’exploitation »

Cette clause, issue de la section Rôles et responsabilités, clause de politique 4.2.1, s’applique directement à la réception des avis CSAF. Les avis CSAF sont des avis de vulnérabilité émis par des fournisseurs ou par un écosystème ; ils doivent être surveillés, corrélés et triés.

La même politique PME définit les attentes en matière de préparation à l’audit :

« Tenir des enregistrements exacts des correctifs appliqués, des points en suspens et des exceptions afin d’être en mesure de répondre à un audit »

Issue des Objectifs, clause de politique 3.4, cette exigence montre où VEX devient plus qu’un fichier technique. Si une équipe n’applique pas de correctif parce qu’un produit est « non affecté », cette exception nécessite des éléments probants, une approbation et une traçabilité.

Pour les environnements d’entreprise, la Politique de gestion des vulnérabilités et des correctifs est explicite :

« Surveiller les avis sur les menaces (par exemple, CVE, CISA KEV, bulletins fournisseurs) et escalader les vulnérabilités critiques. »

Issue de la section Rôles et responsabilités, clause de politique 4.5.1, cette clause soutient un canal de réception structuré pour CSAF, CVE, les bulletins fournisseurs et le renseignement sur les codes d’exploitation. Elle impose également l’escalade lorsqu’un statut VEX est « affecté » ou « en cours d’investigation » pour un produit critique.

La politique d’entreprise précise également :

« Toutes les vulnérabilités critiques et à haut risque doivent être enregistrées dans le registre des risques du SMSI et surveillées jusqu’à leur remédiation ou jusqu’à leur couverture par une exception approuvée. »

Cette clause, issue des Exigences de gouvernance, clause de politique 5.3, constitue l’ancrage de conformité. Une déclaration VEX « non affecté » pour une CVE critique n’est défendable que si elle est traitée comme une exception approuvée et étayée par des éléments probants. Une déclaration VEX « corrigé » ne ferme la boucle que lorsque la remédiation a été vérifiée.

La cotation des risques nécessite également du contexte. La même politique fait référence à :

« Appréciation des risques (fondée sur CVSS, la criticité de l’actif, le renseignement sur les menaces) »

Issue de la section Traitement des risques et exceptions, clause de politique 7.2.2, cette référence soutient un modèle de triage combiné. CVSS seul ne suffit pas. Une vulnérabilité de gravité moyenne activement exploitée dans un composant d’identité critique peut être plus urgente qu’un problème CVSS critique dans du code non joignable.

Les politiques relatives aux applications et au développement sécurisé étendent la même discipline à l’ingénierie et aux fournisseurs. La Politique relative aux exigences de sécurité des applications - PME impose aux équipes de suivre :

« les vulnérabilités connues et le statut de remédiation. »

Issue des Exigences de mise en œuvre de la politique, clause de politique 6.4.2.3, cette exigence se mappe naturellement aux statuts VEX. La même politique exige que les accords :

« précisent les obligations de divulgation des vulnérabilités, les délais de réponse et l’application des correctifs. »

Issue des Exigences de gouvernance, clause de politique 5.3.2, cette exigence devient une clause fournisseur opérationnelle : fournir des avis dans les délais, identifier les versions affectées, émettre un statut VEX lorsque possible, définir les échéances de remédiation et soutenir la communication client.

Pour le développement sécurisé en entreprise, la Politique de développement sécurisé attend :

« le scan des vulnérabilités connues (CVE, OSS Index, etc.) »

Issue des Exigences de gouvernance, clause de politique 5.4.3, cette disposition donne à l’ingénierie un mécanisme défini pour faire correspondre les avis aux composants et déclencher l’analyse VEX.

Lorsqu’une vulnérabilité devient un incident ou un possible sujet juridique, la discipline relative aux éléments probants devient essentielle. La Politique de collecte des éléments de preuve et d’investigation forensique - PME indique :

« Un journal simple de chaîne de conservation (par exemple, fichier Excel ou modèle de document) doit être tenu pour chaque incident. »

Issue des Exigences de gouvernance, clause de politique 5.3.1, cette exigence marque la frontière entre le triage VEX de routine et le traitement des éléments probants au niveau incident. Si une exploitation est suspectée, les journaux, les enregistrements d’avis, les notes d’analyse, les communications et les artefacts forensiques doivent être traçables.

Mapper VEX et CSAF à ISO 27001, NIS2, DORA, GDPR et CRA

Les programmes VEX les plus robustes ne sont pas des projets autonomes d’ingénierie sécurité. Ils sont mappés au dispositif de contrôle déjà utilisé par l’organisation.

Au titre d’ISO/IEC 27001:2022, le SMSI doit tenir compte des parties intéressées, des obligations légales et contractuelles, ainsi que des interfaces et dépendances avec d’autres organisations. Cette logique de périmètre est essentielle pour VEX, car les avis fournisseurs, les engagements clients, les composants open source et les services externalisés influencent tous les décisions relatives aux vulnérabilités.

Les contrôles les plus pertinents de l’Annexe A comprennent 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.20 Prise en compte de la sécurité de l’information dans les accords conclus avec les fournisseurs, 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, 5.22 Surveillance, revue et gestion des changements des services fournisseurs, 5.28 Collecte des éléments probants et 8.8 Gestion des vulnérabilités techniques. Les contrôles de développement sécurisé 8.25 à 8.29 sont également pertinents lorsque l’organisation développe des logiciels ou des produits numériques.

NIS2 accroît la pression de gouvernance. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées, notamment l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition, le développement et la maintenance sécurisés, le traitement et la divulgation des vulnérabilités, l’efficacité des contrôles, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs et l’authentification. Article 20 impose aux organes de direction d’approuver et de superviser les mesures de gestion des risques de cybersécurité. Les indicateurs VEX deviennent ainsi adaptés au reporting au conseil d’administration.

DORA s’applique depuis le 17 janvier 2025 aux entités financières concernées. Il exige un cadre de gestion des risques liés aux TIC, l’identification et la classification des actifs TIC, des vulnérabilités, des dépendances et des services de tiers TIC, la gestion des incidents, des tests de résilience, la gestion des risques liés aux tiers et la supervision par la direction. Pour les entités financières, les enregistrements VEX sont particulièrement utiles lorsqu’un avis fournisseur doit être relié à des fonctions critiques ou importantes, à des obligations contractuelles et à la classification d’un incident.

GDPR intervient lorsque l’exploitation pourrait affecter des données à caractère personnel. Une interface de programmation (API), une bibliothèque ou un service vulnérable susceptible d’exposer des enregistrements clients exige une évaluation au regard de la confidentialité, de l’intégrité, de la disponibilité et des critères de notification des violations. Une conclusion VEX « non affecté » peut soutenir une décision de ne pas notifier, mais uniquement si l’organisation peut démontrer pourquoi aucune violation de données à caractère personnel ne s’est produite.

Le Cyber Resilience Act ajoute une dimension de gouvernance produit. À mesure que les obligations CRA entrent progressivement en application, les fabricants et autres opérateurs économiques doivent disposer de processus répétables de traitement des vulnérabilités, de mise à jour de sécurité, de divulgation coordonnée et de conservation des éléments probants. CSAF peut structurer les avis. VEX peut clarifier quels produits et quelles versions sont affectés, corrigés ou non affectés.

Ce qu’apporte le guide de conformité croisée Clarysec

Zenith Controls est utile parce qu’il mappe le travail technique aux attentes d’audit et aux cadres qui se recoupent. Pour VEX et CSAF, trois domaines sont déterminants : la sécurité de la chaîne d’approvisionnement TIC, la gestion des vulnérabilités techniques et la collecte des éléments probants.

Pour la sécurité de la chaîne d’approvisionnement TIC, Zenith Controls identifie le contrôle 5.21 d’ISO/IEC 27002:2022 comme « Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC ». Il explique que 5.21 étend les contrôles de relation fournisseur 5.19 et 5.20 aux risques propres aux TIC, notamment les composants logiciels non sécurisés et les bibliothèques tierces ou open source. Il le relie à l’ingénierie sécurisée, à la programmation sécurisée, aux tests de sécurité, au contrôle d’accès, à la collecte des éléments probants, au cycle de vie du développement sécurisé et au développement externalisé.

C’est précisément là que CSAF et VEX interviennent. Un avis fournisseur n’est pas seulement un message provenant d’un fournisseur. C’est un élément probant de la pratique cybersécurité du fournisseur. Une déclaration VEX fournisseur n’est pas seulement une commodité. Elle peut soutenir les achats, les diligences préalables, la surveillance et les décisions de risque client.

Pour la gestion des vulnérabilités techniques, Zenith Controls identifie le contrôle 8.8 comme « Gestion des vulnérabilités techniques ». Il classe ce contrôle comme préventif, soutenant la confidentialité, l’intégrité et la disponibilité, et le rattache à la gestion des menaces et des vulnérabilités. Il précise également que la gestion des vulnérabilités est liée à la protection contre les logiciels malveillants, à la gestion des configurations, à la gestion des changements, au renseignement sur les menaces et à la surveillance.

Un passage particulièrement utile de Zenith Controls pour la gouvernance VEX est le suivant :

« Une Gestion des vulnérabilités efficace priorise en fonction des menaces issues du monde réel. Le renseignement sur les menaces indique quelles vulnérabilités sont activement exploitées et guide la priorisation des correctifs. »

C’est la différence entre une simple correspondance SBOM et un triage VEX fondé sur les risques. La présence seule ne suffit pas. L’exploitabilité, la criticité de l’actif, l’exposition et l’activité de menace doivent orienter la décision.

Pour les éléments probants, Zenith Controls identifie le contrôle 5.28, « Collecte des éléments probants », comme correctif et lié à la détection et à la réponse. Il relie 5.28 à la réponse aux incidents, à la journalisation, à la surveillance et à la notification d’événements. Il mappe également le traitement des éléments probants à ISO/IEC 27037:2012 pour l’identification, la collecte, l’acquisition et la conservation des éléments de preuve numériques.

Lorsqu’une vulnérabilité est purement théorique, des enregistrements VEX de routine peuvent suffire. Lorsqu’une exploitation est suspectée, l’organisation doit passer au traitement des éléments probants en contexte d’incident. Les journaux, communications fournisseurs, avis clients, enregistrements de correctifs et artefacts forensiques nécessitent intégrité, conservation et traçabilité.

Un dossier d’éléments probants VEX pratique, de l’alerte à la clôture

Revenons à la plateforme fintech d’Anya. Un avis CSAF arrive pour une vulnérabilité critique dans lib-common-utils, qui apparaît dans le SBOM de la passerelle de paiement. Une réponse disciplinée créerait un seul dossier d’éléments probants, et non des messages Slack et captures d’écran dispersés.

Étape 1 : créer l’enregistrement de réception de l’avis

Ouvrez un dossier de vulnérabilité dans l’outil de suivi des éléments probants du SMSI. Joignez l’avis CSAF, la référence CVE, le bulletin fournisseur, la correspondance SBOM et la liste des actifs affectés. Désignez un responsable de la vulnérabilité et un responsable du système métier. Reliez le service de paiement à l’impact client, aux données à caractère personnel, au traitement financier et à la criticité opérationnelle.

Base politique : la Politique de gestion des vulnérabilités et des correctifs exige la surveillance des avis et l’escalade des vulnérabilités critiques. Base ISO : contrôle 8.8 de l’Annexe A. Base NIS2 : traitement des vulnérabilités et maintenance sécurisée. Base DORA : identification des vulnérabilités TIC et préparation aux incidents.

Étape 2 : définir le statut préliminaire « en cours d’investigation »

Le statut initial devrait souvent être « en cours d’investigation », en particulier pour les avis critiques. Fixez une échéance de décision, par exemple 24 heures pour les services exposés à l’extérieur ou critiques. Consignez les contrôles provisoires, tels qu’une surveillance renforcée, des restrictions temporaires de fonctionnalités ou des règles WAF. Cela empêche un avis critique de disparaître dans un arriéré non maîtrisé.

Étape 3 : réaliser l’analyse d’exploitabilité

L’ingénierie doit répondre à des questions pratiques :

• La version vulnérable est-elle présente en production ?
• La fonction vulnérable est-elle importée, appelée ou joignable ?
• La configuration vulnérable est-elle activée ?
• Le composant est-il exposé à des entrées non fiables ?
• Une authentification est-elle requise avant d’atteindre le chemin vulnérable ?
• Les contrôles compensatoires sont-ils efficaces ?
• Existe-t-il une exploitation active ou un renseignement sur les menaces crédible ?
• L’exploitation pourrait-elle affecter des données à caractère personnel, des transactions financières ou la disponibilité du service ?

Dans le cas d’Anya, l’analyse statique confirme que le composant est présent, mais que la fonction vulnérable n’est pas invoquée par la passerelle de paiement. Aucun chemin d’exécution n’existe en production. L’équipe prépare une déclaration VEX « non affecté » avec les éléments probants à l’appui.

Si l’analyse avait montré qu’une tâche administrateur authentifiée pouvait atteindre la fonction vulnérable, le statut correct aurait été « affecté », et non « non affecté ». L’équipe aurait alors créé un plan de traitement des risques, ouvert un ticket de changement, appliqué un correctif ou une mesure d’atténuation, puis mis à jour le statut à « corrigé » uniquement après vérification.

Étape 4 : lier le dossier au registre des risques et à l’enregistrement fournisseur

Les cas critiques et à haut risque doivent être inscrits dans le registre des risques du SMSI, sauf s’ils sont clôturés par une exception approuvée et étayée par des éléments probants. Les avis fournisseurs doivent également être reliés au registre des fournisseurs, aux obligations contractuelles et aux enregistrements de surveillance.

Cela soutient l’étape 23 de Zenith Blueprint, qui demande aux organisations de compiler les fournisseurs, de les classifier selon l’accès et le contrôle opérationnel, d’intégrer les exigences de sécurité dans les contrats et de définir des procédures de surveillance des changements fournisseurs.

Étape 5 : valider la correction ou approuver l’exception

Pour « corrigé », joignez la version du correctif, l’enregistrement de changement, le résultat du pipeline CI/CD, l’analyse des dépendances, le condensat de l’image de conteneur, la preuve de déploiement et le test de non-régression. Pour « non affecté », joignez l’analyse du chemin de code, la preuve de configuration, la preuve de version, la preuve de contrôle compensatoire et l’approbation.

Si les clients utilisent des versions auto-hébergées ou si la vulnérabilité pourrait affecter des utilisateurs externes, coordonnez la communication. La Politique de divulgation coordonnée des vulnérabilités fournit le modèle :

« Lorsqu’une vulnérabilité confirmée pourrait affecter des clients ou des utilisateurs de services, l’équipe Communications, sous la direction de la VRT, doit préparer un avis de sécurité. L’avis doit inclure une vue d’ensemble du problème, sans divulguer les détails d’exploitation, les produits ou versions affectés, les recommandations d’atténuation ou les instructions de téléchargement du correctif, ainsi que les coordonnées du support. »

Issue des Exigences de mise en œuvre, clause de politique 6.8, cette approche se mappe directement à la discipline de publication CSAF.

Étape 6 : conserver les éléments probants si une exploitation est suspectée

Si les journaux montrent des tentatives d’exploitation, passez du traitement des vulnérabilités à la réponse aux incidents et à la collecte des éléments probants. Ouvrez un journal de chaîne de conservation, conservez les journaux, consignez les requêtes SIEM, exportez les événements pertinents, prenez un instantané des systèmes affectés si nécessaire et documentez qui a manipulé chaque artefact. Reliez le dossier d’incident à l’enregistrement VEX.

Ce que les auditeurs et les autorités de régulation demanderont

Tous les auditeurs ne testent pas la gouvernance VEX et CSAF de la même manière. Un dossier unique d’éléments probants doit satisfaire plusieurs angles d’examen.

Zenith Controls comprend des recommandations de méthodologie d’audit qui correspondent à ce tableau. Pour la sécurité de la chaîne d’approvisionnement TIC, les auditeurs utilisant ISO/IEC 19011 et ISO/IEC 27007 examineront les politiques d’approvisionnement, les modèles d’appels d’offres et les processus de gestion des fournisseurs afin de vérifier les exigences de sécurité propres aux TIC. Ils échantillonneront les contrats pour rechercher des clauses relatives au développement sécurisé, à la divulgation des vulnérabilités et à l’authenticité logicielle.

Pour la gestion des vulnérabilités techniques, les auditeurs examinent la politique de gestion des vulnérabilités, la fréquence des analyses, la couverture des actifs, la priorisation fondée sur les risques, les délais de remédiation et les responsabilités. Pour la collecte des éléments probants, ils testent si la chaîne de conservation, le stockage sécurisé et la conservation ont été respectés lors d’incidents réels.

C’est pourquoi la gouvernance VEX ne doit jamais s’arrêter au libellé du statut. Le libellé est le résumé. La piste d’éléments probants est le contrôle.

Les indicateurs de direction qui rendent VEX exploitable par le conseil d’administration

ISO/IEC 27001:2022 exige l’évaluation des performances, l’audit interne et la revue de direction. NIS2 exige une supervision par la direction. DORA exige une gouvernance du risque TIC. VEX et CSAF créent des indicateurs qui transforment le travail d’ingénierie en visibilité exécutive sur les risques.

Les indicateurs utiles pour la revue de direction comprennent :

• Nombre d’avis CSAF critiques reçus ce trimestre
• Pourcentage mis en correspondance avec des composants SBOM
• Nombre et ancienneté des statuts VEX par affecté, non affecté, corrigé et en cours d’investigation
• Cas « en cours d’investigation » en retard
• Avis fournisseurs sans données suffisantes sur les versions affectées
• Vulnérabilités critiques acceptées comme exceptions approuvées
• Délai entre la réception de l’avis et la décision VEX
• Délai entre la décision « affecté » et la remédiation
• Nombre de cas présentant un impact potentiel sur des données à caractère personnel
• Nombre d’avis clients émis

Ces indicateurs aident la direction à poser de meilleures questions. Quels fournisseurs ne fournissent pas de données de vulnérabilité exploitables ? Quels produits présentent les délais de remédiation les plus longs ? Quelles équipes laissent des investigations ouvertes ? Quelles vulnérabilités peuvent affecter des données à caractère personnel ou des fonctions critiques ?

Schémas d’échec courants à éliminer

Le premier échec consiste à traiter la correspondance SBOM comme une analyse d’exploitabilité. Une correspondance de composant est un signal, pas une conclusion.

Le deuxième échec consiste à utiliser « non affecté » sans justification. Les auditeurs demanderont pourquoi. Le chemin de code était-il non joignable ? La fonctionnalité vulnérable était-elle désactivée ? La version était-elle différente ? Le composant n’était-il utilisé qu’au moment du build ? La conclusion a-t-elle été approuvée par la sécurité produit ?

Le troisième échec consiste à laisser « en cours d’investigation » ouvert indéfiniment. Ce statut n’est utile qu’avec un responsable, une échéance et des contrôles provisoires.

Le quatrième échec consiste à séparer la gouvernance des fournisseurs de la gouvernance des vulnérabilités. Les contrats fournisseurs doivent imposer la divulgation des vulnérabilités dans les délais, des délais de réponse, des obligations d’application des correctifs, le contenu des avis et le soutien aux éléments probants.

Le cinquième échec consiste à ignorer les données à caractère personnel et la communication client. Une vulnérabilité susceptible d’exposer des données à caractère personnel exige une évaluation GDPR. Une vulnérabilité produit confirmée pouvant affecter des clients exige une discipline de divulgation coordonnée. Une dépendance d’un service financier peut exiger une analyse d’incident DORA.

Le sixième échec est la faiblesse de la conservation des éléments probants. Zenith Blueprint avertit à l’étape 23, contrôle 5.28, que les éléments probants sont souvent négligés :

« ce que vous pouvez prouver compte autant que ce qui s’est réellement produit »

Cette phrase résume la réalité de 2026. Les équipes sécurité ne se contentent plus de corriger des vulnérabilités. Elles prouvent que les décisions ont été prises dans les délais, fondées sur les risques et maîtrisées.

Prochaines étapes pour des éléments probants auditables sur les vulnérabilités

Si votre organisation dispose déjà de SBOM, la prochaine étape de maturité n’est pas une nouvelle feuille d’inventaire. C’est la gouvernance du statut des vulnérabilités, des avis fournisseurs et des éléments probants de divulgation.

Commencez par quatre actions :

1. Ajoutez la réception CSAF et VEX à votre procédure de gestion des vulnérabilités.
2. Définissez les critères d’approbation pour les statuts affecté, non affecté, corrigé et en cours d’investigation.
3. Reliez les enregistrements VEX à votre registre des risques du SMSI, à votre registre des fournisseurs, à votre inventaire des actifs, à votre référentiel SBOM et à votre processus d’incident.
4. Testez le processus avec un avis critique récent et produisez un dossier d’éléments probants prêt pour audit.

Clarysec peut vous aider à le mettre en œuvre rapidement avec Zenith Blueprint, Zenith Controls et l’ensemble de politiques pertinent, notamment la Politique de gestion des vulnérabilités et des correctifs, la Politique de gestion des vulnérabilités et des correctifs - PME, la Politique relative aux exigences de sécurité des applications - PME, la Politique de développement sécurisé, la Politique de collecte des éléments de preuve et d’investigation forensique - PME et la Politique de divulgation coordonnée des vulnérabilités.

La question décisive en 2026 n’est pas « Avons-nous un SBOM ? ». C’est « Pouvons-nous prouver, pour chaque avis sérieux, exactement comment nous avons déterminé le statut de vulnérabilité, traité le risque et communiqué le résultat ? »

Réservez une évaluation Clarysec ou demandez le kit de politiques pertinent pour transformer VEX et CSAF en éléments probants auditables sur les vulnérabilités avant que le prochain avis critique n’atteigne votre conseil d’administration.