Übersicht

OSCAL steht für Open Security Controls Assessment Language. NIST entwickelt den Standard gemeinsam mit der Industrie und der öffentlichen Community als maschinenlesbare Möglichkeit, Sicherheitskontrollen, ihre Umsetzung und ihre Bewertung zu beschreiben.

Private Vorbereitung: Secanis implementiertes Toolkit wird privat für Open Source vorbereitet und ist noch nicht veröffentlicht. Die CLI und Agent Skills bleiben zukünftige Projekte.

Was ist OSCAL?

OSCAL stellt eine Reihe miteinander verbundener Modelle bereit: Catalog, Profile, System Security Plan, Component Definition, Assessment Plan, Assessment Results und Plan of Action and Milestones (POA&M). Mit diesen Modellen können Teams Compliance-Daten zwischen Werkzeugen austauschen, anstatt sie in proprietären Dokumenten einzuschließen.

OSCAL-Inhalte können als JSON, XML und YAML serialisiert werden. Jedes Format bildet dieselben strukturierten Sicherheits- und Compliance-Konzepte ab, sodass Anwendungen das Format wählen können, das am besten zu ihren Arbeitsabläufen passt.

OSCAL-Einführung in regulatorischen Kontexten

Forschungsstand — zuletzt geprüft am 12. Juli 2026. Secani prüft kontinuierlich öffentlich verfügbare Primärquellen und bemüht sich, diese Übersicht aktuell zu halten. Sie ist nicht vollständig und stellt keine Rechtsberatung oder rechtliche Bewertung dar. Kennst du eine Aktualisierung oder eine fehlende staatliche Initiative? Schreib an hello@secani.com.

• 74 untersuchte Rechtsräume
• 12 bestätigte staatliche Initiativen
• 5 Länder mit bestätigter offizieller Nutzung

„Bestätigte offizielle Nutzung“ umfasst offizielle staatliche Veröffentlichungen, Beispiele, Pilotprojekte und operative Anforderungen mit begrenztem Scope; sie bedeutet nicht, dass OSCAL-Einreichungen verpflichtend sind. Die folgende Tabelle zeigt eine repräsentative Auswahl von sieben Initiativen aus Secanis manuell gepflegtem Forschungsstand.

So liest du den Reifegrad. Dies ist ein Forschungsreifegrad, keine rechtliche Einstufung:

• 2/5 — Pilotprojekt, Entwurf oder offizielles Beispiel
• 3/5 — Gepflegte offizielle Veröffentlichung
• 4/5 — Verbindliche operative Nutzung in einem definierten Umfang

Eine offizielle OSCAL-Veröffentlichung bedeutet nicht automatisch, dass Organisationen ihre eigenen SSPs oder Assessment Results in OSCAL einreichen müssen.

Lebenszyklus von OSCAL-Dokumenten

Violett: Kontrollebene. Türkis: Umsetzungsebene. Orange: Bewertungsebene.

So liest du diesen Lebenszyklus

0. Catalog übernehmen. Importiere einen maßgeblichen Catalog wie NIST SP 800-53 oder BSI IT-Grundschutz. Der Catalog enthält die vollständige Menge an Kontrollen, Aussagen, Hinweisen und offenen Parametern; du verfasst ihn nicht selbst.
1. Als Profile anpassen. Wähle eine Basislinie oder beginne von Grund auf, nimm Kontrollen mit Begründung auf oder schließe sie aus, lege Parameterwerte fest und füge optional organisationsspezifische Kontrollen hinzu oder ändere Aussagen. Das resultierende Profile ist ein kleines Dokument, das auf den Catalog verweist und diese Entscheidungen festhält.
2. Profile auflösen. Lass das Werkzeug das Profile mit seinem Catalog verbinden. Das Ergebnis ist die wirksame Kontrollliste mit angewendeter Auswahl und ausgefüllten Parameterwerten – die Arbeitscheckliste für alles, was folgt.
3. System Security Plan beschreiben. Beginne den System Security Plan (SSP) mit der Autorisierungsgrenze, Benutzern und Rollen, Informationstypen und Schutzbedarf sowie einem Inventar aus Software, Hardware, Richtlinien und Prozesskomponenten.
4. Jede Kontrolle beantworten. Halte für jede Aussage der aufgelösten Basislinie fest, wie sie umgesetzt ist, welche Komponente sie bereitstellt, wer verantwortlich ist und ob ihr Status umgesetzt, teilweise umgesetzt, geplant oder nicht anwendbar ist. Component Definition-Dokumente von Anbietern können wiederverwendbare Antworten liefern, während geplante Arbeiten in zukünftige POA&M-Einträge einfließen können.
5. Assessment Plan erstellen. Eine unabhängige Prüfstelle nutzt den SSP typischerweise, um festzulegen, welche Kontrollen und Komponenten bewertet werden, welche Methoden – untersuchen, befragen oder testen – eingesetzt werden und wann die Arbeit stattfindet.
6. Assessment Results festhalten. Die Prüfstelle erfasst Beobachtungen und unterstützende Nachweise, leitet daraus für jede Kontrolle erfüllte oder nicht erfüllte Feststellungen ab und dokumentiert die daraus entstehenden Risiken. Nachweisdateien können über OSCAL-Back-Matter angehängt werden.
7. POA&M erstellen. Die systemverantwortliche Person überführt offene Feststellungen und Risiken in Maßnahmen, die festhalten, was behoben wird, wer dafür verantwortlich ist, wann es fällig ist und welche Meilensteine zur Fertigstellung führen.
8. Kontinuierlich überwachen. Behebe Abweichungen, aktualisiere den SSP, teste erneut und aktualisiere Assessment Results und POA&M. Wenn eine neue Catalog-Version erscheint, kehre zur Profile-Anpassung zurück und nutze das Werkzeug, um Änderungen zu erkennen.

NIST-Ressourcen

• OSCAL bei NIST kennenlernen
• NIST-Projektübersicht lesen
• Offizielles OSCAL-Repository entdecken

Secani-Projekte

Secanis @secani/oscal-TypeScript-Toolkit ist implementiert und wird privat für Open Source vorbereitet, ist aber noch nicht veröffentlicht. Es kann derzeit OSCAL-1.2.2-JSON-Dokumente parsen, validieren und analysieren. Die separate oscal-cli-Kommandozeilenschnittstelle und die Sammlung secani/oscal-skills bleiben zukünftige Projekte.

Bis das Toolkit-Repository öffentlich ist, folge Secani auf GitHub, um Neuigkeiten zu erhalten.

• TypeScript-Toolkit entdecken
• oscal-cli entdecken