Traitement des vulnérabilités (annexe I, partie II)
C’est ici que le SBOM devient une obligation légale, et c’est la partie de l’annexe I qui engage sur la durée : elle décrit un processus à tenir pendant toute la période de support.
Les huit obligations
1. Recenser et documenter — le SBOM
Recenser et documenter les vulnérabilités et les composants contenus dans le produit, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau.
Le détail est traité dans Ce que le CRA exige du SBOM. Retenir que « premier niveau » est un plancher légal, et que la Commission peut préciser par acte d’exécution le format et les éléments attendus.
2. Traiter et corriger sans délai
Traiter et corriger les vulnérabilités sans délai, notamment par la fourniture de mises à jour de sécurité. Lorsque c’est techniquement possible, les mises à jour de sécurité sont fournies séparément des mises à jour fonctionnelles.
Cette séparation a une conséquence d’ingénierie lourde : elle suppose des branches de maintenance et une capacité de rétroportage, donc une stratégie de versionnement décidée dès la conception. Voir Mises à jour sécurisées.
3. Tester et revoir régulièrement
Appliquer des tests et des revues de sécurité efficaces et réguliers. « Régulier » implique une cadence définie et tenue, pas un test à la sortie d’une version majeure.
4. Publier l’information sur les vulnérabilités corrigées
Une fois une mise à jour de sécurité disponible, publier des informations sur les vulnérabilités corrigées : description, identification des produits concernés, impacts, gravité, et informations aidant les utilisateurs à remédier.
En pratique : des avis de sécurité publiés, idéalement au format CSAF 2.0, lisibles par machine pour que vos clients puissent les traiter automatiquement.
5. Mettre en place et faire appliquer une politique CVD
Mettre en place et faire appliquer une politique de divulgation coordonnée des vulnérabilités. Les deux verbes comptent : une politique publiée mais sans traitement des signalements reçus ne satisfait pas l’exigence. Voir Politique CVD.
6. Faciliter le partage d’informations
Prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles du produit et des composants tiers qu’il contient, notamment en fournissant une adresse de contact.
7. Diffuser les mises à jour de manière sécurisée
Prévoir des mécanismes de diffusion sécurisée des mises à jour, garantissant que les vulnérabilités sont corrigées ou atténuées en temps utile et, lorsque c’est applicable pour les correctifs de sécurité, de manière automatique.
8. Diffuser sans délai et gratuitement
Veiller à ce que les correctifs et mises à jour disponibles soient diffusés sans délai et, sauf accord contraire pour des produits sur mesure entre professionnels, gratuitement, accompagnés de messages consultatifs indiquant aux utilisateurs les actions à entreprendre.
Point souvent manqué. La gratuité des correctifs de sécurité est une règle, pas une option commerciale. Facturer un contrat de maintenance pour accéder aux correctifs de sécurité pendant la période de support est incompatible avec cette exigence.
La diligence sur les composants tiers
Deux obligations complémentaires, à l’article 13, encadrent l’usage de composants que vous n’écrivez pas — y compris libres :
- Diligence raisonnable à l’intégration : évaluer la qualité et la maintenance du composant, vérifier l’absence de vulnérabilités exploitables connues, examiner l’historique de sécurité, la fréquence des publications et la licence. Cette diligence doit être documentée.
- Remontée à l’amont : lorsqu’une vulnérabilité est identifiée dans un composant, y compris libre, la signaler à la personne ou à l’entité qui fabrique ou maintient ce composant, la corriger et — lorsque c’est pertinent — partager le correctif avec le projet amont.
Voir Intégrer de l’open source.
La preuve à constituer
| Obligation | Artefact de preuve |
|---|---|
| 1 | SBOM par version, signé et archivé |
| 2 | Journal de traitement horodaté, délais mesurés par criticité, branches de correctifs |
| 3 | Rapports de tests datés, plan de test, couverture |
| 4 | Avis de sécurité publiés, historique consultable |
| 5 | Politique CVD publiée, registre des signalements reçus et de leur traitement |
| 6 | Adresse de contact active, security.txt, accusés de réception |
| 7 | Description du mécanisme, clés de signature, tests de mise à jour |
| 8 | Historique des publications, messages consultatifs, preuve de gratuité |