Capacités Produit & Architecture Technique | CRA Direct

1. Objectif

CRA Direct aide les fabricants de produits comportant des éléments numériques à piloter la conformité au Cyber Resilience Act : enregistrement des produits, collecte des preuves SBOM, tri des vulnérabilités, validation humaine, soumission des déclarations sur la plateforme SRP et conservation des preuves d'audit.

La plateforme repose sur un principe simple : l'automatisation prépare, priorise, valide, rappelle et soumet, mais les décisions à portée juridique restent sous contrôle humain et sont conservées dans une piste d'audit. Les preuves de conformité sont traitées comme un système d'enregistrement réglementaire — SBOM, décisions, notifications et événements d'audit sont liés, conservés et vérifiables de manière indépendante.

2. Utilisateurs et authentification

CRA Direct utilise Zitadel pour l'authentification unique (SSO). Les rôles Zitadel sont directement associés aux permissions de la plateforme :

• Relecteurs sécurité et conformité — trient les vulnérabilités, enregistrent les preuves VEX, préparent les projets de déclaration SRP et demandent l'approbation.
• Approbateurs — vérifient les preuves finalisées avant soumission à la plateforme SRP.
• Auditeurs — consultent les preuves en lecture seule, les journaux d'audit et l'historique des soumissions.
• Administrateurs organisation — gèrent les clés de service, les produits, les preuves SBOM et les paramètres de l'espace de travail.
• Super-administrateurs — intègrent de nouvelles organisations et supervisent l'état des locataires sur l'ensemble de la plateforme.

Cette séparation des rôles garantit que les personnes qui préparent les preuves sont distinctes de celles qui les approuvent, renforçant ainsi la responsabilité dans le cadre des déclarations réglementaires.

3. Espace de travail et gestion des organisations

Espace de travail

Chaque organisation dispose de son propre espace de travail contenant ses produits, SBOM, vulnérabilités, dossiers de révision, workflows de déclaration SRP, notifications et preuves d'audit. Le statut de conservation légale (legal hold) est visible sur les vues de l'organisation et de l'espace de travail, afin que les équipes sachent quand les preuves doivent être préservées au-delà des politiques de rétention habituelles.

Lors de l'intégration d'une nouvelle organisation, la plateforme peut provisionner automatiquement des comptes Zitadel pour les contacts conformité et sécurité, en leur attribuant les rôles appropriés sans configuration manuelle du fournisseur d'identité.

Profil de l'organisation

Le profil enregistre les données juridiques et réglementaires nécessaires aux déclarations : raison sociale, type d'entité, numéro d'enregistrement, pays, adresse, contacts conformité et sécurité, URL de la politique de divulgation des vulnérabilités, État membre d'établissement principal pour le routage Article 14(7) et politique de conservation des SBOM. Les informations de routage incomplètes sont signalées, car l'absence de l'État membre d'établissement peut bloquer la préparation à la soumission SRP.

Administration de la plateforme

Les super-administrateurs peuvent intégrer de nouvelles organisations via un parcours guidé, consulter le nombre de produits et l'état d'enregistrement de chaque locataire, modifier les profils d'organisation et naviguer directement de l'intégration à l'enregistrement du premier produit.

4. Tableau de bord et priorisation

Le tableau de bord offre une vue d'ensemble de la couverture du portefeuille produits, du volume de SBOM, des vulnérabilités ouvertes, des dossiers en attente, des échéances à venir et des lacunes de préparation. Il met en avant la prochaine action à entreprendre — qu'il s'agisse de traiter des dossiers en retard, de trier des vulnérabilités critiques, de finaliser l'intégration ou de charger des preuves SBOM.

La gestion des échéances est intégrée à chaque écran, pas reléguée dans un calendrier séparé. Les délais CRA — prévenance 24h, notification 72h, rapport final, rapports intermédiaires et demandes de diffusion différée — apparaissent directement dans les files d'attente, les cartes du tableau de bord et les pages de workflow. Les équipes voient ce qui est en retard, ce qui nécessite une action et ce qui approche, sans suivi manuel.

5. Registre des produits

Les produits sont le socle de toutes les preuves et déclarations. Les équipes enregistrent le nom, la catégorie CRA (standard, important ou critique), le contact sécurité, la période de support, le schéma de version, l'état du marquage CE et l'URL de la politique de divulgation des vulnérabilités. Seules les versions actives enregistrées peuvent recevoir des preuves SBOM ; les versions obsolètes ou en fin de vie restent visibles pour l'historique d'audit.

