CRA : ce qu'on vous demandera de montrer
Vous savez produire un inventaire de composants. Reste à savoir ce qu'un auditeur vous demandera de prouver, et où cette preuve se fabrique dans votre chaîne. La checklist, obligation par obligation.
Vous savez produire un inventaire de composants. Ce que vous ne savez pas, c’est ce qu’on vous demandera de montrer le jour où une vulnérabilité de votre produit sera activement exploitée. Cette page répond à cette question, obligation par obligation.
Ce n’est pas un manque de votre côté. Les lignes directrices de la Commission européenne font quatre-vingt-quatre pages. Elles précisent les délais, le moment où ils commencent à courir, le sort des composants tiers. Et le mot SBOM n’y apparaît pas une seule fois — ni software bill of materials, ni aucun format d’inventaire, ni le mot inventaire lui-même. Le texte dit quand, qui et quoi. Il ne dit rien du comment.
➡️ Obtenir une première lecture → Gratuite, une heure. Nous passons cette checklist sur votre chaîne et vous repartez avec la liste de ce qui manque.
La checklist
Les références renvoient aux paragraphes de l’annexe aux lignes directrices, communication C(2026) 5252 du 27 juillet 2026. Ce texte est une interprétation, non contraignante en droit (§8).
| Ce qu’on vous demande | Ce que vous devez montrer | Où ça se fabrique |
|---|---|---|
| Avoir signalé une vulnérabilité activement exploitée : alerte sous 24 h, notification sous 72 h, rapport final au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible (§215) | À quel moment vous en avez pris connaissance, et la trace de l’évaluation qui vous a donné un degré raisonnable de certitude (§213) | Un registre d’incidents relié à la veille, avec des gabarits de notification versionnés |
| Savoir si le composant vulnérable est réellement atteignable dans votre produit (§218) | Vos composants version livrée par version livrée, et la démonstration que le code vulnérable est atteint ou ne l’est pas | L’inventaire produit par le build, jamais saisi à la main, avec une analyse d’atteignabilité |
| Suivre les vulnérabilités publiées (§233-235) | Que vous surveillez la base européenne des vulnérabilités, créée par l’article 12(2) de la directive (UE) 2022/2555, ainsi que les autres bases publiques de référence, et que vous avez enquêté sur l’applicabilité à votre produit | Une veille branchée sur l’intégration continue, qui garde la trace de chaque décision |
| Remonter la vulnérabilité au mainteneur du composant (§223-227) | La remontée faite pour la version que vous intégrez, et le correctif partagé en format lisible par machine | Une étape du pipeline qui ouvre l’avis chez l’amont et conserve le lien |
| Tester et revoir régulièrement (§238-240) | Non pas une cadence fixe, mais que vous revoyez votre jeu de tests quand la menace change, puis que vous l’exécutez | Un journal de revue du jeu de tests, et l’exécution en intégration continue, régression comprise |
| Qualifier un changement de substantiel ou non (§103-109) | Une analyse de risque qui anticipe votre feuille de route, et une décision tracée pour chaque changement | L’analyse de risque versionnée avec le code, revue à chaque évolution du périmètre |
Deux points contre-intuitifs
Vos produits déjà livrés comptent. L’obligation de signalement s’applique depuis le 11 septembre 2026 à tous les produits dans le périmètre, y compris ceux que vous avez mis sur le marché il y a quatre ans, et bien avant l’échéance de décembre 2027 (§210).
Une mise à jour de sécurité n’est en général pas une modification substantielle. Même lourde techniquement, tant qu’elle n’ajoute pas de risque et ne change pas la finalité du produit (§108). L’exception est explicite : elle le devient si elle modifie de façon significative les frontières ou les dépendances du produit d’une manière non prévue dans votre analyse de risque, par exemple en altérant les flux de données ou en ajoutant des interfaces accessibles depuis l’extérieur (§109). La distinction ne se joue donc pas sur l’ampleur technique du changement, mais sur ce qu’il expose et sur ce que votre analyse de risque avait anticipé.
Ce qui vous manque n’est pas un outil
L’inventaire, Syft et Trivy le génèrent gratuitement. Ce qui bloque, c’est de pouvoir affirmer que cet inventaire correspond à ce qui tourne réellement dans le produit livré, et de le prouver. Un inventaire saisi à la main ou reconstitué après coup reste difficile à défendre : rien dans le règlement ne l’interdit, mais rien ne prouve non plus qu’il décrit le produit livré.
Ce que nous mettons en place, c’est une documentation de conformité produite par la chaîne de build elle-même. Un inventaire attesté par un build reproductible, une vérification à l’exécution sur banc matériel, et des artefacts archivés à chaque livraison. L’inventaire, l’analyse de risque et les scanners deviennent des composants de cette chaîne, pas le livrable. C’est le même métier que l’industrialisation logicielle, appliqué à la preuve.
Ce que ça donne, le jour où ça tombe
Prenons un cas. Une vulnérabilité est publiée sur une bibliothèque de chiffrement que vous embarquez. Voici ce que la chaîne a déjà fait pour vous, et ce qu’il vous reste à décider.
- La preuve existe avant l’alerte. Votre firmware 2.4.1 est sorti du build 1847, qui a produit l’inventaire de ses composants et l’a signé. Rien à reconstituer dans l’urgence.
- Le rapprochement est automatique. La veille relie la vulnérabilité publiée à ce composant, dans cette version précise, et vous dit lesquelles de vos versions livrées la contiennent.
- L’atteignabilité tranche. L’analyse dit si le code vulnérable est réellement appelé dans votre produit. S’il ne l’est pas, vous n’avez pas à signaler — mais vous devez pouvoir le démontrer (§218).
- La décision est datée et motivée. C’est elle qui établit le moment où vous avez atteint un degré raisonnable de certitude, et donc le point de départ de vos 24 heures (§213).
- Le correctif est validé sur le matériel réel. Le test de régression tourne sur banc, pas seulement en simulation.
- Le dossier se referme tout seul. Inventaire, rapprochement, analyse, décision, résultat de test : les artefacts du build 1848 sont votre preuve, archivés sans travail supplémentaire.
Sans cette chaîne, chacune de ces six étapes est un travail manuel, à refaire à chaque alerte, dans la fenêtre de 24 heures.
Commencer
Obtenir une première lecture → Une heure, gratuite et sans engagement.
Nous parcourons cette checklist sur votre chaîne, ligne par ligne : périmètre probable, classe probable, prochains pas. Vous repartez avec la liste de ce qui manque et l’ordre dans lequel le traiter, que vous nous confiiez la suite ou non.
Vous ne savez pas encore si votre produit entre dans le périmètre ? Trois minutes suffisent à le situer, sans inscription ni adresse e-mail.
Pour le cadre général, les paliers et le budget, voir notre offre CRA. Si vous fabriquez en Suisse, ce que le CRA change pour une entreprise suisse.