Cas pratiques
Chaque cas suit la même trame : la situation, la question de chaque équipe, la décision, la preuve produite, l’enseignement.
Cas 1 — Une vulnérabilité critique touche douze de vos produits
Situation. Une vulnérabilité est publiée sur une bibliothèque très répandue. Votre plateforme identifie en dix minutes douze produits affectés, dont quatre en version encore supportée chez des clients.
Juridique : y a-t-il exploitation active ? Si oui, le délai de 24 heures court. Cyber : quelles versions exactement, quels clients, le code vulnérable est-il atteignable ?
Décision. Pas de preuve d’exploitation active à ce stade → pas d’obligation de signalement, mais traitement en urgence selon les SLA, VEX pour les produits où le code n’est pas atteignable, et surveillance renforcée des indices d’exploitation.
Preuve. Entrée au registre motivant l’absence de signalement, journal de traitement, VEX, avis de sécurité à la publication du correctif.
Enseignement. Sans SBOM centralisé, l’étape « quels produits sont affectés » aurait pris plusieurs semaines — et le délai de 24 heures aurait été manqué si l’exploitation avait été constatée entre-temps.
Cas 2 — Un chercheur vous signale une faille un vendredi soir
Situation. Un courriel arrive sur l’adresse PSIRT à 19 h le vendredi, décrivant une vulnérabilité exploitable à distance, avec une preuve de concept.
Juridique : est-ce une exploitation active ? Une preuve de concept fournie par un chercheur n’est pas une exploitation dans la nature. Cyber : la faille est-elle réelle, quelles versions, quel contournement immédiat ?
Décision. Accusé de réception dans les délais de la politique CVD, qualification sous sept jours, pas de signalement CRA en l’absence d’exploitation active, coordination de la date de publication avec le chercheur.
Preuve. Registre CVD, accusé de réception, échanges avec le chercheur, avis publié, remerciement.
Enseignement. La politique CVD absorbe ce cas sans mobiliser l’astreinte. Sans elle, le courriel serait resté sans réponse jusqu’au lundi, et le chercheur aurait pu publier.
Cas 3 — Un client exige votre SBOM dans un appel d’offres
Situation. Un grand compte demande, en pièce obligatoire, un SBOM au format SPDX pour la version qui lui sera livrée.
Juridique : que révèle ce document, sous quelles conditions le communiquer ? Cyber : votre format pivot est CycloneDX ; la conversion perd-elle des informations ?
Décision. Fourniture sous accord de confidentialité, via le portail authentifié, accompagnée des VEX. Conversion documentée, avec mention des pertes connues.
Preuve. Décision de diffusion, clause contractuelle, trace de la remise.
Enseignement. La question de la diffusion doit être tranchée avant l’appel d’offres — voir Diffusion et confidentialité. La traiter dans l’urgence conduit à sur-promettre.
Cas 4 — Un composant open source critique est abandonné
Situation. Le mainteneur unique d’une bibliothèque présente dans trois de vos produits annonce qu’il cesse la maintenance.
Juridique : vos périodes de support courent encore trois ans sur ces produits. Cyber : remplacer, forker, ou internaliser ?
Décision. Fork et maintenance interne pour la durée résiduelle du support, avec provision budgétaire ; remplacement planifié sur la prochaine version majeure.
Preuve. Décision documentée au registre des risques, mise à jour du registre des périodes de support, plan de remplacement.
Enseignement. Le critère « durée de support amont » doit figurer dans la grille de diligence à l’intégration, pas être découvert trois ans plus tard.
Cas 5 — Vous voulez intégrer une bibliothèque AGPL dans une offre en ligne
Situation. Une équipe propose une bibliothèque sous AGPL pour accélérer un développement.
Juridique : la mise à disposition via un réseau déclenche l’obligation de fournir le source de l’œuvre dérivée aux utilisateurs du service. Cyber : existe-t-il une alternative sous licence permissive ?
Décision. Refus, avec proposition d’une alternative. Si aucune n’existe : isolation stricte dans un service séparé, ou négociation d’une licence commerciale avec l’auteur.
Preuve. Blocage en CI, ticket, décision au registre des exceptions.
Enseignement. La politique de licences doit être appliquée par la chaîne de construction, pas seulement publiée. Un blocage automatique évite un débat trois mois plus tard, quand le code est écrit.
Cas 6 — Vous lancez un nouveau produit : quelle classe ?
Situation. Un nouveau produit intègre une fonction de gestion des accès et un moteur de rendu web embarqué.
Juridique : deux catégories de l’annexe III, partie I, sont en cause. Cyber : le moteur de rendu est-il exposé à du contenu distant non maîtrisé ?
Décision. Classe I. Deux scénarios d’évaluation instruits en parallèle : auto-évaluation si les normes harmonisées sont publiées et citées à temps, recours à un organisme notifié sinon — ce dernier retenu comme scénario de référence.
Preuve. Fiche de classification co-signée, versée au dossier.
Enseignement. La classification se fait au lancement du développement, pas avant la mise sur le marché : elle détermine le budget et le planning.
Cas 7 — Une autorité demande le dossier d’un produit vendu il y a quatre ans
Situation. Une autorité de surveillance du marché d’un autre État membre demande le dossier technique de la version 3.1.4, mise sur le marché quatre ans plus tôt.
Juridique : délai imparti, interlocuteur unique, gel des preuves. Cyber : retrouver le SBOM signé, vérifier sa signature, produire les VEX et les journaux de l’époque.
Décision. Application de la fiche réflexe, réponse dans le délai, sans reconstitution de documents.
Preuve. Le dossier tel qu’il existait, plus le registre des échanges.
Enseignement. Ce cas ne se prépare pas au moment où il arrive. Il se prépare par l’exercice annuel de restitution — voir Conservation des preuves.
Cas 8 — Un fournisseur refuse de fournir un SBOM
Situation. Un fournisseur de composant commercial refuse, invoquant le secret des affaires.
Juridique : votre obligation d’inventaire ne disparaît pas ; le contrat doit être renégocié. Cyber : pouvez-vous produire l’inventaire par analyse de l’artefact livré ?
Décision. Trois options, dans cet ordre : négocier une fourniture sous accord de confidentialité ; à défaut, produire un Analyzed SBOM par vos propres moyens et documenter la limite ; à défaut, planifier le remplacement du composant.
Preuve. Trace de la demande et du refus, SBOM produit par analyse avec déclaration de complétude partielle, décision au registre des risques.
Enseignement. La déclaration de complétude du SBOM sert précisément à cela : dire honnêtement ce que l’inventaire couvre. Un inventaire partiel déclaré comme tel vaut mieux qu’un inventaire partiel présenté comme complet.
Cas 9 — Quelle période de support pour un produit embarqué à longue durée de vie ?
Situation. Un équipement industriel dont la durée de vie physique attendue est de quinze ans.
Juridique : la période de support doit refléter la durée pendant laquelle le produit est censé être utilisé — soit potentiellement quinze ans. Cyber : pouvez-vous garantir des correctifs pendant quinze ans, sur une plateforme matérielle dont le fournisseur de puce arrêtera le support avant ?
Décision. Analyse des composants limitants, négociation d’un support étendu auprès du fournisseur de plateforme, et détermination d’une période de support justifiée et documentée — inférieure à la durée de vie physique si les composants ne suivent pas, avec information explicite de l’acheteur.
Preuve. Justification au dossier technique, mention à l’acheteur, registre.
Enseignement. La période de support n’est pas une décision commerciale libre : elle doit être justifiée. Et sa justification révèle souvent que vos fournisseurs ne suivent pas.
Cas 10 — Une exploitation constatée chez un seul client
Situation. Un client signale des indicateurs de compromission concordants exploitant une vulnérabilité de votre produit. Aucun autre client n’est affecté à votre connaissance.
Juridique : une exploitation constatée chez un seul client suffit à caractériser l’exploitation active. Cyber : vérifier les indicateurs, établir le périmètre, préparer un contournement.
Décision. Signalement. Alerte précoce sous 24 heures, information de l’ensemble des utilisateurs de la version affectée, contournement publié, correctif selon le SLA d’urgence.
Preuve. Registre, accusés de la plateforme, communication aux utilisateurs, avis publié.
Enseignement. Il n’existe pas de seuil de nombre de victimes. Un client suffit. C’est le cas qui doit être présent à l’esprit de l’astreinte, car l’intuition pousse à attendre « d’en savoir plus ».