VENTEX / SECURITY CONTROL ROOM / PUBLIC REGISTER

La sécurité, un système que l’on peut vérifier.

Une surface de contrôle publique sur la base de preuves existante. Chaque affirmation indique son état, sa base technique, ses preuves et sa limite à partir de la même source datée.

Ouvrir le registre Evidence Center

ÉTAT PUBLIC DES CONTRÔLESRelu sur le plan éditorial au regard du dépôt, des tests et de la documentation d’exploitation · 9 septembre 2026

Affirmations: 23
Domaines: 6
Prouvé en interne: 9
Limité / prévu: 4

01Affirmation

02Base technique

03Preuves

04Limite

Rechercher des affirmations

Domaine

État

23 / 23

affirmations filtrées issues de la base de preuves publiée

PRD-01Mis en œuvreGRD-01

Connect réunit chats directs, groupes et Mission Rooms dans une seule interface.

Base de preuves: Routes, contrats et tests automatisés de composants/API pour les conversations et les messages.
Limite délibérée: Les Mission Rooms comprennent chat, membres, rôles opérationnels, états de cycle de vie, épingles et un journal de mission chiffré ; les capteurs, caméras, tâches et résumés par IA ne sont pas actifs.

PRD-02Prouvé en interneGRD-01

Application web, API, temps réel et fichiers sont des surfaces produit séparées.

Base de preuves: Application web Next.js, API Fastify, Socket.IO, PostgreSQL/Prisma et stockage privé compatible S3.
Limite délibérée: Un monolithe modulaire n’est pas automatiquement une plateforme multi-région à haute disponibilité.

PRD-03LimitéGRD-01

L’état actuel du produit est une mise en production contrôlée.

Base de preuves: La documentation produit, sécurité, état et livraison utilise le même statut de mise en production contrôlée.
Limite délibérée: Ni disponibilité générale, ni certification, ni homologation pour un usage hautement réglementé.

PRD-04Mis en œuvreGRD-01

Appels, messages vocaux, transfert, messages éphémères et transfert d’historique contrôlé sont des chemins produit mis en œuvre.

Base de preuves: Mise en œuvre WebRTC/partage d’écran, composition MediaRecorder, boîte de dialogue de transfert, logique d’expiration et transfert d’historique entre appareils, avec tests négatifs automatisés.
Limite délibérée: Le comportement en arrière-plan, le push et le partage d’écran dépendent du navigateur et du système d’exploitation ; le transfert d’historique n’est pas une archive en clair côté serveur.

IAM-01Mis en œuvreGRD-02

Les mots de passe utilisent Argon2id et les jetons d’accès restent de courte durée.

Base de preuves: Service d’authentification, limites de configuration et tests négatifs des routes.
Limite délibérée: Un stockage sûr des mots de passe n’empêche ni l’hameçonnage ni la compromission des points d’extrémité.

IAM-02Prouvé en interneGRD-02

Les jetons de renouvellement tournent et leur réutilisation révoque la famille de jetons concernée.

Base de preuves: Logique de session et tests automatisés de réutilisation/révocation.
Limite délibérée: Un point d’extrémité déjà compromis et déverrouillé reste un risque distinct.

IAM-03Mis en œuvreGRD-02

Appareils, sessions, historique de connexion et passkeys sont des objets de sécurité gérables.

Base de preuves: Routes WebAuthn, points d’accès appareils/sessions et interfaces de gestion.
Limite délibérée: Pas de modèle de séparation par organisation, ni SSO, ni provisionnement SCIM.

IAM-04Prouvé en interneGRD-02

La vérification de l’e-mail, la récupération du mot de passe, la suppression du compte, le mode panique, l’accès par mot de passe de contrainte et la révocation d’appareils utilisent des flux confirmés distincts.

Base de preuves: Routes d’authentification, interfaces de sécurité et tests négatifs pour la vérification, la réinitialisation, la suppression, la panique, l’authentification sous contrainte, le retrait du push et le nettoyage local du navigateur.
Limite délibérée: La révocation côté serveur ne peut pas effacer physiquement un point d’extrémité qui reste hors ligne ou compromis. Le nettoyage local s’exécute lors du prochain chemin de connexion éligible, peut être bloqué par un état ouvert du navigateur et signale explicitement cette situation.

