De la preuve signée à l’attestation vérifiable, dans une plateforme intégrée.

1. SENSEpercevoir

   Recueillir des signaux vérifiables et les laisser expirer.

   Composants impliqués

   • Agent d’endpoint
   • Analyse externe
   • SBOM
   • Questionnaires

   1. Un agent pour Windows, macOS et Linux exécute 172 contrôles et envoie des observations signées numériquement ; la console rejette celles qui ne se vérifient pas.

      Dans la démo · détail d’un poste

      Portée. C’est la télémétrie qui est signée, pas l’installeur. 143 contrôles sont des bases de référence ouvertes de niveau L1 qui n’alimentent pas encore le score de conformité.

   2. La preuve expire : un poste qui cesse de remonter des informations cesse de compter comme conforme, avec sept jours de fraîcheur par défaut.

      Docs · Conformité (s’ouvre dans un nouvel onglet)

      Portée. La preuve documentaire se téléverse ou se référence ; elle n’est pas collectée seule depuis le cloud.

   3. Pour chaque fournisseur : analyse externe des ports exposés, CVE et violations de données connues avec les données de Shodan et Have I Been Pwned, et son SBOM CycloneDX ou SPDX croisé avec OSV.dev.

      Docs · Moteur de risque (s’ouvre dans un nouvel onglet)

      Portée. Nouvelle analyse périodique selon la criticité du fournisseur, pas une surveillance continue. SBOM en JSON uniquement. Les données fournisseur sont orchestrées avec n8n ; il n’y a pas de scanner propre.

2. PREDICTprédire

   Transformer la preuve en risque comparable.

   Composants impliqués

   • Moteur de risque
   • FAIR/ALE
   • Simulateur
   • Graphe de dépendances

   1. Exposition FAIR/ALE en euros par fournisseur et pour le portefeuille : une estimation ponctuelle paramétrique avec sa fourchette d’incertitude simulée (non calibrée), reproductible.

      Docs · Moteur de risque (s’ouvre dans un nouvel onglet)

      Portée. Utilise des paramètres sectoriels du modèle, pas des données de pertes de votre organisation.

   2. Un simulateur déterministe à 7 types de scénario propage l’impact sur votre graphe de dépendances, jusqu’à 5 niveaux, et renvoie les fournisseurs touchés, les variations de score et les chemins.

      Docs · Simulateur (s’ouvre dans un nouvel onglet)

      Portée. Renvoie des variations de score, pas des euros. Aucun modèle de langage n’intervient.

   3. Rayon d’impact à 3 sauts et indice de concentration HHI sur vos dépendances déclarées ; les CVE activement exploitées (catalogue KEV de la CISA) pèsent davantage dans le score de 0 à 100.

      Dans la démo

      Portée. Travaille sur les dépendances que vous déclarez ; ce n’est pas une cartographie automatique des n-ièmes parties. Les pondérations sont des constantes du modèle.

3. ACTagir

   Proposer une action et ne l’exécuter qu’avec une approbation humaine.

   Composants impliqués

   • HodeiAI
   • Registre des risques
   • Acheminement des alertes

   1. HodeiAI propose. Exécuter exige l’approbation explicite d’un utilisateur disposant d’un rôle d’écriture : à usage unique, valable 15 minutes et liée au hash de la proposition exacte.

      Dans la démo

      Portée. Aujourd’hui, la seule action exécutable est la création d’une entrée dans le registre des risques.

   2. Le niveau par défaut est « suggérer » et l’approbation pour exécuter est activée par un administrateur. L’exécution autonome est bloquée dans la base de données, l’API et l’exécuteur, et un kill switch par organisation arrête l’agent et échoue en mode fermé.

      Dans la démo

      Portée. ACT ne déploie pas de correctifs, n’isole pas de postes, ne révoque pas d’accès et ne contacte pas de fournisseurs.

   3. Chaque proposition, approbation, refus et exécution est consigné, avec son auteur, dans un journal d’actions en ajout seul, chaîné par hash et signé par lots avec ML-DSA-65, vérifiable avec la clé publique.

      Dans la démo

      Portée. Prouve ce qui a été proposé, qui l’a décidé et dans quel ordre ; pas que la décision était la bonne.

   4. Les alertes sont acheminées vers 9 destinations : ServiceNow, Jira, Slack, Teams, e-mail, webhook signé, SIEM, PagerDuty et Opsgenie.

      Docs · Connecteurs (s’ouvre dans un nouvel onglet)

      Portée. Elles notifient ou créent un ticket selon votre règle ; elles ne remédient pas d’elles-mêmes.

4. ATTESTattester

   Démontrer l’état à un tiers, sans qu’il ait à nous croire sur parole.

   Composants impliqués

   • Trust Center
   • Vérificateur ouvert
   • Clé publique

   1. Chaque Trust Center publié émet des attestations signées avec ML-DSA-65 (FIPS 204), la signature étant séparée du document attesté. Elles attestent le niveau de maturité de chaque référentiel et le plus faible : jamais de scores, d’euros ni de détail sur les fournisseurs.

      Docs · Vérificateur d’attestations (s’ouvre dans un nouvel onglet)

      Portée. C’est une autoévaluation signée par HodeiShield : elle prouve l’intégrité, l’origine et le moment, pas la véracité de ce qui est attesté. Elle ne remplace pas un audit.

   2. Chacun la vérifie hors ligne avec le vérificateur en code ouvert (Apache-2.0) et les clés publiques de /api/public/attest/keys, avec OpenSSL 3.5 ou supérieur.

      GitHub · hodeishield-attest-verifier (s’ouvre dans un nouvel onglet)

      Portée. Durée de vie courte : 15 minutes par défaut et une heure au maximum, avec défi-réponse optionnel.

   3. Une liste d’état signée et publiée permet de révoquer une clé ou toutes les attestations antérieures d’une organisation.

      Docs · Vérificateur d’attestations (s’ouvre dans un nouvel onglet)

      Portée. Elle ne révoque pas des attestations isolées ; leur courte durée de vie le compense.

Le cycle ne se referme pas seul : chaque tour passe par une personne.