STMicroelectronics face aux défis de la conformité CRA

Une Task Force CRA est créée pour porter le projet

Cette mise en conformité a été remontée jusqu’au comité de direction, car l’impact du CRA ne se limite pas la R&D. Elle concerne tous les départements, aussi bien le juridique que la communication avec les clients, mais aussi tous les fournisseurs, en particulier ceux qui ont un impact direct sur la sécurité de STMicroelectronics.

« Nous y avons vu une opportunité de mettre en place un programme de management des vulnérabilités qui soit le même pour toute la compagnie, sur toutes nos lignes de produits, et sur des cycles de vie produit assez longs », ajoute Philippe Callot.

Une Task Force a été créée pour porter ce projet transversal. « Très rapidement, le travail a démarré avec les équipes produits, car elles ont des certifications et des besoins spécifiques, notamment des exigences de certains clients », explique Philippe Callot. « Il fallait aussi discuter avec eux pour permettre une collaboration quelquefois spécifique et efficace. »

De même, l’équipe PSIRT (Product Security Incident Response Team, ou Équipe de Réponse aux Incidents de Sécurité des Produits) qui gère les vulnérabilités par produit travaille avec la Task Force pour aligner ses processus qui existaient déjà depuis des années sur les nouvelles obligations.

Le premier défi de cette équipe a été d’identifier les produits réellement impactés par le CRA. Certains ne sont pas commercialisés sur le marché ordinaire et certains composants legacy sont encore à son catalogue. « En faisant le tour, nous nous sommes aperçus qu’entre 10 % à 50 % des produits ne sont pas concernés. »

Il a ensuite fallu ranger les produits dans les différentes classes définies par le CRA. Ces classes ne sont pas liées au risque, mais à la façon dont on évalue le produit : self-assesment, par un tiers ou certification des process au niveau de la production.

Passée cette phase, l’équipe projet a ensuite identifié des chaînes de décision trop complexes pour escalader rapidement en cas de vulnérabilité.

« Plusieurs équipes travaillent sur le traitement des vulnérabilités qui sont obtenues par les CVE ou un ticket du PSIRT. Typiquement, il faut plusieurs jours, voire plusieurs semaines, avant qu’on puisse fournir une réponse », confie le responsable. « L’information doit traverser plusieurs départements, dont la R&D, les couches de management, le juridique, etc. Nous avons mesuré, puis essayé de réduire ces délais pour répondre aux exigences du CRA. »

Le texte européen impose en effet de notifier un « Early warning » en 24 heures. Ensuite, l’entreprise ne dispose que de 72 heures pour fournir une notification détaillée. « Ces délais sont très courts, et vous imaginez bien que si le T0 est un samedi matin, c’est compliqué », souligne Philippe Callot.

Quant au « final report », il doit arriver au plus tard 14 jours après, soit 8 ou 30 jours après le T0. La définition du T0 elle-même n’est d’ailleurs pas simple. Car lorsqu’une CVE est publiée, qu’une alerte PSIRT est émise ou même à la réception d’un email d’un client, STMicroelectronics doit faire une première analyse pour vérifier si l’alerte est réellement une vulnérabilité activement exploitée.

Le délai de cette tâche n’est pas imposé. Le CRA évoque un « due time », un délai raisonnable. Une fois la vulnérabilité identifiée, trois flux sont lancés en parallèle : la gestion de la vulnérabilité IT qui existait déjà, la communication avec le client et le reporting CRA (selon l’article 14).

Pour identifier les produits impactés par une vulnérabilité, il est nécessaire de disposer d’une liste qui recense jusqu’aux packages fournis par des tierces parties. C’est le rôle de la SBOM. Mais il faut un lien entre le SBOM, le Hardware BOM et éventuellement un CBOM (Cryptography Bill of Materials) afin de reconstituer les produits et les configurations. Ce triptyque permet de faire le lien entre les vulnérabilités potentielles sur ces SBOM et le produit.

« Cette infrastructure va nous permettre de faire un Product Assessment […] et d’établir le statut de chaque vulnérabilité dans chaque configuration », se réjouit le responsable. « Il y a une phase automatique qui va identifier toutes les vulnérabilités potentielles. Mais il reste une partie d’engineering et d’assessment, d’évaluation qui va mesurer s’il y a un impact ou pas. »

Dès que chaque vulnérabilité est qualifiée par un statut spécifique à chaque produit, STMicroelectronics va générer le Security Advisory qui va indiquer au client ce qu’il doit faire face à cette vulnérabilité, ainsi qu’un VEX (Vulnerability Exploitability eXchange).

« La SBOM vous dit que vous avez 500 vulnérabilités potentielles, mais le VEX vous indique que parmi ces 500, seules 3 impactent réellement le produit dans la configuration indiquée et qu’il faut se concentrer seulement sur celles-ci », explicite Philippe Callot qui a travaillé avec Black Duck sur l’intégration de cette fonctionnalité de génération de VEX dans l’outil d’administration SCA de l’éditeur.

Une attention toute particulière a été apportée à la traçabilité des processus et à chaque prise de décision en cas de contrôle par les autorités.

Pour l’instant, STMicroelectronics n’a pas eu à activer son processus de déclaration auprès de l’ENISA. Aucune vulnérabilité active n’a été signalée sur ses produits depuis le 11 septembre. Mais au cas où, STMicroelectronics est prêt.

Propos recueillis lors des Assises de la sécurité 2026