Divulgation de vulnérabilités & mandat de scan

1.Objet

Cette page dit deux choses, dans les deux sens du trafic. D'abord comment nous signaler une vulnérabilité sur nos propres systèmes. Ensuite, et c'est la partie que la plupart des éditeurs passent sous silence, ce que nous exigeons réellement d'un client avant de laisser notre infrastructure émettre du trafic de test vers des systèmes tiers.

Éditeur : Sedona.AI, SAS au capital de 1 000 €, siège social 1 rue des Variétés, 66000 Perpignan, RCS Perpignan 992 946 285.

2.Signaler une vulnérabilité sur nos systèmes

Écrivez à vincent.coderch@sedona-ai.com, la seule adresse e-mail de Sedona.AI, celle de nos mentions légales.

Ce que nous nous engageons à faire : accuser réception sous 24 heures ouvrées, vous dire si le signalement est retenu et pourquoi, vous tenir informé jusqu'à la correction, et vous créditer nommément si vous le souhaitez. Nous n'exploitons aucun programme de prime rémunérée : ne comptez pas sur une récompense financière, nous préférons le dire avant que vous ne passiez du temps dessus.

Périmètre : sedona-ai.com, app.sedona-ai.com, cms.sedona-ai.com et l'infrastructure d'analyse que nous opérons. Hors périmètre : les services de nos sous-traitants (hébergeur, plateforme de paiement, routeur d'e-mails), à signaler directement chez eux.

Règles : pas de déni de service ni de test de charge, pas d'ingénierie sociale visant nos personnes ou nos prestataires, pas d'accès, de modification ni d'exfiltration de données appartenant à nos clients — la preuve de l'existence d'un accès suffit, l'usage de cet accès est de trop. Arrêtez-vous dès que vous atteignez de la donnée réelle et dites-le-nous.

Tant que ces règles sont respectées et que le signalement nous parvient d'abord, nous n'engagerons aucune action judiciaire à votre encontre. Nous vous demandons de ne pas publier avant correction, ou à défaut au terme d'un délai de 90 jours à compter de votre signalement.

3.Trafic de scan sortant : ce que nous exigeons réellement

Sedona Radar analyse la surface d'attaque externe de nos clients. Notre infrastructure émet donc du trafic de test vers des systèmes qui ne nous appartiennent pas. Voici, sans arrangement, l'état du contrôle au 2 septembre 2026.

3.1 Ce que le produit exige aujourd'hui

Un scan naît de deux manières, et les deux ne suivent pas le même chemin technique. Nous les décrivons séparément : c'est exactement là qu'un éditeur est tenté d'arrondir.

Commun aux deux chemins

• Un compte authentifié et nominatif : aucun scan ne peut être déclenché anonymement. La requête est refusée sans session valide, et la procédure serveur qui écrit le scan refuse à son tour une identité nulle.
• Un dernier point de passage avant toute émission de trafic, commun à tous les lancements et à toutes les relances : la cible est refusée si elle appartient à notre liste d'entités protégées (domaines gouvernementaux et souverains, opérateurs d'importance vitale, santé, banque), si elle résout vers une adresse interne ou vers notre propre infrastructure, ou si l'horodatage d'attestation attaché au scan est vide. Ce contrôle est fail-closed : s'il échoue lui-même, le scan est refusé, jamais laissé passer.

Scan lancé à la demande

• Une attestation d'autorisation est obligatoire, et elle est exigée côté serveur par la procédure de base de données qui crée le scan : sans elle, la création est rejetée. Le rôle applicatif dont dispose le navigateur ne peut pas créer directement une ligne dans la table des scans : le droit d'insertion ne lui est pas accordé. Une requête fabriquée qui contournerait le formulaire est donc rejetée elle aussi. Précision : ce rôle conserve des droits de lecture et de suppression sur ses propres scans, encadrés par les règles de sécurité au niveau des lignes ; et les scans récurrents que vous avez programmés sont créés par notre planificateur, sur la base de l'attestation donnée lors de la programmation, sans nouvelle demande à chaque exécution.
• Ce que cette attestation est exactement : une case cochée, transmise par le navigateur. Le serveur vérifie qu'elle est présente, l'horodate lui-même et l'enregistre sur la même ligne que la cible, dans la même transaction. Il ne vérifie rien d'autre.
• Le lien entre l'attestation et la cible : modifier la cible après avoir coché décoche la case, qui doit être redonnée. Ce contrôle-là vit dans le navigateur. Ce que le serveur garantit, c'est que l'attestation qu'il enregistre porte sur la cible qu'il enregistre au même instant — pas qu'elle a été donnée après le dernier changement de cible.

