Ce qui reste à construire

Un fournisseur qui ne présente que ses forces oblige l’acheteur à chercher ses faiblesses. Cette page les nomme d’emblée. Elle décrit des axes à construire, avec leur spécification quand elle existe — pas des dates, pas d’engagement de livraison, et aucun détail qui aiderait à attaquer le produit.

Deux règles s’appliquent à cette page comme aux autres :

• Aucun avis juridique. Le fait qu’un axe soit à construire est un constat d’ingénierie, pas une appréciation de conformité.
• Aucune affirmation sans traçabilité. Chaque point renvoie à la spécification du dépôt qui le porte.

La gestion des vulnérabilités en environnement isolé

C’est l’axe le plus important pour la cible visée, et il est entièrement à construire. La spécification existe, complète (specs/2026-07-29-air-gap-vuln-mgmt/) ; aucune de ses phases n’est engagée — le plan ne porte aucune tâche achevée.

Le raisonnement qui la fonde tient en une phrase : une nomenclature logicielle seule est nécessaire mais insuffisante. Un inventaire figé au jour de la livraison ne dit rien d’un référentiel de vulnérabilités qui a bougé depuis. Un client isolé qui ne reçoit qu’une nomenclature reste aveugle.

Ce que la spécification prévoit, et qui n’existe pas aujourd’hui :

• un scanner packagé pour fonctionner hors ligne, appuyé sur les outils déjà employés en intégration continue plutôt que sur un produit tiers — pour n’ajouter au client ni licence, ni compte, ni fournisseur à faire auditer ;
• une base de vulnérabilités transférable par support contrôlé ou par diode, avec une cadence d’import définie ;
• un indicateur de fraîcheur de cette base, lisible sans réseau et reporté dans tout rapport de scan. Une base périmée produit un « rien à signaler » trompeur : c’est ce qui distingue un scanner hors ligne honnête d’un scanner hors ligne rassurant ;
• une veille continue sur les nomenclatures des versions déjà livrées et encore supportées, distincte de la veille sur la version en cours de développement ;
• des bulletins de sécurité au format CSAF VEX, poussés hors bande, lisibles à la fois par un outil et par un humain.

La répartition des responsabilités, elle, est arrêtée et publiable (specs/2026-07-29-air-gap-vuln-mgmt/spec.md, §3) : le fabricant, connecté, surveille les nomenclatures des versions livrées, signale dans les fenêtres réglementaires et produit le correctif même lorsque l’amont ne corrige pas ; le client, isolé, vérifie l’intégrité de ce qu’il reçoit, applique et journalise. L’isolement du client ne suspend jamais l’horloge réglementaire. Cette répartition est une décision ; l’outillage qui doit la servir n’est pas écrit.

L’intégrité des artefacts livrés

Aucun artefact n’est aujourd’hui signé par une clé de l’éditeur. Le contrôle d’intégrité disponible porte sur la chaîne de construction (dépendances verrouillées, outillage épinglé et vérifié par empreinte, cf. chaîne d’approvisionnement), pas sur une signature apposée par l’éditeur au livrable lui-même.

Deux questions restent ouvertes dans le corpus et conditionnent la suite : une clé souveraine détenue par l’éditeur pour toutes les familles d’artefacts, ou l’acceptation d’une signature de plateforme selon le mode de distribution ; et le mécanisme de signature vérifiable sans réseau, contrainte propre aux environnements isolés qui écarte les schémas reposant sur une autorité en ligne.

Ces exigences ne sont pas seulement techniques : la preuve d’intégrité relève des obligations de fabricant au titre du CRA, avec l’échéance rappelée dans la posture de conformité.

L’analyse statique du code propriétaire

Les contrôles automatisés décrits sur ce site couvrent les dépendances, les secrets et les images de conteneurs. Ils ne couvrent pas le code écrit par l’éditeur : aucune analyse statique de sécurité n’est en place sur le code propriétaire (identifiant SEC-10.5-01, sans réserve).

C’est une couverture manquante, dite comme telle. Aucun résultat d’analyse statique ne sera présenté tant que l’outillage n’existe pas.

Le processus de réponse aux vulnérabilités

Le canal de signalement existe et il est publié (SECURITY.md). Le processus qui doit le servir n’est pas nommé (specs/2026-07-29-air-gap-vuln-mgmt/spec.md, §6) :

• aucun rôle d’astreinte désigné, aucune chaîne de triage écrite ;
• aucun délai d’accusé de réception, aucun périmètre de versions supportées, aucun calendrier de divulgation coordonnée, aucune clause de non-poursuite pour les chercheurs, aucune clé de chiffrement publiée pour le canal (identifiant SEC-9.7-04, partiellement tenu) ;
• aucun délai de mise à disposition des correctifs différencié par criticité, aucune clause de support de durée déterminée, aucune matrice de responsabilité partagée écrite.

Ces engagements sont de nature organisationnelle et contractuelle : ils se prennent avec des personnes nommées, pas avec du code. Publier un processus de réponse sans chaîne d’astreinte réelle serait un engagement intenable, et c’est la raison pour laquelle il n’est pas publié.

Le catalogue de contrôles réglementaires

La méthode est arrêtée (specs/2026-07-29-conformite/spec.md, §3) : un catalogue unifié où chaque contrôle porte son niveau de vérifiabilité, sa correspondance vers un ou plusieurs règlements et articles, et son héritage depuis les identifiants techniques SEC-*. Les vues par règlement en sont projetées, jamais tenues à la main — c’est ce qui interdit à un même fait d’avoir plusieurs statuts.

Ce catalogue n’existe qu’en spécification. Aucune vue « couverture CRA » ou « couverture RGPD » n’est donc produisible à ce jour. Une réponse à questionnaire d’achat s’appuie aujourd’hui sur les artefacts et contrôles décrits dans chaîne d’approvisionnement, pris un par un.

De la même façon, le dossier fournisseur — attestations, politique de vulnérabilités, nomenclature, historique des versions, clauses d’audit acceptées — est spécifié comme livrable et n’est pas constitué.

Ce que cette page ne dira pas

Par principe, et non par prudence commerciale :

• aucune vulnérabilité non corrigée et non publiée. Le canal est SECURITY.md, pas la documentation ;
• aucun détail exploitable : pas de fichier, pas de symbole, pas de reformulation d’une faiblesse précise. Un axe à construire est nommé ; la manière de l’exploiter ne l’est jamais ;
• aucune date de livraison. Une échéance annoncée puis manquée coûte plus cher qu’une absence assumée.

Ce que cette page dit, en revanche, est vérifiable : les spécifications citées vivent dans le dépôt, datées, avec leurs décisions et leurs options écartées. Un audit contractuel peut y accéder.