Comment passer de la conformité CRA à une sécurité opérable ?

On voit la même scène se répéter partout.

Une nouvelle réglementation arrive (CRA).

Tout le monde panique.

On lance un chantier “SBOM”.

On génère une liste.

On coche une case.

Et on se dit : “bon, on est safe”.

Non.

Un SBOM n’est pas de la sécurité.

Un SBOM, c’est de la gouvernance de dépendances.

Et c’est déjà énorme.

Mais c’est seulement le début.

1) Le CRA change la nature du jeu

Le CRA ne demande pas “faites de votre mieux”.

Il impose une logique opérable :

• savoir ce que vous embarquez,
• surveiller les vulnérabilités,
• décider et prouver,
• corriger dans le temps.

Le mot important, c’est dans le temps.

La conformité devient une cadence.

2) Le SBOM : rendre le produit lisible

Sans SBOM, vous êtes aveugle.

Avec SBOM, vous voyez.

Mais voir n’est pas agir.

Un bon SBOM doit être :

• automatique (à chaque build),
• versionné,
• lié à un firmware précis,
• exploitable par des outils (pas un PDF oublié).

3) La vraie boucle : vulnérabilité → décision → patch → preuve

Le cœur opérationnel, c’est un pipeline.

1. Détection : CVE, alertes fournisseurs, scanning.
2. Qualification : suis-je concerné ? impact réel ? exploitabilité ?
3. Décision : corriger, mitiger, accepter, ou remplacer.
4. Déploiement : OTA, release, communication.
5. Preuve : logs, tickets, versions, SBOM mis à jour.

Ce n’est pas un sujet “cyber”.

C’est un sujet produit.

4) Les erreurs classiques

• Générer un SBOM une fois, puis ne jamais le régénérer.
• Confondre “zéro vulnérabilité” avec “zéro risque”.
• Ne pas avoir de capacité OTA, donc être incapable de corriger.
• Ne pas savoir qui décide (CTO ? CISO ? PM ?)

Dans le hardware connecté, l’incapacité à patcher est un défaut de design.

Conclusion

Le CRA oblige une vérité simple :

la sécurité n’est pas un projet.

C’est une fonction.

Le SBOM est la carte.

La sécurité, c’est le trajet.

Et ce trajet doit être praticable, encore et encore.

La bonne question n’est pas : “avez-vous un SBOM ?”

La bonne question est : combien de temps vous faut-il pour corriger une vulnérabilité critique, et comment le prouvez-vous ?

CRA : Cyber Resilience Act
SBOM : Software Bill of Materials