Analyse des vulnérabilités et SBOM
Le CRA transforme votre nomenclature logicielle en une obligation vivante : savoir ce que contient votre produit, surveiller ces composants à la recherche de nouvelles vulnérabilités, puis les corriger et les signaler dans les délais de l’article 14. Cette page parcourt la boucle, et l’outil gratuit qui l’exécute.
Générer un SBOM
Produisez une nomenclature logicielle lisible par machine couvrant au moins vos dépendances de premier niveau. C’est une exigence ferme, pas une bonne pratique.
Comment le générer ↓Surveiller les vulnérabilités
Recoupez en continu chaque composant avec les données de vulnérabilité en direct (NVD, EUVD). Les notifications groupées ne respectent pas le délai de 24 heures.
Pourquoi les notifications groupées sont insuffisantes ↓Évaluer, corriger et signaler
Documentez l’exploitabilité, déployez un correctif et signalez les vulnérabilités activement exploitées à l’ENISA et au CSIRT selon le calendrier 24 h / 72 h / 14 jours.
L’outil qui s’en charge ↓Analyseur de vulnérabilités CRA
Téléversez votre SBOM et votre liste de vulnérabilités actives. L’Analyseur recoupe chaque composant avec la base de données nationale des vulnérabilités (NVD) et la base de données de l’UE (EUVD), signale les composants en fin de vie et génère un rapport de conformité que vous pouvez joindre à votre dossier technique.
Guides pratiques
Générer un SBOM conforme
Une nomenclature logicielle est une exigence juridique ferme au titre de l’annexe I, partie II, point (1). Ce guide couvre le périmètre et le format obligatoires, la manière d’en générer une, et son rôle dans la boucle de surveillance.
1 · Base juridique
L’annexe I, partie II (« Exigences en matière de gestion des vulnérabilités »), point (1) impose aux fabricants de « recenser et documenter les vulnérabilités et les composants […] notamment en établissant une nomenclature logicielle dans un format courant et lisible par machine couvrant au moins les dépendances de premier niveau du produit ».
Contrairement à certaines dispositions du CRA qui laissent une marge d’interprétation, l’obligation de produire un SBOM lisible par machine couvrant au moins les dépendances de premier niveau n’admet pas d’autre approche.
2 · Périmètre et format obligatoires
Couverture des composants. Le SBOM doit documenter toutes les dépendances de premier niveau, le minimum légal plutôt que la cible recommandée. Cartographiez les dépendances transitives (indirectes) lorsque c’est possible ; un SBOM superficiel respecte la lettre de la loi mais est souvent insuffisant pour une gestion efficace des vulnérabilités.
Format. Le CRA impose un « format courant et lisible par machine ». Les formats acceptés comprennent :
- SPDX (ISO/IEC 5962:2021) : largement adopté, axé sur les licences, adapté à la documentation de conformité.
- CycloneDX : centré sur la sécurité, bien adapté aux flux de gestion des vulnérabilités.
- D’autres formats structurés (JSON, XML) issus d’outils reconnus sont généralement acceptables au regard de l’exigence de base.
Ne stockez pas les SBOM en PDF. Le PDF peut être contesté comme non lisible par machine par les autorités de surveillance du marché. Conservez la sortie native JSON, XML ou tag-value de votre chaîne d’outils.
Champs de métadonnées requis
| Champ | Description |
|---|---|
| Nom du composant | Identifiant unique de la bibliothèque, du paquet ou du module |
| Version | Chaîne de version exacte ; les plages de versions sont insuffisantes |
| Fournisseur / origine | Nom de l’éditeur, du fournisseur ou du projet open source |
| Relations de dépendance | Directes ou transitives ; graphe de dépendances lorsque c’est possible |
| Empreinte cryptographique | Contrôle d’intégrité SHA-256 ou plus fort par composant |
| Identifiant de licence | Expression de licence SPDX (p. ex. Apache-2.0, MIT) |
3 · Générer votre SBOM
La plupart des plateformes modernes peuvent générer des SBOM automatiquement à la compilation, sans coût supplémentaire :
- GitHub / Actions : Dependency Graph → Export SBOM (Settings → Code security). Produit du SPDX JSON.
- GitLab : Les rapports CycloneDX sont générés nativement par le job CI/CD d’analyse des dépendances.
- Syft (Anchore) : CLI open source produisant du SPDX et du CycloneDX pour les images de conteneurs, les systèmes de fichiers et les manifestes de paquets.
- cdxgen : SBOM CycloneDX pour npm, Maven, pip, Go, Rust et bien d’autres.
Analyse des vulnérabilités. Avant de finaliser un SBOM, analysez chaque composant par rapport aux bases de vulnérabilités connues. Le scanner de GitHub comme Syft s’intègrent à Grype pour cela. Inclure un composant présentant une vulnérabilité connue et déjà corrigée constitue une violation directe de l’annexe I et n’admet aucune marge d’interprétation.
Si une version corrigée d’un composant existe, vous devez l’utiliser. Il n’existe pas de catégorie « risque accepté » au titre du CRA pour les vulnérabilités résolues. Agissez sur chaque constat avant de mettre le produit sur le marché.
4 · Maintenance du cycle de vie et conservation
Un SBOM est un artefact vivant, mis à jour en continu tout au long du cycle de vie pris en charge du produit pour refléter les composants corrigés, les nouvelles dépendances, les composants en fin de vie retirés et les changements de chaîne d’approvisionnement. Toutes les versions de la documentation technique, y compris les SBOM, doivent être conservées pendant au moins 10 ans à compter de la première mise sur le marché…
Sections 4 à 9 : cycle de vie, sanctions, BSI TR-03183-2 et la liste de préparation
Le reste du guide couvre l’obligation de conservation de 10 ans, la confidentialité et la divulgation dans la chaîne d’approvisionnement, l’intégration au signalement des vulnérabilités de l’article 14, la fréquence de surveillance, les règles plus strictes du BSI allemand, les amendes (jusqu’à 15 M€ ou 2,5 % du chiffre d’affaires) et une liste de préparation prête à l’emploi.
Outils et analyses associés
Matrice de conformité
Chaque obligation du cycle de vie avec sa référence d’article ; suivez votre avancement et téléchargez la liste complète.
État des lieux
Où en est le CRA aujourd’hui : actes d’exécution, normes harmonisées et la route vers décembre 2027.
Calculateur de coûts
Une estimation indicative de ce que la mise et le maintien en conformité sont susceptibles de coûter.