L'Union européenne a considérablement renforcé son dispositif de cybersécurité avec l'adoption du règlement (UE) 2024/2847, également connu sous le nom de CRA (Cyber Resilience Act). En tant que premier règlement horizontal en matière de cybersécurité applicable aux produits comportant des éléments numériques (PDE), le CRA établit des exigences de sécurité juridiquement contraignantes pour le matériel et les logiciels mis sur le marché de l'UE.
En 2024, la réglementation a officiellement instauré des obligations en matière de cybersécurité tout au long du cycle de vie des produits, allant du développement sécurisé et de la diligence raisonnable concernant les composants tiers à la gestion des vulnérabilités et au signalement des incidents.
À compter de septembre 2026, les fabricants seront tenus de signaler les vulnérabilités activement exploitées et les incidents de sécurité graves. D'ici décembre 2027, la conformité totale deviendra obligatoire, y compris en matière de documentation, de contrôles de sécurité tout au long du cycle de vie etBill of Materials (SBOM) Software Bill of Materials (SBOM) .
Pour les DSI, les RSSI, les responsables de la sécurité des produits et les équipes chargées de la conformité, la CRA a des implications opérationnelles, financières et réglementaires. Les organisations doivent être prêtes à démontrer qu'elles appliquent des pratiques de sécurité intégrée, à mettre en place une surveillance continue des vulnérabilités, à tenir à jour une documentation SBOM prête pour les audits et à garantir la transparence de la chaîne d'approvisionnement, tant pour les composants propriétaires que pour ceux open source.
Cet article propose un guide pratique pour se conformer à la CRA, abordant les obligations relatives à la chaîne d'approvisionnement logicielle, les exigences en matière de SBOM, les responsabilités tout au long du cycle de vie, ainsi que les mesures stratégiques que les organisations devraient prendre dès maintenant pour se préparer à la mise en application de la réglementation.
Aperçu des exigences de la loi sur la cyber-résilience
Qu'est-ce que la loi sur la cyber-résilience et pourquoi a-t-elle été adoptée ?
La directive CRA établit le premier cadre horizontal européen en matière de cybersécurité pour les produits comportant des éléments numériques.
Le règlement vise à :
- Réduire les vulnérabilités systémiques des produits connectés
- Améliorer la transparence dans les chaînes d'approvisionnement logicielles
- Assurer la gestion des vulnérabilités tout au long du cycle de vie
- Transférer la responsabilité aux fabricants
Qui doit s'y conformer ?
- Software
- Hardware intégrant des logiciels
- Importateurs et distributeurs
- Les développeurs qui intègrent des composants tiers ou open source
- Fournisseurs de produits numériques essentiels ou importants
Supply Chain Software en vertu de la CRA
Vérification préalable des composants
Les fabricants doivent faire preuve de diligence raisonnable concernant les composants tiers, notamment en évaluant les vulnérabilités connues et en assurant le suivi des mises à jour de sécurité.
Responsabilité de bout en bout en matière de vulnérabilité
Les fabricants restent responsables des vulnérabilités affectant l'ensemble des composants intégrés, quelle que soit leur origine.
Secure et Secure
Les produits doivent être livrés avec des configurations par défaut sécurisées et conçus de manière à intégrer la cybersécurité dès leur conception.
Surveillance et signalement des vulnérabilités
Les vulnérabilités activement exploitées et les incidents graves devront être signalés à compter de septembre 2026.
Documentation technique et conservation
La documentation relative à la sécurité, y compris les SBOM (Software ), doit être conservée pendant dix ans à compter de la mise sur le marché du produit.
Exigences relatives à la liste des composants logiciels (SBOM) en vertu de la CRA
La CRA exige des fabricants qu'ils répertorient les composants logiciels utilisés dans les produits comportant des éléments numériques, généralement au moyen de listes de composants logiciels (SBOM) intégrées à la documentation technique du produit. Bien que la réglementation ne prescrive pas de champs spécifiques pour ces listes, les SBOM conformes aux normes de l'industrie comprennent généralement des identifiants de composants, des informations sur les versions, des détails sur les fournisseurs ou l'origine, les relations de dépendance, ainsi que des données d'intégrité telles que des hachages cryptographiques.
La liste des composants (SBOM) doit :
- Lisible par machine
- Conservé dans le cadre de la documentation technique
- Fournies aux autorités de l'UE sur demande motivée
Comment OPSWAT Supply Chain Software de la CRA
1. Transparence Software
- Nom du composant, version et identification du fournisseur
- Cartographie des dépendances directes et transitives
- Identifiants uniques et validation cryptographique
- Gestion centralisée des SBOM
2. Transparence et détection des risques
- Vulnerability detection aux bases de données publiques
- Analyse antivirus au sein des suites logicielles
- Identification des risques inhérents avant la mise en service
- Surveillance continue des nouvelles vulnérabilités CVE
3. Documentation et préparation aux audits
- Génération de SBOM lisible par machine (CycloneDX, SPDX)
- Rapports exportables
- Secure et partage contrôlé
Aligner Software sur les obligations en matière de CRA
| Type de composant | Exemple | Visibilité requise | Responsabilité |
|---|---|---|---|
| Application principale | Plateforme SaaS d'entreprise | SBOM complète au niveau du produit | Fabricant |
| Core | OpenSSL | Suivi des niveaux supérieurs et des vulnérabilités | Fabricant |
| Middleware/Environnement d'exécution | Serveur Web ou environnement d'exécution de conteneurs | Validation des dépendances | Fabricant + Fournisseur |
| Bibliothèques tierces | SDK, API | Inclusion transitive dans la SBOM | Fabricant |
Guide pratique pour la mise en conformité avec la CRA
1. Réaliser une évaluation de l'état de préparation
Évaluer :
- Pratiques actuelles en matière d'inventaire des logiciels
- Génération de la liste des composants logiciels (SBOM) existante
- Niveau de maturité en matière de surveillance des vulnérabilités
- Procédures de conservation des documents
2. Mettre en place une gouvernance interne
Définir clairement les rôles pour :
- Développeurs
- Équipes DevOps
- Équipes de sécurité
- Aspects juridiques et conformité
- Approvisionnement
3. Automatiser la génération de la SBOM
Les outils devraient :
- Générer des SBOM pour chaque version et mise à jour
- Intégration aux pipelines CI/CD
- Sortie aux formats CycloneDX et SPDX
- Vérifier les champs obligatoires
4. Intégrer la SBOM tout au long du cycle de vie du développement logiciel (SDLC)
La maturité de la SBOM évolue au fil des étapes :
- SBOM de conception (composants prévus)
- Générer la SBOM (artefacts compilés)
- SBOM analysée (contrôle après compilation)
- SBOM déployée (environnement de production)
- SBOM d'exécution (surveillance active)
5. Assurer la conformité et la surveillance en continu
- Surveiller en permanence les bases de données de vulnérabilités
- Mettre à jour les SBOM en cas de modification des composants
- Mettre en place des procédures de signalement des vulnérabilités
- Préparer les documents nécessaires aux demandes d'autorisation
Formats de SBOM acceptés dans le cadre de la CRA
CycloneDX
Axé sur la sécurité, optimisé pour la gestion des vulnérabilités.
SPDX
Axé sur les licences, largement utilisé pour la documentation relative à la conformité.
Comment évaluer les solutions de conformité adaptées aux exigences de l'ARC
Lorsque vous choisissez des fournisseurs ou des outils, tenez compte des éléments suivants :
- Génération de SBOM dans les formats pris en charge
- Intégration avec DevOps et les registres de conteneurs
- Surveillance continue des vulnérabilités
- Fonctionnalités d'analyse des logiciels malveillants
- Rapports prêts pour l'audit
- Stockage et partage Secure
Demandez aux fournisseurs :
- À quelle fréquence les SBOM sont-elles mises à jour ?
- Comment gérez-vous les dépendances transitives ?
- Comment les informations sur les vulnérabilités sont-elles intégrées ?
- Comment gérez-vous les processus de déclaration réglementaire ?
Bonnes pratiques pour une mise en œuvre sans heurts de la CRA
- Intégrer la génération de la SBOM dès le début du processus (« shift left »)
- Automatiser la cartographie des dépendances
- Exiger des données SBOM de la part des fournisseurs
- Former les équipes aux responsabilités liées à la CRA
Erreurs courantes à éviter
| Erreur | Risque | Atténuation |
|---|---|---|
| Considérer la SBOM comme un élément statique | Exposition à une vulnérabilité obsolète | Automatiser les mises à jour continues |
| Ignorer les dépendances transitives | Risques cachés liés à la chaîne d'approvisionnement | Utiliser la cartographie récursive des dépendances |
| Processus manuels de gestion de la nomenclature (SBOM) | Incohérence et échec de l'audit | Mettre en place des outils automatisés |
Considérations propres à chaque secteur
- Intégrer la génération de la SBOM dès le début du processus (« shift left »)
- Automatiser la cartographie des dépendances
- Exiger des données SBOM de la part des fournisseurs
- Former les équipes aux responsabilités liées à la CRA
Produits essentiels et importants
Les systèmes d'exploitation, les hyperviseurs, les pare-feu et les composants fondamentaux de l'infrastructure font l'objet d'une surveillance accrue.
Services financiers
Les organisations doivent aligner leur conformité au règlement CRA sur les cadres plus généraux de l'UE en matière de cybersécurité (par exemple, DORA).
Industrial Internet des objets
Les logiciels embarqués doivent garantir la conservation à long terme de la documentation et la surveillance des vulnérabilités.
OPSWAT SBOM
OPSWAT offre aux équipes les fonctionnalités suivantes :
- Inventaires précis des composants logiciels
- Génération de listes de composants logiciels (SBOM) pour le code source et les conteneurs
- Corrélation des vulnérabilités
- Visibilité des licences
SBOM pour Software et les artefacts
Identifier, hiérarchiser et corriger les risques liés aux logiciels libres sans ralentir le développement.
SBOM pour les images de Container
Générez des SBOM à chaque niveau de conteneur et détectez les vulnérabilités avant le déploiement.
MetaDefender Software Supply Chain™
Allez au-delà de la simple documentation et faites face aux menaces avancées pesant sur la chaîne d'approvisionnement.
MetaDefender Software Chain™ intègre une inspection « zero-trust » dans le cycle de développement logiciel (SDLC) en combinant une analyse multi-moteurs avec plus de 30 moteurs antivirus, la détection des secrets codés en dur, l'analyse approfondie de la couche des conteneurs, l'identification des vulnérabilités et des intégrations natives avec les référentiels et les pipelines CI/CD, afin de prévenir les logiciels malveillants, l'exposition des identifiants et les risques liés aux dépendances, tout en facilitant la conformité à des cadres réglementaires tels que la loi européenne sur la cyber-résilience.
FAQ
Dans quels cas la CRA s'applique-t-elle ?
Les obligations de déclaration prendront effet en septembre 2026. La mise en œuvre complète débutera en décembre 2027.
Les SBOM doivent-elles être rendues publiques ?
Non. Elles doivent être fournies aux autorités sur demande motivée.
Les composants open source sont-ils pris en compte ?
Oui. Tous les composants intégrés relèvent de la responsabilité du fabricant.
Quelles sont les sanctions en cas de non-respect ?
Jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial.
L'automatisation est-elle nécessaire ?
Bien qu'elle ne soit pas explicitement imposée, l'automatisation est indispensable pour répondre aux exigences en matière de surveillance du cycle de vie.
Et maintenant ? Se préparer aux mesures coercitives de l'ARC
L'Autorité européenne de protection des données (AEPD) fait de la sécurité de la chaîne d'approvisionnement logicielle une condition préalable à l'exercice d'activités sur le marché de l'UE, en exigeant la traçabilité tout au long du cycle de vie, une surveillance continue des vulnérabilités et une documentation structurée de la liste des composants logiciels (SBOM). Les organisations qui commencent dès maintenant à harmoniser leurs processus de développement et de sécurité peuvent réduire leur exposition aux risques réglementaires tout en renforçant leur résilience globale.
OPSWAT la mise en œuvre des exigences en matière de CRA en intégrant directement dans les processus de développement l'automatisation des listes de composants logiciels (SBOM), les informations sur les vulnérabilités, l'analyse multi-outils et l'inspection « zero-trust », aidant ainsi les fabricants à renforcer leurs chaînes d'approvisionnement logicielles tout en garantissant leur conformité aux audits.
Découvrez comment OPSWAT aider votre organisation à mettre en œuvre les exigences de la CRA et à renforcer la sécurité de votre chaîne logistique logicielle.