CRY-01Mis en œuvreGRD-03

Le contenu des messages, fichiers et réactions dispose de charges utiles protégées côté client.

Base de preuves: Bibliothèques de chiffrement, contrats d’API et tests de cryptographie et multi-appareils.
Limite délibérée: Le service en fonctionnement a toujours besoin d’informations d’acheminement, d’appartenance et d’horaires ; une exploitation sans métadonnées n’est pas revendiquée.

CRY-02Prouvé en interneGRD-03

Le Double Ratchet est le chemin d’envoi par défaut, sans liste d’autorisation de conversations ; les enveloppes par appareil, les époques et une garde contre le retour arrière soutiennent la rotation et le fonctionnement multi-appareils.

Base de preuves: Preuves de rotation, d’appareils, de double ratchet et d’appartenance dans la pile de tests.
Limite délibérée: Des preuves internes ne sont pas un audit indépendant du protocole et de sa mise en œuvre.

CRY-04Prouvé en interneGRD-03

Pour les appareils compatibles, le chemin de la version 3 utilise un établissement de session PQXDH hybride combinant X25519 et ML-KEM-1024 ; le secret dérivé devient la clé racine du Double Ratchet.

Base de preuves: Tests automatisés de cryptographie et du service de clés, 308 contre-tests associés, 19 exécutions dans de vrais navigateurs avec 189 vérifications, scénarios multi-appareils et de retour arrière, attribution des prékeys à usage unique et parcours contrôlé en production le 6 septembre 2026 ; réexécution le 9 septembre 2026.
Limite délibérée: Le composant post-quantique protège l’établissement de session, pas un ratchet continuellement post-quantique. Le déploiement reste dépendant de l’appareil et n’a pas encore fait l’objet d’un audit externe indépendant.

CRY-05LimitéGRD-03

Les images de profil exigent une authentification et sont protégées au repos, mais elles ne sont pas chiffrées de bout en bout.

Base de preuves: Route de récupération protégée, récupération authentifiée des octets dans le client et vérification actuelle des affirmations en production.
Limite délibérée: Le service peut lire les images de profil. Leur récupération exige une authentification, mais pas de relation de communication existante lorsqu’un identifiant de compte exact est résolu.

META-03Prouvé en interneGRD-03

Les identifiants directs ont été supprimés de plusieurs chemins de communication stockés ou remplacés par des références opaques propres à la conversation.

Base de preuves: Pas de senderId dans les lignes de messages, un auteur signé dans le texte chiffré, des valeurs HMAC pour les chats directs, des marques de destinataire au lieu d’identifiants d’appareil dans les enveloppes de clés, memberRef pour les réactions, favoris et mentions, et un nouvel état de lecture sans nouvelles lignes d’accusé de réception. Dans l’état actuel du code et des tests, le chemin de démarrage à froid reconstruit l’annuaire des identifiants à partir de l’état de compte chiffré et ne considère pas un ensemble de preuves vide comme un succès. Les transferts d’historique y utilisent une seule marque de destination opaque calculée et ignorent les anciennes enveloppes non marquées au lieu de deviner leur destination.
Limite délibérée: Le service en fonctionnement a toujours besoin de métadonnées limitées sur les comptes, les relations et la technique pour l’autorisation et la distribution. L’environnement d’exécution signé en ligne n’a pas été mis à jour par cette tâche sur le site ; les nouvelles corrections du démarrage à froid et du transfert d’historique n’y s’appliqueront qu’après une livraison séparée de l’application et une migration. Les références historiques d’horaires/d’appareils et les registres de sécurité conservés restent visibles jusqu’à l’exécution de leur chemin de renouvellement ou de nettoyage défini. Minimiser les métadonnées ne signifie pas qu’elles sont absentes.

FIL-03Mis en œuvreGRD-03

