La sécurité de la chaîne d’approvisionnement logicielle entre dans une phase beaucoup plus contraignante. Avec le Cyber Resilience Act, les fabricants de produits connectés et de logiciels devront mieux connaître les composants qu’ils intègrent, documenter leurs dépendances et réagir plus vite aux vulnérabilités exploitées. Scott Register, VP chez Keysight Technologies, explique pourquoi le SBOM, la réduction des faux positifs et l’intégration de la sécurité dans les processus de développement deviennent des conditions d’accès au marché européen.
Chaque produit connecté est livré avec un risque : ses composants logiciels. Lorsque la faille Log4Shell a fait surface fin 2021, cette vulnérabilité est devenue une urgence absolue. Les organisations ont passé des jours, parfois des semaines, à tenter de déterminer si une seule bibliothèque open-source était intégrée à leurs produits. La réponse aurait dû être immédiate; pourtant, pour la plupart, cela ne fut pas le cas.
La réponse de l’Union européenne a été de légiférer. Le Cyber Resilience Act (CRA), est entré en vigueur en décembre 2024. Elle a imposé des exigences de cybersécurité à la quasi-totalité des produits comportant des éléments numériques vendus dans la région : des objets connectés grand public et systèmes de contrôle industriels jusqu’aux logiciels autonomes. Aujourd’hui, la première échéance approche; dès septembre 2026, les fabricants devront signaler toute faille exploitée activement et tout incident grave à l’ENISA ainsi qu’aux CSIRT nationaux sous 24 heures.
Quand les bonnes pratiques deviennent des obligations légales
Le CRA représente un changement fondamental dans la manière dont l’Union européenne traite la sécurité logicielle. Au lieu de s’appuyer sur un cadre volontaire, il positionne la cybersécurité comme une exigence de sécurité des produits, à l’image des normes qui régissent le matériel depuis des décennies. Les produits devront arborer le marquage CE pour prouver leur conformité, et les fabricants seront responsables tout au long du cycle de vie du produit, avec une période de support minimale de cinq ans.
Les sanctions en cas de non-respect sont colossales. Les organisations qui ne satisfont pas les exigences de cybersécurité s’exposent à des amendes pouvant atteindre 15 millions d’euros ou 2,5 % de leur chiffre d’affaires annuel, le montant le plus élevé étant retenu. De plus, les autorités peuvent ordonner le rappel de produits ou le retrait du marché des produits non conformes. La Commission européenne a publié son premier projet de directives sur la mise en œuvre de la loi, et les normes techniques sont attendues plus tard cette année.
Répertorier les logiciels que vous livrez
L’un des piliers du CRA est l’obligation pour les fabricants de produire et de tenir à jour une nomenclature logicielle (SBOM) pour chaque produit comportant des éléments numériques. Un SBOM est un inventaire de chaque élément présent dans un produit, allant des paquets du système d’exploitation et des bibliothèques tierces jusqu’aux dépendances imbriquées sur plusieurs niveaux. Le règlement exige que ce document soit fourni dans un format lisible par machine et qu’il couvre l’intégralité des dépendances de premier niveau.
Les produits logiciels modernes se composent au minimum à 75 % de composants externes, dont beaucoup sont open-source. Selon le rapport 2025 sur la sécurité et l’analyse des risques open-source, 97 % des applications commerciales contiennent désormais des logiciels libres, dont beaucoup présentent des failles connues. Sans un SBOM complet, les fabricants ne peuvent pas identifier de manière fiable si une vulnérabilité nouvellement révélée affecte leurs produits, et encore moins réagir dans les délais de signalement exigés par le CRA.
Cela reflète une tendance mondiale plus large. La directive allemande BSI TR-03183-2 est en train de devenir une référence de qualité à l’échelle de l’Union européenne, tandis que des marchés tels que la Corée du Sud et l’Inde développent des cadres similaires. Pour les fabricants présents sur plusieurs juridictions, la maturité en matière de SBOM est un enjeu de compétitivité mondiale, et non un simple exercice de conformité européenne.
Le problème des faux positifs
Le SBOM détaille le contenu de votre produit ; cependant, il ne vous dit pas si une vulnérabilité signalée est réellement exploitable. Une bibliothèque peut contenir une faille connue, mais si la fonction concernée n’est jamais exécutée dans la version finale, le risque reste théorique. Les outils de scan traditionnels peinent à faire cette distinction. Des recherches de l’Université Cornell évaluent le taux de faux positifs des outils de vulnérabilité logicielle à près de 97,5 %.
De plus, le coût opérationnel est significatif. Les équipes de développement perdent des heures chaque semaine à poursuivre des alertes qui ne s’avèrent être que du bruit, retardant ainsi les lancements et érodant la confiance envers les outils de sécurité. La fatigue liée aux alertes s’installe, et les menaces réelles risquent d’être ignorées. Sous l’obligation de signalement en 24 heures imposée par le CRA, la capacité à distinguer les vulnérabilités réelles des fausses alertes devient une exigence réglementaire.
Développer une chaîne d’approvisionnement logicielle sécurisée
Se conformer au CRA nécessite plus qu’un simple outil de scan et un SBOM. Les organisations ont besoin de capacités couvrant l’identification des vulnérabilités, le tri, la remédiation et la communication, aussi bien en amont avec les fournisseurs de composants qu’en aval avec les clients.
Pour bien choisir ses outils de sécurité, il faut d’abord regarder comment les équipes travaillent. Analyser le code source d’un logiciel, son fichier final ou son micrologiciel revient à regarder un problème sous des angles différents : il n’existe pas de solution miracle qui voit tout. Au lieu de comparer des listes interminables de fonctionnalités, les entreprises devraient tester ces outils sur leur propre code et privilégier deux critères : la précision de la détection et l’absence d’alertes inutiles (les fameux “faux positifs”).
La sécurité ne doit pas être une île isolée. Un tableau de bord rempli de failles de sécurité ne sert à rien s’il n’est pas connecté directement aux outils quotidiens des développeurs (comme les pipelines CI/CD). Si l’information reste coincée dans un coin, la réponse est lente et le risque augmente.
Dès qu’une faille sérieuse est confirmée, le système devrait agir de lui-même en :
- Créant automatiquement un ticket d’incident prioritaire pour les équipes.
- Listant précisément tous les produits impactés.
- Alertant instantanément l’ensemble de la chaîne de production, des fournisseurs jusqu’aux clients.
L’intérêt d’anticiper
La mise en œuvre complète du CRA débutera en décembre 2027, mais dès septembre 2026 les obligations de signalement s’appliqueront à tous les produits déjà présents sur le marché européen. Le cadre d’évaluation de la conformité deviendra opérationnel à l’été 2026, et la demande d’évaluations par des tiers devrait excéder les capacités disponibles. Les organisations qui attendent s’exposent à des lacunes de conformité et à des retards d’accès au marché.
Il existe également une dimension commerciale. Avant de signer des contrats, les équipes d’achats des entreprises doivent poser des questions de plus en plus détaillées sur la posture de sécurité de la chaîne d’approvisionnement. Les entreprises capables de démontrer des pratiques matures en matière de SBOM et une réponse rapide aux vulnérabilités se démarqueront sur un marché où la confiance devient un facteur de différenciation.
Le CRA a clairement établi une condition d’accès au marché et un facteur déterminant dans les relations commerciales : la sécurité logicielle. La transparence de la chaîne d’approvisionnement définit la fiabilité d’une entreprise, ainsi, aucune organisation ne peut se permettre d’attendre.
