Cyber Resilience Act : les échéances qui arrivent.
Le CE du numérique : sécurité par conception, mises à jour obligatoires, signalement des failles exploitées sous 24 h dès le 11 septembre 2026. Ce qui vous concerne.
Vous avez durci vos serveurs, généralisé le MFA, formé vos équipes. Puis votre logiciel de comptabilité publie une mise à jour, signée, légitime, distribuée par le canal officiel - et elle contient du code qui ne devrait pas s'y trouver. Vous venez d'installer vous-même l'intrusion, avec les droits d'administration, en suivant scrupuleusement la bonne pratique qui consiste à rester à jour.
C'est la particularité de l'attaque par la chaîne d'approvisionnement : elle ne force aucune porte. Elle entre par celle que vous tenez ouverte pour vos fournisseurs, et qui doit le rester pour que votre système fonctionne.
En résumé
- L'attaque par la chaîne d'approvisionnement ne force aucune porte : elle entre par celle que vous tenez ouverte pour vos fournisseurs, et qui doit le rester pour que votre système fonctionne.
- Deux problèmes distincts sous un même nom : l'éditeur compromis (rare, spectaculaire, hors de votre portée) et la dépendance ouverte (bien plus fréquente, et c'est là que se joue l'essentiel).
- Le piège est la profondeur : vous avez choisi douze bibliothèques, votre application en embarque huit cents, et personne n'a jamais évalué les autres.
- Un SBOM ne protège de rien : il transforme une enquête de trois semaines en une recherche de dix minutes le jour où une faille critique sort. C'est exactement ce qui compte dans une course contre un attaquant.
- Ne pas avoir de développeurs n'exonère de rien : la question devient contractuelle - en combien de temps mon prestataire corrige-t-il un composant qu'il a mis dans mon application ?
- NIS2 et le Cyber Resilience Act font passer le sujet de la bonne pratique à l'obligation, pour qui vend comme pour qui achète.
Deux problèmes différents sous un même nom
On mélange souvent deux choses qui n'appellent pas les mêmes réponses.
- Le fournisseur compromis. Un éditeur dont on pirate la chaîne de production, et dont la mise à jour légitime devient le vecteur. Rare, spectaculaire, difficile à prévenir de votre côté : vous ne pouvez pas auditer la sécurité interne de chacun de vos éditeurs.
- La dépendance ouverte. Votre application - ou celle de votre prestataire - agrège des dizaines de bibliothèques libres, qui en appellent elles-mêmes des centaines d'autres. Une seule d'entre elles, maintenue bénévolement par une personne, suffit. C'est infiniment plus fréquent, et c'est là que se joue l'essentiel.
Le second cas a une propriété désagréable : la profondeur. Vous avez choisi douze bibliothèques ; votre application en embarque peut-être huit cents. Les sept cent quatre-vingt-huit autres, personne ne les a jamais évaluées - elles sont arrivées comme dépendances de dépendances.
Pourquoi « on n'a pas de développeurs » ne vous exonère pas
Une PME qui n'écrit pas de code hérite quand même de ce risque, par ses prestataires et ses logiciels. La question n'est alors plus « quelles bibliothèques utilisons-nous » mais « que fait mon prestataire quand une faille critique sort dans un composant qu'il a mis dans mon application, et en combien de temps ? ». Cette question se pose au contrat, pas après l'incident.
Le SBOM, en une phrase et sans jargon
Un SBOM (Software Bill of Materials) est la liste des ingrédients d'un logiciel : tous les composants qu'il contient, avec leur version. Exactement la même idée que la composition sur un emballage alimentaire.
Son intérêt tient tout entier dans une situation, et il faut l'avoir vécue pour le comprendre. Une faille critique est annoncée dans un composant très répandu, un vendredi soir. La question devient : est-ce que je suis concerné ?
- Sans SBOM, vous appelez vos éditeurs et vos prestataires, et vous attendez. La réponse arrive en trois jours, parfois en trois semaines, parfois jamais. Pendant ce temps la faille est exploitée.
- Avec SBOM, vous cherchez le nom du composant dans une liste. Vous savez en dix minutes lesquelles de vos applications sont concernées, et vous corrigez dans le bon ordre.
Le SBOM ne protège de rien. Il transforme une enquête de trois semaines en une recherche de dix minutes - ce qui, dans une course contre un attaquant, est précisément ce qui compte.
Ce que la réglementation vient changer
Ce sujet quittait déjà le terrain de la bonne pratique ; il devient une obligation. Deux textes convergent :
- NIS2 traite explicitement la sécurité de la chaîne d'approvisionnement comme une mesure attendue : les entités concernées doivent tenir compte du risque porté par leurs fournisseurs directs, ce qui se traduit par des exigences contractuelles.
- Le Cyber Resilience Act impose aux fabricants de produits numériques des obligations de sécurité par conception, de gestion des vulnérabilités et de transparence sur les composants, sur toute la durée de vie du produit.
Conséquence pratique, quelle que soit votre taille : si vous vendez du logiciel ou du matériel connecté, vous devrez documenter vos composants. Si vous en achetez, vous serez en position de l'exiger - et vos propres clients vous le demanderont.
Le piège du SBOM qu'on produit et qu'on range
Beaucoup d'organisations génèrent un SBOM pour cocher une case, puis le déposent dans un répertoire. Il vieillit à la première mise à jour et devient trompeur. Un SBOM n'a de valeur que s'il est régénéré à chaque livraison et interrogeable rapidement. Un inventaire d'ingrédients périmé est pire qu'aucun : il vous fera répondre « non concerné » à tort.
Par où commencer, selon ce que vous êtes
Vous produisez du logiciel.
- Générez le SBOM automatiquement à chaque construction, dans un format standard. Fait à la main, il sera faux ; fait automatiquement, il est gratuit.
- Branchez une alerte sur les vulnérabilités connues de vos dépendances, et traitez d'abord ce qui est réellement exposé - toutes les failles d'une bibliothèque ne sont pas atteignables dans votre usage.
- Figez vos versions et vérifiez leur intégrité, pour qu'une construction soit reproductible et qu'un composant ne change pas sous vous.
Vous achetez du logiciel.
- Ajoutez au contrat un délai de correction pour les failles critiques, et l'obligation de vous notifier quand un composant de votre solution est touché. C'est la clause qui a le plus d'effet, et elle ne coûte rien à négocier avant la signature.
- Demandez le SBOM. La réponse renseigne autant que le document : un éditeur qui ne sait pas ce qu'il livre ne saura pas non plus vous dire s'il est concerné.
- Sachez qui peut pousser du code chez vous - un accès de télémaintenance ouvert en permanence est une chaîne d'approvisionnement à lui seul.
Le fond du sujet est là : la sécurité de votre système ne s'arrête plus à votre périmètre. Elle inclut désormais les décisions de gens que vous n'avez jamais rencontrés.
Reprendre la main sur vos dépendances
Kenawek vous aide à cartographier ce que vos applications embarquent réellement, à poser les bonnes clauses dans vos contrats fournisseurs, et à savoir en dix minutes si une faille vous concerne. Parlons-en.