Les envois sont liés à un utilisateur et à une conversation et n’utilisent pas de buckets publics.

Base de preuves: Autorisations d’envoi, validation de la taille/du type MIME/de la somme de contrôle et URL de téléchargement de courte durée.
Limite délibérée: L’analyse antivirus, la DLP et le transcodage vidéo côté serveur ne sont pas actifs.

PWA-01Mis en œuvreGRD-04

L’application web comprend un manifeste, un service worker, des icônes d’application et un affichage autonome.

Base de preuves: Ressources PWA publiques, interface d’installation et tests du service worker.
Limite délibérée: L’installation sur iOS passe par Safari plutôt que par l’App Store.

PWA-02Prouvé en interneGRD-04

Le service worker met en cache les ressources publiques de l’application, mais pas les réponses de l’API ni les messages.

Base de preuves: Liste d’autorisation de cache explicite et vérifications hors ligne et de mise à jour.
Limite délibérée: Le mode hors ligne n’expose pas un historique opérationnel arbitrairement ancien ; les messages non envoyés utilisent une boîte d’envoi locale.

PWA-03LimitéGRD-04

Le Web Push est lié à l’appareil, peut fonctionner sans texte en clair des messages et est supprimé lors de la révocation de l’appareil.

Base de preuves: Configuration VAPID, points d’accès d’abonnement, une valeur par défaut sans aperçu des messages, et tests négatifs de révocation et de push d’appels entrants.
Limite délibérée: Le push sur iOS exige une application installée sur l’écran d’accueil et une autorisation explicite ; la distribution reste sous le contrôle du système.

MSN-01Mis en œuvreGRD-05

Les Mission Rooms sont modélisées comme un type de conversation dédié.

Base de preuves: Contrats partagés, modèle de données, routes d’API et interface utilisateur.
Limite délibérée: Un type dédié n’est pas encore un processus complet de commandement et de contrôle.

MSN-02Mis en œuvreGRD-05

Créer, ouvrir, ajouter des membres, communiquer, gérer fichiers et épingles et piloter le cycle de vie de la salle sont disponibles.

Base de preuves: Flux de conversation/d’appartenance, matrice d’autorisations, routes du cycle de vie, chemins des fichiers, épingles et journal de mission chiffré.
Limite délibérée: Les tâches, les événements en direct, les flux de caméras/capteurs et les résumés par IA ne sont pas actifs.

MSN-03Prouvé en interneGRD-05

La démo publique présente l’approche sans prétendre être un système d’incident en production.

Base de preuves: Simulateur local sans connexion, avec des vues distinctes pour la chronologie, les tâches et les preuves.
Limite délibérée: Les données de démonstration sont illustratives et n’accèdent pas à la production de Connect.

OPS-01Mis en œuvreGRD-06

La pile comprend des composants conteneurisés pour le web, l’API, la base de données, Redis et le stockage.

Base de preuves: Compose de production, images multi-étapes, points de santé et tâche de migration.
Limite délibérée: Un seul hôte n’est ni une haute disponibilité ni une exploitation multi-région.

OPS-02Prouvé en interneGRD-06

Les livraisons peuvent être conditionnées par les types, les tests, le build, la migration, des tests de fumée et des preuves de livraison signées.

Base de preuves: Script de livraison, vérification des affirmations, correspondance schéma-migration, parcours dans le navigateur et répétition côté serveur des migrations en attente dans une copie jetable des données en fonctionnement.
Limite délibérée: Un contrôle de livraison interne n’est ni un test d’intrusion ni une certification d’exploitation. La répétition de migration ne modifie pas les données en fonctionnement ; un véritable exercice de reprise à partir de la sauvegarde chiffrée reste une preuve opérationnelle distincte.

OPS-03PrévuGRD-06

Le sur-site est préparé sur le plan de l’architecture, mais ce n’est pas un package clés en main général.

Base de preuves: Les limites des conteneurs et des modules permettent des environnements cibles isolés.
Limite délibérée: Réseau, secrets, sauvegardes, supervision, reprise, correctifs et recette doivent être définis pour chaque environnement.