Les pages de détail produit regroupent les métadonnées, les versions, les documents de contexte, les ensembles de preuves SBOM, les déclarations SRP associées et l'historique d'audit.

6. Documents de contexte produit

Les équipes peuvent joindre des documents d'accompagnement — architecture de sécurité, modèles de menace, manuels utilisateur, notes de version, rapports de test — pour aider les relecteurs et l'analyse IA à mieux comprendre le produit. Les documents peuvent s'appliquer à toutes les versions ou à une version spécifique. Les fichiers originaux sont conservés dans le stockage objet et accessibles via des liens de téléchargement sécurisés à durée limitée.

7. Preuves SBOM et inventaire des composants

La bibliothèque SBOM accepte les fichiers CycloneDX (1.4 à 1.7) et SPDX (2.2, 2.3, 3.0.1) pour les versions de produits enregistrées. L'API valide les fichiers, calcule les empreintes, archive les preuves brutes dans un stockage compatible S3 et verrouille l'ensemble pour qu'il serve de preuve CRA auditable. Les doublons, les formats non conformes et les conflits de version sont détectés au moment du chargement.

La bibliothèque affiche l'état des preuves (verrouillé, analysé, brouillon, en cours, échec), les analyses de base et les deltas d'impact, le nombre de composants et les transferts vers la relecture humaine. Les pages d'inventaire relient chaque fichier SBOM aux packages et vulnérabilités correspondants, avec des empreintes de vérification pour la traçabilité d'audit.

API de scan sans état

CRA Direct expose également des endpoints sans état qui permettent aux outils externes et aux pipelines CI d'évaluer des SBOM sans persister de données :

• POST /scan-sbom — accepte un SBOM CycloneDX ou SPDX et retourne les vulnérabilités détectées sans créer de preuve.
• POST /scan-purls — accepte jusqu'à 500 PURLs et retourne les vulnérabilités correspondantes.
• POST /triage-stateless — accepte un contexte produit et des vulnérabilités, retourne une analyse CRA assistée par IA.

Ces endpoints sont conçus pour l'évaluation en amont de l'ingestion, le contrôle CI et l'intégration de scanners externes sans couplage avec le cycle de vie des preuves de la plateforme.

8. Renseignement sur les vulnérabilités

Plutôt que de dépendre d'un seul scanner tiers, CRA Direct collecte les données de vulnérabilité directement depuis des sources autorisées et effectue son propre appariement composant-vulnérabilité. Cette architecture indépendante des scanners évite de lier la chaîne de preuves de conformité au modèle de données ou au cycle de mise à jour d'un éditeur particulier.

Sources de renseignement disponibles :

• OSV — base de vulnérabilité principale, synchronisée en masse et consultable via API
• CISA Known Exploited Vulnerabilities — catalogue complet avec synchronisation différentielle
• FIRST EPSS — score de prédiction d'exploitation
• ENISA EUVD — correspondance CVE vers EUVD

La plateforme distingue les analyses de base (sur un ensemble SBOM verrouillé) des deltas d'impact (déclenchés lorsque de nouvelles informations modifient le profil de risque de composants connus). Chaque évolution du renseignement crée un événement d'impact en lecture seule pour la traçabilité d'audit.

9. Analyse CRA assistée par IA

Les analyses traitent les preuves SBOM verrouillées, les données de vulnérabilité et le contexte produit. Les résultats incluent une décision d'ensemble (candidat au signalement, à surveiller, examen VEX ou tri manuel), des verdicts par vulnérabilité avec justifications, des preuves d'exploitation active, des suggestions de preuves manquantes et des actions recommandées.

Les résultats de l'IA sont une aide à la décision, pas une décision finale. Les conclusions « pas de signalement » et « non affecté » nécessitent des preuves humaines et une décision validée par un relecteur. Le contenu généré par l'IA est vérifié par rapport aux preuves avant d'être présenté à un relecteur, et le système bascule sur un traitement déterministe en cas d'échec du modèle.

10. Preuves VEX et tri des vulnérabilités

Les relecteurs peuvent enregistrer des preuves VEX avec des justifications spécifiques au produit — non affecté, affecté, corrigé ou en cours d'investigation — accompagnées de déclarations d'impact, d'actions et de justifications au format CSAF. Le parcours de relecture peut générer des projets d'artefacts VEX pour approbation, et les décisions VEX finales sont verrouillées dans l'historique d'audit.

