Homologuer en continu : le kit de preuves comme sortie de build

Cet article s’adresse aux officiers de sécurité des systèmes d’information et aux homologateurs. Il décrit comment OC2-Edge inverse la production du dossier d’homologation : les preuves ne se reconstituent pas après coup, elles sortent du build à chaque version. Il précise le contenu du kit d’instance, la trajectoire de certification visée, et le périmètre de sécurité assumé en v1.

Le renversement

Dans la pratique courante, l’homologation d’un système arrive en fin de projet. Une équipe reconstitue alors ce que le système contient, comment il a été construit, quels tests ont été passés, et assemble un dossier qui photographie un état déjà dépassé au moment de sa signature. Chaque version suivante rouvre l’écart : le dossier décrit le système d’hier, le terrain exécute celui d’aujourd’hui. L’homologateur arbitre alors entre bloquer les mises à jour, ce qui fige les vulnérabilités, et les accepter hors dossier, ce qui vide l’homologation de son contenu.

OC2-Edge renverse la charge. Les éléments de preuve sont des artefacts de build : chaque version produite par les 9 chaînes d’intégration continue du dépôt sort accompagnée de son kit de preuves, généré par les mêmes chaînes, dans le même déclenchement. Le dossier d’homologation ne se reconstruit jamais après coup : il se met à jour au rythme exact des versions, et la question de l’écart entre dossier et système déployé disparaît par construction. Le build reproductible bit à bit complète le dispositif : un homologateur peut reconstruire les binaires depuis les sources et constater l’identité binaire avec les artefacts livrés, ce qui transforme la confiance dans la chaîne de build en vérification.

Le renversement change aussi la nature de la décision sur les mises à jour. Entre deux versions, l’autorité dispose du différentiel exact des kits : composants ajoutés ou retirés, tests modifiés, lignes de la matrice touchées. Elle peut alors définir une politique graduée : les versions dont le différentiel ne touche aucune exigence de la cible suivent une voie de ré-examen allégée, les autres déclenchent un ré-examen complet. Cette gradation est impraticable quand le dossier se reconstitue à la main ; elle devient un tri sur des artefacts quand le dossier sort du build.

Le contenu du kit d’instance

Le kit de preuves d’une instance contient quatre éléments.

1. Le SBOM (Software Bill of Materials) : l’inventaire complet des composants logiciels de l’image, avec versions et provenances. C’est l’élément que les autorités, dont la CISA américaine, promeuvent comme fondation de la transparence logicielle, notamment pour l’analyse d’exposition aux vulnérabilités publiées [1]. Un CVE publié sur un composant se croise avec le SBOM de chaque version en service, sans investigation manuelle.
2. Le rapport de tests : le résultat daté de la suite complète, ~930 tests automatisés, sur les cibles d’émulation x86-64 et ARM64, avec l’identifiant exact de la version testée. Les échecs éventuels y figurent au même titre que les succès.
3. Le manifeste de provenance signé : l’attestation de la chaîne de build, décrivant quelles sources, quelles chaînes et quels paramètres ont produit quels artefacts. Le format suit l’approche du cadre SLSA, qui normalise l’attestation de provenance pour la chaîne d’approvisionnement logicielle [2].
4. La matrice exigence-mécanisme-preuve : pour chaque exigence de sécurité de la cible, la ligne désigne le mécanisme du socle qui la porte et la preuve qui l’atteste (test, mesure, document, procédure). Une exigence sans mécanisme ou sans preuve apparaît comme un trou dans la matrice : le format rend les manques visibles au lieu de les lisser.

Une ligne de la matrice se lit ainsi : exigence « le nœud rejette tout module dont la signature ne se vérifie pas », mécanisme « vérification ML-DSA-65 à l’installation, chaîne de confiance ancrée hors ligne », preuves « tests d’installation de modules à signature invalide, révoquée et absente dans la suite publique, section correspondante du modèle de menace ». L’homologateur ne reçoit pas une affirmation, il reçoit un chemin de vérification qu’il peut parcourir jusqu’au code du test.

Ce kit ne remplace pas la décision d’homologation, qui reste un acte de l’autorité sur un périmètre d’emploi donné. Il en fournit la matière première, à jour et vérifiable.

La trajectoire CSPN

La trajectoire de certification visée est la CSPN (Certification de Sécurité de Premier Niveau) de l’ANSSI : une évaluation en boîte noire, menée par un centre d’évaluation agréé, sous contrainte de temps, qui atteste la résistance d’un produit à un niveau d’attaquant donné [3]. Le périmètre d’évaluation, la cible de sécurité et les documents exigibles suivent le référentiel publié par l’agence [4]. Aucune échéance de dépôt n’est annoncée ici : le calendrier est un point ouvert, publié dans le dépôt quand il sera engagé.

