OSCAL: Frameworks as Code

ISO 27001, NIS2, DORA, CRA, AI Act, BSI C5, PCI DSS — chaque référentiel paraît dans son propre format, sa propre langue et son propre schéma de numérotation. Les équipes lisent de longs PDF à la main, des tableurs mappent un référentiel sur l’autre cellule par cellule, et chaque nouvelle version fait repartir le travail de zéro. Les documents n’interopèrent pas — chaque correspondance repose sur de la colle humaine. Dans le même temps, les autorités de surveillance exigent elles-mêmes depuis longtemps des données structurées : le registre d’informations DORA sur les prestataires tiers de services TIC doit être soumis chaque année au format xBRL-CSV depuis 2025. La conformité en piles de documents ne passe plus à l’échelle — ni pour les entreprises, ni pour les auditeurs.

L’Open Security Controls Assessment Language est un standard du NIST ouvert et neutre vis-à-vis des fournisseurs, développé avec l’industrie et maintenu ouvertement sur GitHub. Il est né d’une douleur concrète : les paquets d’autorisation comme ceux de FedRAMP étaient de volumineuses piles de documents qu’aucune machine ne pouvait vérifier. Depuis la première version stable 1.0.0 du 7 juin 2021, le standard évolue en continu — la version actuelle est la 1.2.3 du 7 août 2026. Chaque modèle existe à parts égales en JSON, XML et YAML, convertible d’un format à l’autre, défini via le framework Metaschema du NIST, qui génère schémas, convertisseurs et documentation à partir d’une source unique. L’essentiel en une phrase : un framework devient des données au lieu d’un PDF — les mêmes mots, désormais adressables et interrogeables.

OSCAL organise la conformité en trois couches : la couche Control décrit ce que dit un framework (Catalog), quelles parties sont sélectionnées et adaptées (Profile) et — depuis la version 1.2.0 — comment les frameworks se positionnent les uns par rapport aux autres (Control Mapping). La couche Implementation décrit comment les systèmes mettent en œuvre les contrôles (Component Definition, System Security Plan). La couche Assessment décrit comment on évalue et ce qui a été constaté (Assessment Plan, Assessment Results, POA&M). L’exemple de référence public est FedRAMP : le catalogue SP 800-53 est taillé sur mesure via un profil de baseline, un SSP implémente la sélection, les évaluations la vérifient, le POA&M suit les écarts — chaque étape référence la précédente de manière lisible par machine. La même chaîne fonctionne pour n’importe quel framework dès qu’un catalogue existe sous forme de données.

Un catalogue OSCAL reflète la structure du document source : les groups représentent chapitres, domaines ou articles ; les controls sont les exigences adressables dotées d’un ID stable ; les parts portent le texte fidèle — statement, guidance, objectif d’évaluation — référençables individuellement ; les params transforment les champs « organization-defined » d’un framework en champs de données à renseigner ; les props fournissent libellés et ordre de tri ; et le back-matter peut contenir le document source lui-même, sécurisé par des empreintes cryptographiques. Le point décisif est l’identité stable : un contrôle comme « ac-1 » reste la même référence à travers les versions et les mappings — outils, profils et preuves pointent durablement vers le même objet plutôt que vers un numéro de page.

Cinq propriétés impossibles avec un PDF et triviales avec des données : comparable (diff) — qu’est-ce qui a exactement changé entre deux versions d’un framework ? Interrogeable — filtrer, compter, sélectionner et produire des rapports sur l’ensemble des contrôles. Mappable — mettre en relation des contrôles à travers les frameworks : implémenter une fois, satisfaire plusieurs exigences. Traçable — chaque élément peut pointer vers l’emplacement exact de la source dont il provient. Automatisable — les outils consomment les données directement, sans ressaisie ni dérive de copier-coller. Pour les équipes GRC, cela signifie : les changements de version deviennent des diffs au lieu de recommencements, les audits s’appuient sur des références vérifiables, et la conformité multi-référentiels devient une opération sur des données.

