Tenir les preuves CRA par produit : SBOM, vulnérabilités connues et documentation technique

• La classification au regard des annexes III et IV, la procédure d’évaluation de la conformité qui en découle et votre justification.
• La version, la mise sur le marché et la période de support du produit commercialisé.
• La SBOM de cette version, les vulnérabilités connues de ses composants et leur traitement.
• Les documents : documentation technique (annexe VII), évaluation des risques de cybersécurité, informations destinées aux utilisateurs (annexe II), déclaration UE de conformité (annexe V) et politique de divulgation coordonnée des vulnérabilités.
• Un canal de signalement externe et un contact de sécurité.

Générez la SBOM lors de la compilation du logiciel et transmettez-la automatiquement au dossier produit. Attesly accepte les fichiers CycloneDX et SPDX par téléversement, par collage ou depuis votre pipeline CI via l’API.

• L’original est conservé : le fichier soumis est archivé avec un reçu d’importation numéroté et une somme de contrôle. Les fichiers précédents restent disponibles après les importations suivantes.
• Les vulnérabilités connues sont rapprochées : les composants dotés d’une URL de paquet sont comparés à OSV.dev lors de l’importation et des nouvelles analyses manuelles.
• Ce n’est pas un analyseur de code : Attesly lit les SBOM produites par vos outils ; il n’analyse ni votre code source ni vos fichiers binaires.

Chaque nouvelle version pose les mêmes questions : la SBOM correspond-elle encore au produit sur le marché ? Quels résultats cette version corrige-t-elle ? La modification affecte-t-elle la conformité ? Vous devez pouvoir justifier votre appréciation d’une modification substantielle au sens de l’article 3, point 30. Conservez les réponses dans le dossier produit plutôt que dans un simple e-mail d’annonce de version.

• Les importations de SBOM sont numérotées, pour que l’inventaire de chaque version reste traçable après l’importation suivante.
• Les résultats indiquent la version qui les corrige, à côté de votre évaluation.
• Les documents sont versionnés et portent une indication de langue ; les versions précédentes restent dans l’historique.
• La période de support conserve sa justification : les informations prises en compte lors de sa détermination sont enregistrées avec elle.

Exemple fictif avec le fabricant de démonstration Northwind Robotics et son NW-200 Edge Controller.

1. La compilation du micrologiciel NW-200 2.3 se termine par l’envoi du fichier CycloneDX au dossier produit. Le fichier est conservé avec son reçu et la liste des composants est actualisée.
2. Le rapprochement avec OSV.dev signale une vulnérabilité connue dans un composant. L’équipe consigne son évaluation et la version prévue pour le correctif.
3. Le micrologiciel 2.4 est livré avec le correctif. L’équipe actualise la version du produit, marque le résultat comme corrigé en 2.4 et explique pourquoi il s’agit d’un correctif de sécurité ordinaire plutôt que d’une modification substantielle.
4. La documentation technique reçoit une nouvelle version ; la précédente reste dans l’historique.
5. Les importateurs et distributeurs consultent la page de confiance publique du produit plutôt que de demander des fichiers par e-mail.

Le score de préparation d’Attesly résume le degré de complétude d’un dossier à partir de vos propres données. Il aide à repérer les lacunes ; il ne constitue pas une évaluation de conformité.

Attesly est un outil de documentation et d’organisation du travail. Il ne certifie pas de produits, n’est pas un organisme notifié et ne fournit pas de conseil juridique. Consultez les offres et tarifs, prenez rendez-vous ou découvrez comment préparer une notification article 14.