CRA
Réglementation
Cyber Resilience Act. Règlement européen publié en décembre 2024 qui impose des exigences de cybersécurité à tous les produits comportant des éléments numériques mis sur le marché européen.
Lien CRA : Article 13 — Oblige les fabricants à assurer la sécurité du produit pendant toute sa durée de vie.
Exemple : Un fabricant de routeurs industriels doit prouver que son produit respecte les exigences CRA avant de le vendre en Europe.
SBOM
Composants
Software Bill of Materials. Liste exhaustive et structurée de tous les composants logiciels d’un produit : bibliothèques open source, dépendances, firmware, modules tiers.
Lien CRA : Article 13 §1 — Le SBOM est la base de toute conformité CRA. Sans lui, impossible d’identifier rapidement quels composants sont touchés par une CVE.
Exemple : Un SBOM liste « OpenSSL 3.0.2, libcurl 7.88, Linux kernel 5.15… » avec les versions exactes de chaque composant.
CVE
Vulnérabilités
Common Vulnerabilities and Exposures. Identifiant unique attribué à chaque vulnérabilité de sécurité connue, publié dans une base de données publique maintenue par le MITRE.
Lien CRA : Article 13 §6 — Le CRA oblige à surveiller les CVE affectant vos composants et à traiter les vulnérabilités critiques en 24h.
Exemple : CVE-2021-44228 est l’identifiant de Log4Shell, la faille critique Log4j découverte en 2021.
VEX
Vulnérabilités
Vulnerability Exploitability eXchange. Document structuré qui indique si une CVE connue est exploitable dans un produit spécifique, et dans quel contexte.
Lien CRA : Article 13 §6 — Le VEX permet d’informer vos clients de l’impact réel d’une CVE sans divulguer votre architecture interne.
Exemple : Quand Log4Shell est publiée, un VEX permet de dire « notre produit utilise Log4j mais la fonctionnalité vulnérable est désactivée — risque non exploitable ».
CVSS
Vulnérabilités
Common Vulnerability Scoring System. Score de 0 à 10 qui évalue la sévérité d’une vulnérabilité selon des critères standardisés : complexité d’exploitation, impact, vecteur d’attaque.
Lien CRA : Le CRA impose des délais de correction proportionnels à la criticité. Une CVE avec CVSS > 9 activement exploitée doit être signalée à l’ENISA sous 24h.
Exemple : CVE-2021-44228 (Log4Shell) a un score CVSS de 10/10 — exploitation triviale avec impact maximal.
ENISA
Réglementation
European Union Agency for Cybersecurity. Agence européenne chargée de la cybersécurité, qui reçoit les notifications d’incidents et de vulnérabilités activement exploitées.
Lien CRA : Article 14 — En cas de vulnérabilité activement exploitée dans votre produit, vous devez notifier l’ENISA dans les 24 heures.
Exemple : Un fabricant découvre qu’une faille de son firmware est exploitée. Il notifie l’ENISA via le portail dédié dans les 24h.
PSIRT
Processus
Product Security Incident Response Team. Équipe interne dédiée à la réception, l’évaluation et le traitement des signalements de vulnérabilités sur les produits d’une organisation.
Lien CRA : Le CRA exige un processus de gestion des vulnérabilités. Le PSIRT est l’implémentation organisationnelle de cette obligation.
Exemple : Quand un chercheur signale une faille dans votre produit, c’est le PSIRT qui évalue la criticité et coordonne la réponse.
CycloneDX
Standards
Format open source de SBOM développé par l’OWASP. Permet de représenter les composants logiciels, leurs dépendances et les vulnérabilités associées en JSON ou XML.
Lien CRA : Standard de facto recommandé par la Commission européenne pour les SBOM conformes au CRA.
Exemple : Un SBOM CycloneDX exporté depuis votre pipeline CI/CD liste automatiquement tous les composants avec leurs versions et licences.
SPDX
Standards
Software Package Data Exchange. Standard ISO (ISO 5962:2021) de représentation des SBOM développé par la Linux Foundation, orienté gestion des licences.
Lien CRA : Compatible avec les exigences CRA, comme CycloneDX. Le choix entre les deux dépend de votre outillage existant.
Exemple : GitHub génère automatiquement des SBOM au format SPDX pour les dépôts publics depuis 2023.
Déclaration de conformité UE
Réglementation
Document formel par lequel le fabricant atteste que son produit respecte les exigences du CRA. Doit accompagner le produit mis sur le marché européen.
Lien CRA : Article 28 — Obligatoire avant mise sur le marché. Le fabricant engage sa responsabilité en signant ce document.
Exemple : Avant de vendre un routeur industriel en Europe, le fabricant signe une déclaration attestant la conformité CRA et CE.
Marquage CE
Réglementation
Marquage obligatoire sur les produits vendus dans l’EEE attestant la conformité aux réglementations européennes applicables, dont le CRA pour les produits numériques après 2027.
Lien CRA : Le CRA ajoute des exigences cybersécurité au marquage CE. Un produit non conforme au CRA ne pourra plus apposer le marquage CE.
Exemple : Un objet connecté vendu en France sans marquage CE incluant conformité CRA sera interdit à la vente après 2027.
Durée de support
Processus
Période pendant laquelle le fabricant s’engage à fournir des mises à jour de sécurité. Doit être communiquée à l’acheteur avant la vente.
Lien CRA : Article 13 §14 — Le CRA impose une durée de support minimale proportionnelle à la durée d’utilisation attendue.
Exemple : Un fabricant de caméras annonce « support sécurité garanti 5 ans ». Il doit informer ses clients à l’échéance.
Security by Design
Processus
Approche de développement qui intègre la sécurité dès la phase de conception plutôt qu’en correctif. Implique une analyse de menaces et des exigences sécurité.
Lien CRA : Article 13 §8 — Le CRA exige que les fabricants intègrent la sécurité dès la conception et documentent leurs décisions.
Exemple : Plutôt qu’activer le chiffrement après un incident, une équipe Security by Design le définit comme exigence dès les premières spécifications.
Analyse de risque
Processus
Processus d’identification et d’évaluation des menaces pesant sur un produit, de leur probabilité et de leur impact. Aboutit à des décisions documentées.
Lien CRA : Article 13 §8 — Une analyse de risque documentée est obligatoire et doit être mise à jour tout au long du cycle de vie.
Exemple : Une analyse identifie que votre API d’administration est exposée à Internet — risque critique — et documente la décision de la protéger par authentification forte.
Chaîne d’approvisionnement logicielle
Composants
Ensemble des composants, outils, processus et fournisseurs qui contribuent à la création d’un logiciel — des bibliothèques open source aux sous-traitants.
Lien CRA : Le CRA étend la responsabilité du fabricant à ses fournisseurs. Un composant vulnérable intégré sans contrôle engage la responsabilité du fabricant final.
Exemple : L’attaque SolarWinds (2020) a compromis des milliers d’organisations en injectant du code malveillant dans un outil de mise à jour légitime.
Patch / Correctif
Composants
Mise à jour logicielle qui corrige une ou plusieurs vulnérabilités de sécurité. Doit être distribué via un canal sécurisé et authentifié.
Lien CRA : Le CRA oblige à mettre à disposition des correctifs pendant toute la durée de support et à notifier les utilisateurs affectés.
Exemple : Après une faille dans son firmware, un fabricant IoT publie un correctif signé cryptographiquement téléchargeable via HTTPS.
NIS 2
Réglementation
Directive européenne sur la sécurité des réseaux et des systèmes d’information (2022). Élargit les obligations de cybersécurité aux opérateurs d’importance essentielle et importante.
Lien CRA : NIS 2 et CRA sont complémentaires : NIS 2 cible les opérateurs de services, le CRA cible les fabricants de produits.
Exemple : Un fabricant de systèmes de contrôle industriel peut être soumis à la fois au CRA (fabricant) et à NIS 2 (infrastructures critiques).
