Ce qui reste à construire

Cette page nomme ce que le produit vise et ne tient pas encore. Elle a deux sources : ce que le livre blanc sécurité V3 annonce lui-même comme en cours, et les axes que le livre blanc ne couvre pas et dont la spécification vit dans le dépôt. Ce que le livre blanc énonce comme un engagement ou une garantie n’y figure pas : ces points sont décrits dans les pages qui les reprennent, dont Chaîne d’approvisionnement et Posture de conformité.

La page ne donne ni date, ni engagement de livraison, ni détail qui aiderait à attaquer le produit.

Deux règles s’appliquent :

• 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 section du livre blanc ou à la spécification du dépôt qui le porte.

Ce que le livre blanc annonce comme en cours

Le raccordement LDAP et Kerberos. L’authentification passe par le fournisseur d’identité de l’organisation, en OpenID Connect, ou par des comptes locaux pour les environnements isolés. Le raccordement à un annuaire LDAP et à Kerberos est en cours (livre blanc sécurité V3, section 6.1).

L’évaluation de la cible de sécurité. La cible de sécurité est rédigée au format CSPN et remise sur demande. L’évaluation elle-même n’est pas engagée : elle le sera lorsque le périmètre sera figé (livre blanc sécurité V3, section 10.4).

L’outillage de scan chez un client isolé

Chaque version est livrée avec sa nomenclature (SBOM) et sa déclaration d’exploitabilité (VEX), que vous chargez dans vos propres outils de gestion des vulnérabilités (livre blanc sécurité V3, section 9.1). Le livre blanc ne prévoit pas que le produit embarque son propre scanner. Une spécification du dépôt va plus loin (specs/2026-07-29-air-gap-vuln-mgmt/) : elle part du constat qu’un inventaire figé au jour de la livraison ne dit rien d’un référentiel de vulnérabilités qui a bougé depuis.

Le cœur constructible de cette spécification existe dans le dépôt, sous security/vuln-mgmt/ et scripts/airgap/ :

• l’empaquetage d’un scanner appuyé sur les outils employés en intégration continue (OSV-Scanner, Trivy), avec leur base, pour fonctionner hors ligne ;
• la copie hors ligne de la base de vulnérabilités, avec un fichier de fraîcheur daté ;
• l’indicateur de fraîcheur, reporté dans le rapport de scan, qui signale une base périmée.

Ce qui n’existe pas :

• aucune version publiée n’embarque ce scanner ni sa base, et la cadence d’import de la base par support contrôlé ou par diode n’est pas outillée ;
• l’absence d’appel réseau pendant le scan se vérifie à la main, sans contrôle automatisé.

L’analyse statique du code propriétaire

Tout changement du code est revu avant fusion (livre blanc sécurité V3, section 9.1). 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).

Aucun résultat d’analyse statique n’est présenté tant que l’outillage n’existe pas.

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

Le canal de signalement est publié (SECURITY.md) : une adresse dédiée, ce qu’un rapport doit contenir et ne pas contenir, un délai d’accusé de réception, un délai d’évaluation, un délai de correctif ou d’explication, une clause de non-poursuite pour les chercheurs de bonne foi, le périmètre des composants couverts, et la marche à suivre pour un client sans accès à Internet. Une clé PGP est fournie sur demande.

Les délais de notification d’une vulnérabilité activement exploitée, et la répartition des responsabilités entre l’éditeur et l’hôte, sont fixés par le livre blanc sécurité V3 (sections 7.3 et 11.1).

Ce qui n’est pas écrit (specs/2026-07-29-air-gap-vuln-mgmt/spec.md, §6) :

• les rôles d’astreinte et la chaîne de triage interne ;
• le périmètre des versions supportées et la durée de support par version ;
• une clé PGP publiée.

Ces engagements sont de nature organisationnelle et contractuelle : ils se prennent avec des personnes nommées, pas avec du code.

Le catalogue de contrôles réglementaires

Le dossier de sécurité qui accompagne le produit tient en six pièces, décrites dans le livre blanc sécurité V3 (section 10.1). Le catalogue ci-dessous est un outil de plus, que le livre blanc ne prévoit pas.

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, 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 produisible. Une réponse à un questionnaire d’achat s’appuie sur les pièces du dossier de sécurité et sur les artefacts et contrôles décrits dans Chaîne d’approvisionnement, pris un par un.

Ce que cette page ne dit pas

• aucune vulnérabilité non corrigée et non publiée : le canal est SECURITY.md, pas la documentation ;
• aucun détail exploitable : ni fichier, ni symbole, ni reformulation d’une faiblesse précise. Un axe à construire est nommé ; la manière de l’exploiter ne l’est pas ;
• aucune date de livraison.

Ce que cette page dit 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.