OSCAL: Frameworks as Code

ISO 27001, NIS2, DORA, CRA, AI Act, BSI C5, PCI DSS — jedes Rahmenwerk erscheint in eigenem Format, eigener Sprache und eigenem Nummernschema. Teams lesen lange PDFs von Hand, Tabellen mappen Framework auf Framework Zelle für Zelle, und mit jeder neuen Version beginnt die Arbeit von vorn. Die Dokumente interoperieren nicht — jede Zuordnung ist menschlicher Klebstoff. Gleichzeitig verlangen Aufsichten selbst längst strukturierte Daten: Das DORA-Informationsregister über IKT-Drittdienstleister muss seit 2025 jährlich im xBRL-CSV-Format eingereicht werden. Compliance als Dokumentenstapel skaliert nicht mehr — weder für Unternehmen noch für Prüfer.

Die Open Security Controls Assessment Language ist ein offener, herstellerneutraler NIST-Standard, entwickelt mit der Industrie und offen auf GitHub gepflegt. Entstanden ist sie aus einem konkreten Schmerz: Autorisierungspakete wie bei FedRAMP waren umfangreiche Dokumentstapel, die keine Maschine prüfen konnte. Seit dem ersten stabilen Release 1.0.0 am 7. Juni 2021 wird der Standard kontinuierlich weiterentwickelt — aktuell ist Version 1.2.3 vom 7. August 2026. Jedes Modell existiert gleichwertig in JSON, XML und YAML, ineinander konvertierbar, definiert über NISTs Metaschema-Framework, das Schemas, Konverter und Dokumentation aus einer Quelle generiert. Der Kern in einem Satz: Ein Framework wird Daten statt PDF — dieselben Worte, jetzt adressierbar und abfragbar.

OSCAL organisiert Compliance in drei Schichten: Der Control Layer beschreibt, was ein Framework sagt (Catalog), welche Teile ausgewählt und angepasst werden (Profile) und — seit Version 1.2.0 — wie Frameworks zueinander stehen (Control Mapping). Der Implementation Layer beschreibt, wie Systeme die Controls umsetzen (Component Definition, System Security Plan). Der Assessment Layer beschreibt, wie geprüft wird und was gefunden wurde (Assessment Plan, Assessment Results, POA&M). Das öffentliche Referenzbeispiel ist FedRAMP: Der SP-800-53-Katalog wird per Baseline-Profil zugeschnitten, ein SSP implementiert die Auswahl, Assessments prüfen dagegen, das POA&M trackt die Lücken — jeder Schritt referenziert maschinenlesbar den vorherigen. Dieselbe Kette funktioniert für jedes Framework, sobald ein Katalog als Daten existiert.

Ein OSCAL-Katalog spiegelt die Struktur des Quelldokuments: groups bilden Kapitel, Domänen oder Artikel ab; controls sind die adressierbaren Anforderungen mit stabiler ID; parts tragen den wortgetreuen Text — Statement, Guidance, Prüfziel — einzeln referenzierbar; params machen die „organization-defined“-Lücken eines Frameworks zu ausfüllbaren Datenfeldern; props liefern Labels und Sortierung; und im back-matter kann das Quelldokument selbst liegen, mit Hashes gesichert. Entscheidend ist die stabile Identität: Ein Control wie „ac-1“ bleibt über Versionen und Mappings hinweg dieselbe Referenz — Werkzeuge, Profile und Nachweise zeigen dauerhaft auf dasselbe Objekt statt auf eine Seitenzahl.

Fünf Eigenschaften, die mit einem PDF unmöglich und mit Daten trivial sind: Diff-bar — was hat sich zwischen zwei Framework-Versionen exakt geändert? Abfragbar — filtern, zählen, selektieren und reporten über alle Controls hinweg. Mappbar — Controls über Frameworks hinweg in Beziehung setzen: einmal implementieren, mehrfach erfüllen. Nachvollziehbar — jedes Element kann auf die exakte Quellstelle zeigen, aus der es stammt. Automatisierbar — Werkzeuge konsumieren die Daten direkt, ohne Re-Keying und ohne Copy-Paste-Drift. Für GRC-Teams heißt das: Versionswechsel werden Diffs statt Neuanfänge, Audits greifen auf belegbare Referenzen zu, und Mehrfach-Compliance wird eine Datenoperation.