Le caractère ouvert du socle sert directement cette évaluation. Une CSPN se mène sous forte contrainte de temps : chaque heure que l’évaluateur passe à comprendre le produit est retirée de la recherche d’attaques. Un évaluateur qui dispose des sources, du modèle de menace, de la suite de tests et des rapports de build entre dans le vif du sujet immédiatement, et la charge de compréhension pèse sur des documents publics vérifiés en amont plutôt que sur les journées d’évaluation.

Le choix d’architecture qui prépare cette trajectoire est la réduction de la TCB (Trusted Computing Base) : l’ensemble des composants dont la compromission suffit à compromettre la sécurité du système. Dans OC2-Edge, les modules métier s’exécutent isolés (namespaces, cgroups, seccomp, microVM, WASI) et hors TCB : la cible d’évaluation se concentre sur le socle, démarrage vérifié, vérification de signatures, isolation, mise à jour. Une TCB réduite donne un périmètre d’évaluation réduit, donc une évaluation dont le coût et la durée restent compatibles avec un rythme de versions soutenu.

Du modèle de menace à la cible de sécurité

La cible de sécurité ne se rédige pas à partir d’un catalogue générique : elle se dérive du modèle de menace, publié dans le dépôt, par une chaîne en trois outils.

1. EBIOS RM (EBIOS Risk Manager), la méthode d’appréciation du risque numérique de l’ANSSI, structure l’analyse : cadrage du périmètre, sources de risque, scénarios stratégiques puis opérationnels, traitement [5]. C’est elle qui relie les biens à protéger d’une instance aux scénarios redoutés.
2. STRIDE fournit la grille de classification des menaces par catégorie technique (usurpation, falsification, répudiation, divulgation, déni de service, élévation de privilège), appliquée à chaque interface du socle [6].
3. MITRE ATT&CK apporte la base de connaissance des techniques adverses observées, qui confronte le modèle aux pratiques documentées plutôt qu’à des attaquants théoriques [7].

La sortie de cette chaîne est précisément la première colonne de la matrice exigence-mécanisme-preuve : chaque exigence de la cible trace vers un scénario de menace identifié, et chaque scénario retenu trace vers au moins une exigence. L’homologateur peut parcourir la chaîne dans les deux sens.

Système-haut assumé, promesses MLS refusées

La v1 d’OC2-Edge assume un positionnement dit système-haut : une instance opère à un niveau de classification unique, et tous les utilisateurs de l’instance sont habilités à ce niveau. Le socle ne prétend pas être un système MLS (multi-level security), c’est-à-dire capable de faire cohabiter plusieurs niveaux de classification dans une même instance avec une séparation démontrée.

Ce choix est une application de la ligne éditoriale du projet : la précision contre les promesses. Une séparation MLS démontrée est un objet rare, coûteux, et dont la démonstration dépasse le cadre d’une CSPN. Prétendre au MLS sans cette démonstration ferait porter à l’homologateur un risque non documenté : la promesse figurerait dans le dossier, sans mécanisme ni preuve en face, exactement le type de ligne creuse que la matrice exigence-mécanisme-preuve est conçue pour rendre visible. Un positionnement système-haut, plus modeste, se démontre entièrement avec les mécanismes existants du socle, et donne à l’autorité un périmètre qu’elle peut réellement instruire. Le besoin multi-niveaux se traite en v1 par la séparation physique ou virtualisée d’instances, une par niveau, fédérées le cas échéant par les mécanismes de labels décrits dans La coalition dans le code. L’évolution de ce positionnement, si elle advient, passera par le même chemin que le reste : un modèle de menace révisé, des mécanismes publiés, des preuves dans le kit.

Le kit de preuves d’instance se demande via la page de contact, avec la version du socle concernée.

Sources

1. CISA, « Software Bill of Materials (SBOM) », https://www.cisa.gov/sbom
2. OpenSSF, « SLSA: Supply-chain Levels for Software Artifacts », https://slsa.dev/
3. ANSSI, « Présentation de la Certification de Sécurité de Premier Niveau (CSPN) », https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/certification-de-produits/presentation-certification-cspn/
4. ANSSI, « Documents applicables à la Certification de Sécurité de Premier Niveau (CSPN) », https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/certification-de-produits/referentiel-dexigences-pour-la-certification/documents-applicables-certification-de-securite-de-premier-niveau/
5. ANSSI, « La méthode EBIOS Risk Manager », https://cyber.gouv.fr/securisation/analyse-des-risques/methode-ebios-rm/
6. Microsoft, « Threats, STRIDE model (Threat Modeling Tool) », https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
7. MITRE, « MITRE ATT&CK », https://attack.mitre.org/