11. Bureau de relecture humaine

Le bureau de relecture organise les dossiers par type : soumissions SRP, tri VEX, rapports intermédiaires, demandes de diffusion différée et actions externes. Derrière cette interface se trouve une machine à états explicite qui fait évoluer les dossiers à travers des phases contrôlées — ouvert, en relecture, projet généré, soumis pour approbation, modifications demandées, rejeté, approuvé, soumis, clos ou archivé — selon le type de dossier.

Ce mécanisme garantit la séparation des responsabilités entre relecteurs et approbateurs, enregistre chaque transition comme preuve d'audit et maintient les résultats de l'IA au statut de projet tant qu'un humain n'a pas validé l'étape correspondante.

12. Workflows de soumission SRP

CRA Direct gère les déclarations Article 14 pour les vulnérabilités activement exploitées et les incidents graves. Les workflows de vulnérabilité peuvent démarrer depuis l'analyse (scanner/IA/VEX) ou depuis une saisie manuelle directe.

Workflow vulnérabilité

• Prévenance 24h — Article 14(2)(a)
• Notification 72h — Article 14(2)(b)
• Rapport final — Article 14(2)(c), soumis après disponibilité d'une mesure corrective (dans les 14 jours)
• Suivi des notifications fournisseurs et mainteneurs pour les composants tiers
• Saisie manuelle pour les vulnérabilités connues exploitées

Un moniteur de correction bloquée détecte lorsqu'une mesure corrective est disponible depuis 14 jours sans rapport final soumis et déclenche une alerte pour éviter que l'obligation n'expire silencieusement.

Workflow incident grave

• Prévenance 24h — Article 14(4)(a)
• Notification 72h — Article 14(4)(b)
• Rapport d'incident final — Article 14(4)(c), dans un délai d'un mois