Le NIST publie SP 800-53 nativement en OSCAL — actuellement la release 5.2.0, avec les procédures d’évaluation de SP 800-53A et les quatre baselines. Le moteur d’adoption le plus puissant est FedRAMP : après les phases pilotes 20x (26 puis 14 soumissions lisibles par machine), la décision de mars 2026 impose à plus de 500 fournisseurs Rev5 existants des paquets d’autorisation lisibles par machine ou semi-structurés — avec une échéance finale au 1er novembre 2027 ; en parallèle, le programme 20x remplace la documentation narrative par 46 Key Security Indicators vérifiables de manière automatisée. À l’international, l’Australian Signals Directorate publie l’ISM avec ses profils Essential Eight en OSCAL, GovTech Singapour adopte le standard à l’échelle gouvernementale, CIS livre les Controls v8/v8.1 et la Cloud Security Alliance sa CCM v4.1 en format lisible par machine ; selon sa propre annonce, AWS fournit depuis le printemps 2026 ses rapports SOC 1 et SOC 2 en complément au format OSCAL. Depuis février 2025, l’OSCAL Foundation (comité de pilotage incluant notamment AWS et Cisco) fédère la communauté ; le projet d’outillage OSCAL Compass est en sandbox CNCF depuis juin 2024.

Depuis le 30 septembre 2025, le BSI met à disposition sa bibliothèque « Stand der Technik » sur GitHub — des référentiels lisibles par machine sur base OSCAL, sous licence libre CC-BY-SA 4.0 et organisés selon les couches OSCAL. Le successeur de l’IT-Grundschutz, Grundschutz++, paraît OSCAL-first : environ 1 000 exigences réparties en 20 pratiques (build pilote mi-2026), phase pilote jusqu’au 30 septembre 2026, présentation officielle au salon it-sa le 27 octobre 2026, et une certification ISO 27001 sur cette base est prévue à partir de 2027. Le C5:2026 — 168 critères répartis en 17 domaines thématiques, aligné structurellement sur l’EUCS — est lui aussi disponible pour la première fois en format lisible par machine. Au niveau de l’UE, les projets Horizon MEDINA et EMERALD (Certification-as-a-Service, jusqu’en octobre 2026) ainsi que la communauté EUROSCAL font progresser l’usage d’OSCAL pour la certification cloud automatisée ; au sein de l’ECSO, une European OSCAL Task Force s’est réunie pour la première fois en septembre 2025. Une limite honnête : pour ISO 27001, il n’existe pas de catalogue officiel librement distribuable en raison du copyright ISO — ISO et IEC travaillent, avec l’initiative SMART, à leurs propres normes lisibles par machine.

Avec la version 1.2.0 de décembre 2025, le modèle Control Mapping est devenu le huitième modèle OSCAL : les mapping-collections relient catalogues ou profils au niveau des contrôles, voire des statements — avec six types de relations ensemblistes (equal-to, equivalent-to, subset-of, superset-of, intersects-with, no-relationship), une justification obligatoire (syntactic, semantic ou functional selon NIST IR 8477) et des qualificateurs pour les couvertures partielles et les incompatibilités. Le tout est complété par le programme OLIR du NIST, avec des références officielles CSF 2.0 vers ISO/IEC 27001, CIS Controls et PCI DSS, ainsi que par des métaframeworks comme le Secure Controls Framework, qui revendique plus de 200 référentiels mappés. La conséquence pratique : quiconque doit satisfaire à la fois à NIS2, AI Act, ISO 27001, ISO 42001 et CRA consolide le tout, par mapping, dans un référentiel de contrôles interne — l’analyse d’écarts combinée devient une requête, et cinq projets de mise en œuvre n’en font plus qu’un. Un point reste essentiel : les mappings sont rarement 1:1 — c’est précisément pourquoi le modèle impose type de relation et justification au lieu d’assimiler des contrôles en silence.

Dans le modèle Assessment Results, les preuves deviennent elles-mêmes des données : les findings se relient via des observations à des références de preuves, et les fichiers de preuve résident comme ressources back-matter — sécurisés par des empreintes cryptographiques via lien, ou directement embarqués. C’est le socle des évaluations continues, jusqu’aux concepts de Continuous ATO que le département américain de la Défense a définis par mémorandum en 2022. Pour la chaîne d’approvisionnement, la Component Definition est la clé : un fournisseur de logiciels ou de cloud décrit une seule fois, en format lisible par machine, comment son produit soutient des contrôles — et les clients importent ce composant directement dans leur System Security Plan au lieu de répondre au questionnaire suivant. L’outillage gagne en maturité : compliance-trestle gère OSCAL comme du code dans des pipelines CI/CD, Compliance-to-Policy génère à partir de Component Definitions des politiques natives pour Kyverno ou Open Cluster Management et renormalise les résultats de contrôle en Assessment Results ; en complément, CycloneDX 1.6 relie, avec ses attestations, SBOM et preuve de conformité. Restons honnêtes : la complexité du standard est réelle — sa valeur naît lorsqu’une plateforme l’encapsule au lieu de la répercuter sur les utilisateurs.