Vellacila conformité Cyber Resilience Act pour les fabricants de produits

Contexte

Le Cyber Resilience Act (règlement UE 2024/2847) s’applique à quiconque met sur le marché européen un produit comportant des éléments numériques — logiciel, firmware, objet connecté. Depuis le 11 septembre 2026, un fabricant doit signaler une vulnérabilité activement exploitée ou un incident grave à son CSIRT et à l’ENISA : alerte précoce sous 24 heures, notification sous 72 heures, rapport final ensuite.

Le règlement ne demande pas de la bonne volonté ; il demande des dates, des noms et des documents. Un fabricant qui ne peut pas produire le SBOM de la version livrée, la trace de la décision de signalement et la preuve de ce qui a été soumis n’est pas en conformité, quelle que soit la qualité de sa sécurité réelle.

Problème

La plupart des fabricants répondent aujourd’hui à ces questions depuis des tableurs et des horodatages de tickets. Cela échoue sur trois points précis, et chacun est fatal en audit.

• L’exposition est un projet, pas une requête : savoir quels produits embarquent une bibliothèque vulnérable demande de rouvrir des builds au lieu d’interroger un inventaire.
• L’horloge n’a pas de point de départ défendable : un horodatage de ticket n’est pas une prise de connaissance, et personne n’a signé la décision de signaler.
• La preuve est reconstituée après coup : sans révisions immuables ni journal d’audit, ce qui a été soumis ne se distingue plus de ce qui a été corrigé ensuite.

Le plus difficile

Le cœur du produit est une horloge qu’un régulateur acceptera. La tentation d’ingénierie est de démarrer le compte à rebours automatiquement dès qu’une vulnérabilité exploitée est détectée — c’est mesurable, c’est propre, et c’est faux : le règlement parle de la prise de connaissance du fabricant, pas de la date de publication d’un avis.

La décision produit a donc été d’imposer une confirmation humaine avant toute horloge. Vellaci peut signaler qu’une vulnérabilité est potentiellement signalable — par exemple parce qu’un composant que vous livrez est listé dans le catalogue CISA KEV — mais un relecteur nommé confirme ou écarte, avec sa motivation, et c’est cette décision qui démarre le compte à rebours.

Le reste en découle. L’échéance est persistée avec la version de règle qui l’a produite, son horodatage source et son fuseau ; les statuts et les alertes sont calculés par des tâches de fond, jamais seulement dans le navigateur, pour qu’une horloge continue de tourner quand personne n’a l’onglet ouvert. Et les déclencheurs du rapport final sont deux, pas un : pour une vulnérabilité exploitée, quatorze jours à partir du moment où une mesure corrective est disponible ; pour un incident, un mois calendaire après la notification à 72 heures.

Le produit comme système

1. Produit + SBOM→
2. Correspondance vulnérabilités→
3. Décision du relecteur→
4. Horloges Article 14→
5. Soumission + preuves

Décisions produit

Trois décisions structurent le produit plus que la stack.

• Classer par signal d’exploitation, pas par ordre alphabétique ni par CVSS seul : KEV et EPSS d’abord, parce qu’un score de 9,8 jamais exploité mobilise moins qu’un 7,5 activement exploité sur un composant que vous livrez.
• Montrer la carte des écarts avant de demander une adresse e-mail : seize questions, huit minutes, un résultat par bandes plutôt qu’un score — un fabricant qui découvre le CRA a besoin de comprendre son exposition avant d’entrer dans un tunnel commercial.
• Vendre le logiciel en libre-service et la mise en route comme un service : l’engagement Vellaci Readiness configure le périmètre, les produits, les SBOM, les workflows et la structure de preuve avec le client, parce que la première configuration est là où la conformité se gagne ou se perd.

Écrans

De l’entrée à l’exécution — chaque étape, sa couche, ce qui s’y passe.

Architecture

Le système est organisé autour d’un seul graphe : Organisation → Produit → Version → Release → SBOM → Composant → Vulnérabilité → Évaluation → Remédiation → Incident → Notification CRA → Preuve. Chaque écran est une vue sur ce graphe, et chaque enregistrement remonte à un produit réellement mis sur le marché européen.

L’ingestion est la fondation : un SBOM est validé, parsé vers un modèle de composants normalisé, puis lié à une version de produit — le fichier d’origine conservé avec son empreinte SHA-256, et les faits historiques jamais réécrits quand un SBOM plus récent arrive. La déduplication se fait par purl canonique au niveau de l’organisation tout en préservant les relations produit/version, ce qui transforme « quels produits embarquent cette bibliothèque ? » en une requête à une ligne.

