Quand créer une vulnérabilité CRA formelle ?

Réponse courte

Créez une vulnérabilité CRA formelle lorsque l’organisation a qualifié une faiblesse dans le contexte d’un produit. La présence d’une CVE ou d’un avis fournisseur ne suffit pas.

Disponibilité produit : Gestion des vulnérabilités disponible dans les deux éditions ; points de sécurité à vérifier réservés à l’édition complète.

Trois niveaux à distinguer

Une référence externe décrit un problème publié par une source. Un point de sécurité à vérifier relie un signal au contexte d’un produit, avec une décision de revue. La vulnérabilité CRA formelle est l’objet suivi par l’organisation après qualification humaine. Ces objets ne sont pas interchangeables et peuvent exister sans CVE publique.

Qualifier avant de déclarer

Vérifiez le composant, la version livrée, la plage affectée et les conditions d’exploitation. Conservez la source et une preuve reproductible ou une analyse expliquant les incertitudes. Une version corrigée dans le dépôt de développement ne prouve pas que les clients utilisent cette version.

Décidez avec le responsable compétent si la faiblesse affecte réellement le produit. Distinguez « non affecté », « à examiner » et « corrigé ». Ne classez pas un signal en faux positif uniquement parce qu’il gêne un indicateur.

Informations à conserver

Lors de la déclaration, renseignez le titre, le statut, la criticité, la source et le niveau de confiance. Associez le composant ou le point de sécurité pertinent lorsqu’il existe, puis la référence externe et le résumé de remédiation. La criticité et la confiance répondent à des questions différentes : gravité possible et solidité des informations.

L’exploitation active peut être À déterminer, Non ou Oui. Si une notification est envisagée, documentez séparément la date et l’heure de prise de connaissance ainsi que la décision ENISA et sa justification. Un score CVSS élevé ou l’inscription dans une source publique ne constitue pas à lui seul cette décision.

Exemple et limites

« Passerelle Atlas » contient une bibliothèque vulnérable, mais la fonction concernée est désactivée. L’équipe conserve l’analyse de configuration et vérifie si cette condition élimine réellement le scénario. Elle peut demander des vérifications supplémentaires plutôt que déclarer le produit corrigé sans preuve.

La qualification doit être réexaminée si une nouvelle version, configuration ou information fournisseur change l’exposition. Une vulnérabilité héritée se modifie sur le produit source autorisé ; la composition ne génère pas automatiquement une déclaration ENISA.

Articles liés

• Préparer une notification
• Retrouver le produit source

Article issu de la base de connaissance CRA Manager.