Scan planifié (monitoring récurrent)

• L'attestation n'est pas redemandée à chaque exécution. Chaque échéance est écrite directement dans la table des scans par notre orchestrateur, sans repasser par la procédure décrite ci-dessus, en reprenant la date de création de la planification et l'adresse IP qui y est enregistrée (cf. 3.2).
• La mise en place, elle, dépend de l'écran utilisé : créée depuis le formulaire de scan, la planification accompagne un scan qui a exigé l'attestation ; créée depuis l'écran de monitoring, l'interface de programmation appelée ne réclame pas de case à cocher — elle enregistre le compte, la cible, la fréquence et l'adresse IP du demandeur. Aucune attestation d'autorisation n'est exigée ni conservée à cette étape.

3.2 Ce que nous conservons comme preuve d'acceptation

Attachés au scan, et produits sur demande motivée du titulaire :

• l'identifiant du compte demandeur ;
• l'horodatage serveur de l'attestation — pas l'horloge du navigateur, qui n'est pas une preuve ;
• l'adresse IP depuis laquelle l'attestation a été émise ;
• la cible exacte sur laquelle elle porte.

Pour un scan planifié, ces quatre éléments existent aussi, mais ils datent de la mise en place de la planification, pas de l'exécution : l'horodatage est celui de la création de la planification, tandis que l'adresse IP est celle enregistrée lors de sa dernière mise en place ou modification — les deux ne coïncident donc pas nécessairement. Nous ne présenterons jamais cet horodatage comme celui d'une attestation donnée le jour du scan observé.

Une planification qui ne porterait aucune adresse ne produirait aucun scan : la table des scans refuse une ligne dépourvue d'adresse d'attestation, l'échéance est journalisée en erreur et aucun trafic n'est émis. Nous préférons le dire ainsi plutôt que de laisser croire qu'une valeur de remplacement viendrait combler le trou.

Ces éléments sont conservés aussi longtemps que le scan auquel ils se rattachent, et supprimés avec lui.

4.Vous êtes titulaire d'un système que nous avons scanné

Écrivez à vincent.coderch@sedona-ai.com en indiquant le domaine ou l'adresse IP visés et une fenêtre horaire. Nous accusons réception sous 24 heures ouvrées.

Nous procédons ensuite ainsi :

• nous identifions le compte à l'origine du trafic ;
• nous vous confirmons l'existence, la date et la cible de l'attestation correspondante — en précisant, s'il s'agit d'un scan planifié, que cette date est celle de la mise en place de la planification et non celle du scan que vous avez observé ;
• sur votre demande, nous arrêtons le scan en cours et nous désactivons toute planification récurrente pointant vers vos systèmes ;
• l'identité du demandeur vous est communiquée sur demande motivée, ou sur réquisition d'une autorité compétente.

Ces opérations sont aujourd'hui manuelles. Nous n'exploitons aucune liste d'exclusion alimentée par vos demandes : le seul refus permanent qui existe est la liste d'entités protégées évoquée au 3.1, embarquée dans le code de notre infrastructure d'analyse. Y ajouter une cible suppose une modification et un déploiement de notre part — ce n'est ni instantané, ni en libre-service, et nous ne le présenterons pas comme tel.

5.Vérification de propriété : ce que nous prévoyons d'exiger

Cette vérification n'est pas déployée à ce jour. Nous publions son cahier des charges pour que vous puissiez juger de ce qui manque, et pour nous engager sur une cible précise plutôt que sur une intention.

5.1 Principe

Aucun scan ne pourrait être lancé sur une cible dont la propriété n'a pas été démontrée par une preuve que seul le titulaire, ou l'administrateur technique qu'il a mandaté, est en mesure de produire. Elle devrait s'appliquer aux deux chemins décrits au 3.1 — création à la demande et exécution planifiée — ainsi qu'au dernier point de passage avant émission de trafic, faute de quoi elle ne vaudrait que pour le formulaire. Ces chemins ne partagent pas aujourd'hui de contrôle d'attestation commun : les y ramener fait partie du chantier.

