Correlens

Cas d’usage · Risque fournisseur

Une violation chez un fournisseur, reliée aux pièces qu’elle met en danger.

Lorsqu’un acteur du dark web a annoncé des données prétendument volées à un grand partenaire d’ingénierie connectée, la question utile n’était pas seulement « est-ce réel ? ». Elle était : « quels composants, ECU et programmes ce fournisseur touche-t-il chez nous ? ». Voici comment y répondre.

1 · Le signal arriveUn acteur propose sur un forum du dark web environ 35 Go de données prétendument volées à Accenture, dont du code source, des jetons cloud et des identifiants. Accenture a publiquement confirmé un incident ; le volume annoncé n’a jamais été vérifié.
2 · Évalué, sans amplificationL’IA confronte l’affirmation aux antécédents de l’acteur. Celui-ci a déjà exagéré ses déclarations ; le signal obtient donc une confiance moyenne : il est signalé, pas présenté comme un fait établi.
3 · Corrélé à votre grapheLe fournisseur est déjà cartographié depuis vos SBOM. La plateforme relie la violation aux composants partagés exacts, aux ECU qui les utilisent et aux programmes exposés, puis les classe.
4 · Une personne décideUn analyste confirme la pertinence, réévalue le risque selon le contexte réel du véhicule, puis enregistre la décision et son raisonnement. La piste d’audit se construit au fil du travail.

Le résultat

Traçabilité des décisions

Une vague revendication publiée sur le dark web est devenue, en quelques minutes plutôt qu’après une recherche précipitée, une courte liste hiérarchisée de composants et de programmes, avec un responsable et une décision consignée. Cette même piste constitue ensuite la preuve demandée par l’évaluateur.

Traçabilité des décisionsdonnées d’exemple
09:41Signaux ingérés et dédoublonnés à partir de sources multiplesSIG-4471
09:41Confiance évaluée selon l’historique de l’acteur0.62 · MEDIUM
09:43Résolu pour les composants et les programmes partagés3 COMPONENTS
10:02L’analyste a confirmé la pertinence, réévalué pour le contexteANALYSTE K.M.
10:05Exporté sous STIX 2.1 vers le (V)SOCSTIX 2.1
Chaque étape ci-dessus constitue un enregistrement : qui, quand, qu’est-ce qui a changé et pourquoi.

Cas publics

Cinq ans d’exemples publics. Une seule question commune.

Des incidents fournisseurs publiquement rapportés dans l’automobile et les secteurs proches. Aucun n’a commencé comme une violation chez l’acheteur ; chacun exigeait pourtant la même réponse en quelques heures : quels composants, programmes et usines ce fournisseur touche-t-il chez nous ?

Accenture · 2021 et 2026

En août 2021, le groupe LockBit 2.0 a revendiqué environ 6 To volés à Accenture et exigé 50 millions de dollars ; la confirmation que des données avaient été consultées n’est venue que dans un rapport trimestriel ultérieur. En juillet 2026, un autre acteur a proposé sur un forum criminel du code source, des clés cloud et des identifiants, et des chercheurs ont pointé des dossiers portant le nom de clients dans l’arborescence divulguée comme la véritable exposition. Dans les deux cas, le chiffre venait de l’attaquant, et le premier geste utile était de relier la revendication à ce qu’elle touche réellement.

sources publiques 1sources publiques 2

Continental · 2022

LockBit a exfiltré des fichiers internes de cet équipementier de rang 1 pendant environ un mois avant sa détection, puis proposé les données à la vente pour 50 millions de dollars. Continental fournit notamment VW, BMW, Mercedes-Benz et Ford : l’archive volée d’un seul fournisseur devient donc une question d’exposition pour plusieurs constructeurs.

sources publiques

Toyota / Kojima Industries · 2022

Une cyberattaque contre un fournisseur de pièces national a mis à l’arrêt les systèmes de commande de Toyota. Sans marge dans un modèle en flux tendu, Toyota a arrêté 28 lignes réparties sur 14 usines pendant une journée, soit une perte de production estimée à 13 000 véhicules, sans avoir été elle-même compromise.

sources publiques

Denso · 2022

Le groupe Pandora a revendiqué 1,4 To provenant des opérations allemandes de Denso le même mois. Denso a coupé l’accès réseau dès la découverte et n’a signalé aucun impact sur la production : mêmes relations d’acheteur que Kojima, mais un périmètre d’impact différent selon le système touché.

sources publiques

Pourquoi ce n’est pas optionnel

Chaque référentiel pose quelque part la question du fournisseur.

Des régulateurs différents, la même exigence sous-jacente : savoir quels fournisseurs touchent quoi, et pouvoir le démontrer.

21434 · Clause 7 Activités distribuées : lorsque le travail de cybersécurité est réparti entre client et fournisseur, les responsabilités sont définies dans un accord d’interface de cybersécurité, évalué dès la sélection du fournisseur.
21434 · Clause 15 La TARA couvre chaque composant du périmètre, et les composants d’origine fournisseur alimentent la même analyse, avec une décision de traitement consignée.
UNECE R155 Le CSMS certifié doit gérer le risque sur toute la chaîne d’approvisionnement : exigences répercutées aux fournisseurs, et preuves de cybersécurité remontées par composant.
EU CRA · Art. 13 Diligence raisonnable sur les composants tiers et open source, avec l’obligation de signaler à son fabricant ou mainteneur toute vulnérabilité découverte dans l’un d’eux.
NIS2 · Art. 21(2)(d) Sécurité de la chaîne d’approvisionnement couvrant la relation avec chaque fournisseur direct, évaluée au regard des propres vulnérabilités et pratiques de ce fournisseur.
DORA · Art. 28 Les entités financières, y compris les filiales captives de financement et de crédit-bail des constructeurs lorsqu’elles sont des établissements agréés, tiennent un registre à jour de chaque prestation TIC assurée par un tiers, classée par criticité et communiquée aux régulateurs.
TISAX / VDA ISA Les constructeurs exigent des fournisseurs manipulant des données partagées ou des prototypes qu’ils détiennent un label TISAX à un niveau d’évaluation adapté à la sensibilité des données.
SBOM practice Née du décret américain EO 14028 et des éléments minimaux de la NTIA ; l’obligation fédérale a été abrogée par un changement de politique de l’OMB en février 2026, mais R156 et le CRA continuent d’attendre une nomenclature au niveau du composant pour chaque publication.

Cette correspondance est un outil de repérage, pas une revendication de certification. Vérifiez les numéros de clause et leur applicabilité actuelle dans les textes officiels avant une évaluation.

Où Correlens s’inscrit

Le registre dont chaque incident avait besoin est celui que chaque référentiel exige.

Chaque cas ci-dessus est devenu un problème en aval avant même que le fournisseur concerné n’ait terminé sa propre enquête. L’artefact qui réduit cet écart est le même que celui exigé par les référentiels : un registre à jour de quel fournisseur livre quel composant sur quel programme. Correlens tient ce registre à jour, y résout chaque nouveau signal, et consigne la décision de l’analyste au moment où elle est prise, si bien que la réponse à incident et la preuve d’audit ne forment qu’un seul artefact, et non deux tâches distinctes.

Voyez ce processus appliqué à vos propres fournisseurs.

L’appliquer à mes fournisseurs