Au-dessus, la veille est continue plutôt que ponctuelle : les composants sont confrontés à OSV et aux avis GitHub, enrichis de CISA KEV et d’EPSS, et re-vérifiés chaque jour. Un composant livré il y a six mois qui entre au catalogue KEV aujourd’hui remonte sur la page produit sans que personne ne relance un scan.

Modèle de domaine

Organisation → Produit → Version

Registre de premier rang : états de cycle de vie, raisonnement de classification, propriétaires, périodes de support, historique de version immuable.

Release → SBOM

Le document reste attaché à la version qu’il décrit ; le fichier d’origine est conservé avec son SHA-256 et les faits historiques ne sont jamais réécrits à l’arrivée d’un SBOM plus récent.

Composant

Catalogue dédupliqué par purl canonique, avec usage produit, relations de dépendance, licences et compteurs d’exposition.

Vulnérabilité → Évaluation → Remédiation

Triage avec raison obligatoire, propriétaire de la remédiation, état VEX, et la revue CRA qui pose la question de l’Article 14.

Incident

Enregistrements distincts pour l’exploitation, les appareils compromis, la compromission de l’infrastructure de mise à jour — chacun avec son horodatage de prise de connaissance confirmée.

Notification CRA

Le dossier : type, produit, propriétaire, échéances calculées côté serveur, formulaires par étapes, enregistrement de soumission.

Preuve

Fichier ou lien à empreinte, rattaché à un produit, une exigence, une vulnérabilité, un incident ou un dossier, avec date de revue et gel légal.

État actuel

En production, abonnements actifs via Stripe. Tarifs publiés (septembre 2026) : espace d’évaluation gratuit (1 produit, 3 sièges, 10 SBOM/mois), Readiness 490 €/mois, Growth 990 €/mois, Enterprise sous contrat, implémentation Vellaci Readiness dès 4 900 €. Les obligations de signalement de l’Article 14 sont en vigueur depuis le 11 septembre 2026.

Modèle économique et opérationnel

Un espace gratuit qui n’est pas une démo : un produit réel, trois sièges et le workflow de reporting complet, suffisant pour traverser un vrai cas. L’abonnement se déclenche quand le nombre de produits, de sièges ou de SBOM dépasse ce cadre — c’est-à-dire quand le fabricant met réellement son portefeuille sous CRA. À côté, un engagement d’implémentation à prix fixe : périmètre, produits, SBOM, workflows et structure de preuve configurés avec le client. Le logiciel se vend en libre-service ; la mise en route se vend comme un service, parce qu’un fabricant qui découvre le règlement n’achète pas un outil, il achète une sortie de l’incertitude.

Ce qui a été livré

• Ingestion SBOM (CycloneDX, SPDX) avec confrontation continue à OSV, aux avis GitHub, à CISA KEV et EPSS — l’exposition devient une requête, plus un projet
• Horloges Article 14 calculées côté serveur depuis une prise de connaissance confirmée, avec version de règle, horodatage source et fuseau conservés ; statuts et alertes en tâches de fond
• Confirmation humaine avant toute horloge : un relecteur nommé confirme ou écarte le caractère signalable avec sa motivation — l’échéance a un responsable et un point de départ défendable
• Révisions immuables — chaque enregistrement est une révision hashée, celle qui est soumise est gelée, les amendements y sont rattachés — plus un coffre de preuves à empreintes exportable à tout moment
• Vulnérabilités classées par signal d’exploitation (KEV + EPSS), pas par ordre alphabétique
• Une évaluation de maturité gratuite en 16 questions en haut du tunnel : la carte des écarts s’affiche avant qu’une adresse e-mail soit demandée

Acquisition

L’acquisition est bâtie sur les intentions d’un fabricant qui découvre le règlement : le périmètre (« mon produit est-il concerné ? »), les catégories de produits, les délais de l’Article 14, la différence entre incident et vulnérabilité, la documentation technique de l’Annexe VII, les routes d’évaluation de la conformité, la période de support. À cela s’ajoutent des outils gratuits — un calculateur d’échéance CRA, un générateur de security.txt — qui répondent à une question réelle sans compte.

Chaque page mène à la même porte : l’évaluation en seize questions. C’est le seul point de conversion du site, et il donne son résultat avant de demander quoi que ce soit.