NIST publiziert SP 800-53 nativ in OSCAL — aktuell Release 5.2.0 samt Assessment-Prozeduren aus SP 800-53A und den vier Baselines. Der stärkste Adoptionstreiber ist FedRAMP: Nach den 20x-Pilotphasen (26 und 14 maschinenlesbare Einreichungen) verpflichtet die Entscheidung vom März 2026 über 500 bestehende Rev5-Anbieter zu maschinenlesbaren bzw. semistrukturierten Autorisierungspaketen — mit Endfrist 1. November 2027; parallel ersetzt das 20x-Programm narrative Dokumentation durch 46 automatisiert prüfbare Key Security Indicators. International publizieren Australiens Signals Directorate das ISM samt Essential-Eight-Profilen in OSCAL, GovTech Singapur adaptiert den Standard behördenweit, CIS liefert die Controls v8/v8.1 und die Cloud Security Alliance ihre CCM v4.1 maschinenlesbar; AWS stellt nach eigener Ankündigung seit Frühjahr 2026 SOC-1- und SOC-2-Berichte zusätzlich in OSCAL bereit. Seit Februar 2025 bündelt die OSCAL Foundation (Steering Committee u. a. AWS und Cisco) die Community; das Tooling-Projekt OSCAL Compass ist seit Juni 2024 CNCF-Sandbox.

Seit dem 30. September 2025 stellt das BSI seine Stand-der-Technik-Bibliothek auf GitHub bereit — Regelwerke maschinenlesbar auf OSCAL-Basis, unter freier CC-BY-SA-4.0-Lizenz und nach OSCAL-Schichten organisiert. Der IT-Grundschutz-Nachfolger Grundschutz++ erscheint OSCAL-first: rund 1.000 Anforderungen in 20 Praktiken (Pilot-Build Mitte 2026), Pilotphase bis 30. September 2026, offizielle Vorstellung zur it-sa am 27. Oktober 2026, eine ISO-27001-Zertifizierung auf dieser Basis ist ab 2027 geplant. Auch der C5:2026 — 168 Kriterien in 17 Themenbereichen, strukturell am EUCS ausgerichtet — liegt erstmals maschinenlesbar vor. Auf EU-Ebene treiben die Horizon-Projekte MEDINA und EMERALD (Certification-as-a-Service, Laufzeit bis Oktober 2026) sowie die EUROSCAL-Community die OSCAL-Nutzung für automatisierte Cloud-Zertifizierung voran; bei der ECSO tagte im September 2025 erstmals eine European OSCAL Task Force. Eine ehrliche Grenze: Für ISO 27001 existiert wegen des ISO-Copyrights kein frei verteilbarer offizieller Katalog — ISO und IEC arbeiten mit der SMART-Initiative an eigenen maschinenlesbaren Normen.

Mit Version 1.2.0 vom Dezember 2025 wurde das Control-Mapping-Modell das achte OSCAL-Modell: mapping-collections verbinden Kataloge oder Profile auf Control- oder sogar Statement-Ebene — mit sechs mengentheoretischen Beziehungstypen (equal-to, equivalent-to, subset-of, superset-of, intersects-with, no-relationship), verpflichtender Begründung (syntactic, semantic oder functional nach NIST IR 8477) und Qualifiern für Teilüberdeckungen und Inkompatibilitäten. Flankiert wird das vom NIST-OLIR-Programm mit offiziellen CSF-2.0-Referenzen zu ISO/IEC 27001, CIS Controls und PCI DSS sowie Metaframeworks wie dem Secure Controls Framework mit nach eigenen Angaben über 200 gemappten Rahmenwerken. Die Praxis-Konsequenz: Wer NIS2, AI Act, ISO 27001, ISO 42001 und CRA zugleich schuldet, konsolidiert per Mapping auf ein internes Kontrollset — die kombinierte Gap-Analyse wird eine Abfrage, und aus fünf Umsetzungsprojekten wird eines. Wichtig bleibt: Mappings sind selten 1:1 — genau deshalb erzwingt das Modell Beziehungstyp und Begründung, statt Controls stillschweigend gleichzusetzen.

Im Assessment-Results-Modell werden Nachweise selbst zu Daten: Findings verknüpfen sich über Observations mit Evidenz-Verweisen, und die Nachweisdateien liegen als back-matter-Ressourcen vor — per Link mit kryptografischen Hashes gesichert oder direkt eingebettet. Das ist die Grundlage für kontinuierliche Assessments bis hin zu Continuous-ATO-Konzepten, wie sie das US-Verteidigungsministerium 2022 per Memorandum definiert hat. Für die Lieferkette ist die Component Definition der Schlüssel: Ein Software- oder Cloud-Anbieter beschreibt einmal maschinenlesbar, wie sein Produkt Controls unterstützt — und Kunden importieren diesen Baustein direkt in ihren System Security Plan, statt den nächsten Fragebogen zu beantworten. Das Tooling reift: compliance-trestle verwaltet OSCAL als Code in CI/CD-Pipelines, Compliance-to-Policy erzeugt aus Component Definitions native Policies für Kyverno oder Open Cluster Management und normalisiert Prüfergebnisse zurück in Assessment Results; komplementär verbindet CycloneDX 1.6 mit seinen Attestations SBOM und Compliance-Nachweis. Ehrlich bleibt: Die Komplexität des Standards ist real — ihr Nutzen entsteht, wenn eine Plattform sie kapselt, statt sie an Anwender durchzureichen.