Deux ensembles de critères de gravité sont pris en charge : SECURITY_IMPACT (exploitation active, perte de confidentialité/intégrité/disponibilité) et MALICIOUS_CODE (soupçon de code malveillant intentionnel, indicateurs de compromission de la chaîne d'approvisionnement).

Les pages de workflow affichent l'état de chaque étape (24h/72h/rapport final), l'État membre de déclaration, les identifiants de suivi SRP, le statut de notification des utilisateurs et fournisseurs, ainsi que des indicateurs d'attention manuelle pour les étapes en échec.

13. Saisie manuelle

Lorsqu'un fabricant sait déjà qu'une vulnérabilité est activement exploitée et dispose de preuves spécifiques, le parcours de saisie manuelle crée un workflow Article 14(2) sans attendre l'analyse SBOM en amont. L'utilisateur renseigne le produit et la version concernés, les identifiants de vulnérabilité, la date de prise de connaissance, la gravité, les preuves d'exploitation, les verdicts VEX et le périmètre géographique.

Un parcours similaire existe pour les incidents graves. Lors de la relecture d'un incident, l'assistance IA peut préremplir le contenu des déclarations à partir des éléments saisis, mais les relecteurs conservent la main sur la validation et l'approbation du document final.

14. Rapports intermédiaires et diffusion différée

Les rapports intermédiaires permettent de répondre aux demandes des coordinateurs CSIRT (Article 14(6)) sans modifier les obligations principales 24h/72h/rapport final. L'utilisateur enregistre une demande depuis la page de détail du workflow, ce qui ouvre un dossier de relecture dédié et soumet la mise à jour approuvée à l'API intermédiaire SRP.

Les demandes de diffusion différée capturent les motifs du retard, l'analyse de risque, la fenêtre de diffusion demandée et le plan de divulgation. Les données de délai sont incluses directement dans le document SRP.

15. Activité et notifications

Le fil d'activité donne aux équipes une vue chronologique des événements de l'espace de travail — fin d'analyse, transfert vers relecture humaine, échéances de revue, demandes d'approbation et résultats SRP — sans avoir à ouvrir chaque workflow.

Le centre de notifications délivre les alertes par e-mail, SMS, Slack et Teams. Les notifications sont persistées en base de données et traitées par un worker dédié, garantissant que les échecs sont visibles et relançables plutôt que perdus silencieusement. Les rappels d'échéance suivent une cadence progressive (24h, 4h, 1h, 15 minutes avant l'échéance, puis à l'échéance elle-même), avec déduplication par clé d'idempotence et compteurs plafonnés pour éviter les alertes en boucle.

16. Clés de service pour l'automatisation

Les équipes peuvent créer des clés d'API propres à chaque organisation pour les pipelines CI, les intégrations de scanners et l'automatisation des workflows. Les clés offrent une expiration configurable (30 jours, 90 jours, 1 an ou sans expiration), un suivi de la dernière utilisation et une révocation immédiate. Trois périmètres d'autorisation sont disponibles :

• sbom:ingest — chargement de preuves SBOM
• stateless:analyze — analyse et tri sans état
• workflow:create — création de workflows CRA et de rapports intermédiaires

17. Piste d'audit et intégrité des preuves

Chaque action significative — analyse IA, décision humaine, transition de workflow, notification et soumission SRP — est enregistrée. Les entrées d'audit sont chaînées par empreinte, ce qui permet de vérifier l'intégrité des preuves exportées. Les fichiers stockés sont délivrés via des URLs sécurisées à durée de vie limitée plutôt que d'exposer des identifiants de bucket. Les données sont isolées par organisation via des politiques de sécurité au niveau des lignes (Row-Level Security) de PostgreSQL sur l'ensemble des tables.

18. Choix techniques

CRA Direct est conçu comme une plateforme de preuves de conformité, pas seulement comme une interface de workflow. Principaux choix d'architecture :

• Ingestion pilotée par l'API — l'API assure la validation SBOM, l'archivage et le verrouillage des preuves ; le navigateur est une simple surface de chargement.
• Références immuables — chaque SBOM est verrouillé sur une version de produit ; les mises à jour ultérieures créent des analyses delta distinctes.
• Indépendance des scanners — les données de vulnérabilité proviennent d'OSV, KEV, EPSS et EUVD plutôt que d'un scanner embarqué ; les outils externes s'intègrent via des SBOM CycloneDX ou SPDX.
• Workers robustes — synchronisation des vulnérabilités, analyse, déclaration et notifications s'exécutent en arrière-plan avec relances et gestion des échecs.
• Isolation des locataires — les données de chaque organisation sont séparées par sécurité au niveau ligne PostgreSQL, clés de service dédiées et visibilité d'audit basée sur les rôles.
• IA avec garde-fous — le contenu généré est vérifié par rapport aux preuves avant d'atteindre les relecteurs ; les affirmations non étayées sont détectées automatiquement et le modèle défaillant est remplacé par un traitement déterministe.
• SSO via Zitadel — intégration Auth.js, mappage des rôles et provisionnement automatique optionnel lors de l'intégration.

19. Limites actuelles

• Les déclarations SRP (Article 14) constituent le workflow réglementaire principal.
• Le statut de notification aux utilisateurs finaux est suivi, mais la publication CSAF 2.0 n'est pas encore intégrée.
• Les scores CVSS, EPSS et la gravité sont des signaux de priorisation, pas des déclencheurs Article 14 en eux-mêmes.
• Les versions de produit doivent être enregistrées avant le chargement SBOM — les noms ad hoc ne sont pas acceptés pour les preuves verrouillées.
• Le rapport final de vulnérabilité commence lorsqu'une mesure corrective est disponible, pas automatiquement après la notification 72h.
• Les résultats de l'IA restent des projets ou des aides à la décision jusqu'à ce qu'un humain enregistre la décision métier finale.

20. Valeur métier

• Maîtrise des échéances — les délais Article 14 sont visibles sur l'ensemble des workflows 24h, 72h, rapport final, intermédiaire et diffusion différée, avec des rappels qui tiennent les bonnes personnes informées.
• Tri allégé — concentre l'attention sur les vulnérabilités exploitées et pertinentes pour le produit, tout en dirigeant le bruit des simples scores de gravité vers des pistes de surveillance.
• Preuves connectées — relie produits, versions, SBOM, décisions VEX, déclarations SRP et événements d'audit en un seul endroit.
• Responsabilité claire — sépare les responsabilités des relecteurs et des approbateurs et conserve chaque décision comme preuve d'audit.
• Visibilité du portefeuille — offre aux responsables sécurité et conformité une vue unique des risques, de l'état de préparation et du statut des déclarations.
• Conformité d'audit — les preuves peuvent être exportées et vérifiées indépendamment, sans avoir à reconstituer les événements depuis des emails ou des tableurs.