5.2 Le jeton

Un jeton aléatoire d'au moins 128 bits, tiré par un générateur cryptographique, distinct par couple (compte, domaine), présenté sous la forme sedona-verify=<jeton>. Un jeton n'est jamais réutilisé d'un compte à l'autre : sans cela, un attaquant recopierait l'enregistrement d'un client légitime.

5.3 Méthode A — enregistrement DNS TXT (par défaut)

• Publication d'un TXT sur _sedona-challenge.<domaine> contenant la valeur du jeton.
• Résolution depuis nos propres résolveurs, avec validation DNSSEC quand la zone est signée, et interrogation directe des serveurs faisant autorité pour ne pas dépendre d'un cache empoisonné.
• Refus de la vérification si le domaine visé est un suffixe public (au sens de la Public Suffix List) : personne ne « possède » .fr ni .co.uk.
• Deux résolutions concordantes espacées d'au moins cinq minutes, pour ne pas valider un enregistrement transitoire.

5.4 Méthode B — fichier témoin HTTPS

Dépôt du jeton à l'adresse https://<domaine>/.well-known/sedona-verify.txt, servi en text/plain, en HTTPS avec certificat valide, sans suivre de redirection hors du domaine vérifié. Méthode réservée aux hôtes qui servent effectivement du web : elle prouve le contrôle du serveur, pas celui de la zone DNS, et vaut donc pour le seul nom d'hôte testé.

5.5 Méthode C — courriel de rôle

Envoi du jeton à une adresse de rôle du domaine (admin@, hostmaster@, webmaster@, postmaster@) ou au contact technique publié par le RDAP du registre. Méthode de repli, à réserver aux cas où le demandeur n'a la main ni sur la zone ni sur le serveur web.

5.6 Méthode D — adresses IP et blocs d'adresses

Une adresse IP n'a pas de zone DNS que le titulaire contrôle nécessairement. Pour une IP ou un bloc, la preuve exigée serait l'une des suivantes : un enregistrement TXT sur la zone in-addr.arpa correspondante quand le titulaire en a la délégation ; ou une lettre d'autorisation signée (LOA) désignant nommément le bloc, le signataire et sa qualité, recoupée avec le contact publié par le RDAP du registre régional. Une LOA reste une pièce déclarative : elle est vérifiée humainement, pas automatiquement.

5.7 Portée et héritage

• Vérifier un domaine apex ouvrirait ses sous-domaines : c'est le sens du Deep Scan, qui découvre les sous-domaines publics puis les analyse.
• L'inverse serait interdit : vérifier blog.exemple.fr n'autoriserait pas exemple.fr, et n'autoriserait aucun autre sous-domaine frère.
• Cas des hébergements mutualisés : un sous-domaine délégué à un tiers (plateforme SaaS, CDN) ne serait pas couvert par la vérification de l'apex si sa zone est déléguée ailleurs. Ce cas exigerait une vérification propre.

5.8 Durée de validité et révocation

• Une vérification expirerait au bout de 90 jours et serait recontrôlée avant tout nouveau scan : un domaine change de main, et l'autorisation d'hier ne vaut pas pour toujours.
• La disparition de l'enregistrement TXT ou du fichier témoin révoquerait la vérification et suspendrait les scans récurrents associés.
• Le titulaire pourrait demander la révocation immédiate par le canal du point 4, sans avoir à justifier d'un compte chez nous.
• Chaque vérification, chaque échec et chaque révocation seraient horodatés et conservés au même titre que l'attestation.

5.9 Ce que cette vérification ne résoudrait pas

Elle prouverait le contrôle technique d'une zone ou d'un serveur, pas la qualité juridique du signataire. Un prestataire ayant accès au DNS de son client passerait la vérification sans détenir de mandat. C'est pourquoi elle n'abolirait pas l'attestation d'autorisation : elle s'y ajouterait, la première fermant la porte de la technique, la seconde engageant la responsabilité de son auteur.

6.Contact

Vulnérabilité et trafic de scan : vincent.coderch@sedona-ai.com.