Spočítali jsme každé omezení v OSCAL 1.2.2. Všech 348.

Každý validátor OSCAL tvrdí, že „validuje OSCAL“. Téměř žádný z nich vám neřekne, co ta věta znamená.

Modely OSCAL od NIST jsou napsány v Metaschema – osm kořenových modulů plus sdílené importy, tisíce řádků XML, které definují nejen tvar dokumentu, ale i jeho sémantiku: povolené slovníky hodnot, pravidla jedinečnosti, indexy křížových odkazů, požadavky na kardinalitu. JSON Schema zachytí tvar. Sémantika je ale místem, kde se dokumenty compliance skutečně pokazí – a kde se z „validujeme OSCAL“ potichu stane „validujeme část OSCAL, nejsme si jistí kterou“.

My jsme si chtěli být jistí, kterou část. Proto jsme svůj validátor postavili tak, jako byste auditovali systém: začít u zdrojů, vše vyčíslit a vykázat každou jednotlivou položku.

Připnutí standardu na úroveň bajtů

První rozhodnutí bylo to nejdůležitější: autoritou jsou zdroje NIST – ne referenční implementace. Připnuli jsme usnistgov/OSCAL na commit 21403b4a… (v1.2.2), každý bajt Metaschema jsme přesně uložili do cache s hashi SHA-256 a ctihodné Java OSCAL CLI jsme brali jako to, čím skutečně je: srovnávací nástroj ke křížovému výslechu, ne pravdu ke kopírování. (Mimo jiné obsahuje vazby pro OSCAL 1.2.1 – dokumenty 1.2.2 dokáže zpracovat, ale mluvit jazykem 1.2.2 neumí.)

Poté jsme lexikálně inventarizovali každý výskyt omezení v připnutých zdrojích. Ne typy omezení – výskyty, identifikované souborem a řádkem, aby dvě omezení, která náhodou sdílejí ID, nikdy nesplynula v jedno. Napočítali jsme 348.

Prokázání každého z nich

Pro každý výskyt musí náš build mít přesně jeden ze tří verdiktů, což vynucuje generátor, který při každém běhu znovu přepočítá evidenci:

• Prokazatelně vynuceno (303): test přesný na úrovni výskytu spustí skutečný vyhodnocovač nad minimálním dokumentem a ověří, že byl vyhodnocen právě tento výskyt na daném souboru a řádku. AST testu je strojově ověřen – testovaný subjekt se musí provést přesně jednou a jeho výsledek musí vstoupit přesně do jedné aserce – a soubor testu včetně jeho tranzitivních importů je připnut hashem. Změňte vyhodnocovač a důkazy zastarají, dokud nebudou znovu odvozeny.
• Vynuceno schématem (1): prokazatelně pokryto JSON Schema daného vydání.
• Vyloučeno se zdůvodněním (44): výslovně vyřazeno, každé s písemným, přezkoumatelným důvodem.

Nevykázáno: nula.

Právě tato poslední skupina – vyloučení – se ukázala jako zajímavá.

Standard má chyby

Když kontrolujete 348 omezení jedno po druhém, na leccos narazíte. Tři z našich vyloučení jsou vady přímo ve zdrojích NIST:

• Osiřelé omezení. oscal_mapping-common_metaschema.xml na řádku 657 omezuje flag, který je definován o pět řádků výše – a poté na něj nic neodkazuje. Žádný dokument, který může existovat, tento flag nenese. Omezení je nesplnitelné.
• Nemožný predikát. Pravidlo pro názvy prop u inventory-item platí jen tehdy, když je @type rovno software, hardware nebo service – jenže inventory-item žádný flag type vůbec nedeklaruje. (Jeho soused asset-id je ve zdroji sám zakomentovaný.) Predikát nemůže nikdy odpovídat.
• Omezení uvnitř komentářů. Pět výskytů omezení se nachází uvnitř bloků komentářů – včetně celého slovníku hodnot pro with-child-controls v profilu. Člověk, který čte zdroj, je vidí; zkompilované schéma je nikdy nevynutí. Všechna tři zjištění jsme nahlásili upstream: usnistgov/OSCAL#2254, #2255, #2256.

A audit působil oběma směry: náš vlastní vyhodnocovač měl chybu, kdy se omezení cílící na flagy (například povolené hodnoty action/@type) zkompilovala do inventáře, ale potichu se nikdy nespustila. Nenašli jsme ji náhodou – brána uzávěru odmítla přijmout důkazy pro tyto dva výskyty, což je přesně ten druh selhání, který má celý systém odhalovat.

Pak jsme srovnání skutečně spustili

Tvrdit „referenční implementace něco přehlíží“ jen na základě prohlídky zdrojů je přesně ten druh neprokázaného tvrzení, který má tento projekt odstranit. Stáhli jsme proto Java OSCAL CLI 3.2.0 z Maven Central, ověřili jeho hash a spustili oba validátory nad rodinou testovacích dokumentů, jejichž výchozí dokumenty čistě projdou na obou stranách – takže každou neshodu lze přičíst jediné vložené změně.

OSCAL 1.2.2 změnil kromě navýšení verzí přesně dvě omezení (obě v modelu SSP). Java CLI – které obsahuje vazby pro 1.2.1 – stojí u každého pozorovatelného důsledku na špatné straně:

• SSP s visícím odkazem na komponentu rel="validation" porušuje 1.2.2. Java: platné, návratový kód 0.
• SSP s visícím odkazem rel="validated-by" je podle 1.2.2 v pořádku (omezení bylo odstraněno). Java: neplatné.
• responsible-role bez volitelného party-uuid je podle 1.2.2 v pořádku – NIST přidal predikát právě proto, aby to opravil. Java skončí chybou doslova Key reference [null] not found.

Pak jeden případ, který s rozdílem verzí vůbec nesouvisí: katalog, jehož action v metadatech deklaruje "type": "invented-type" – zakázáno na řádku 877 Metaschema pro metadata jak v 1.2.2, tak ve zdrojích 1.2.1, které Java obsahuje. Java ho prohlásí za platný, v JSON i v XML. Omezení cílí na flag; omezení cílící na flagy, která se potichu nespouštějí, jsou přesně tou třídou chyb, kterou naše brána úplnosti zachytila v našem vlastním vyhodnocovači. Referenční implementace má stejnou třídu chyb – a žádnou bránu uzávěru, která by ji zachytila. Nahlásili jsme ji upstream jako metaschema-framework/oscal-cli#279. (Třídu jsme zmapovali strojově: přesně 2 z 200 výskytů allowed-values cílí na flagy a jediný člen na úrovni chyby je ten, který jsme živě otestovali. Žádný netestovaný zbytek.)

A teď ta poctivá část, protože běh působil oběma směry: náš validátor odmítl vlastní katalog NIST SP 800-53 rev5. Dvacet chyb, všechny s jedinou příčinou – náš vyhodnocovač indexů považoval chybějící volitelné klíčové pole za porušení, zatímco specifikace Metaschema říká, že jde o nulový klíč. Java soubor přijala; mýlili jsme se my; opravili jsme to ještě týž den a 800-53 se nyní validuje čistě. Běh později zachytil i druhou chybu: slovník typů akcí OSCAL jsme vynucovali i tehdy, když action/@system deklaroval vlastní URI – přesně tu segmentaci podle organizace, kterou požadují poznámky samotného NIST. Také opraveno. Diferenciální testovací systém, který vždy najde jen chyby druhé strany, není testovací systém, ale marketing.

(Do kategorie „obě strany“ patří i to, že ani jeden resolver sémanticky nevalidoval vlastní výstup. resolve-profile v Javě klidně zapíše katalog, který pak vlastní validate v Javě odmítne – a náš dělal totéž, hlídaný schématem, ale ne sémantikou. Náš nyní odmítá zapisovat sémanticky neplatná rozlišení; Java to stále nedokáže, protože uzavření této díry vyžaduje sémantickou vrstvu, které důvěřujete.)

Validace grafu, nejen souboru

Druhá věc, která stávajícím nástrojům chybí: dokumenty OSCAL nežijí osamoceně. Výsledek posouzení importuje plán posouzení, který importuje SSP, který importuje profil, který se rozlišuje vůči katalogům. Dokumentace modelů je plná vztahů, které žádný validátor jednotlivých souborů nedokáže zkontrolovat – „cíl tohoto zjištění se musí rozlišit na výrok v baseline“, „tento POA&M musí identifikovat svůj systém“.

Proto jsme vytvořili validaci napříč dokumenty, která tyto hrany skutečně rozlišuje. Požádejte ji o kontrolu SSP a ona rozliší importovanou baseline celou pipeline pro rozlišení profilů (podle návrhu specifikace) až ke katalogům, vypočte vybranou sadu opatření a sdělí vám:

{
  "ruleId": "SSP-003.b",
  "severity": "warning",
  "path": "/…/implemented-requirements/1/control-id",
  "message": "implemented control 'ac-99' is not supplied by the resolved import-profile 'file:///…/baseline.json'"
}

S jedním zásadním pravidlem návrhu: tyto kontroly vztahů jsou interpretacemi zdokumentované prózy a tak s nimi také zacházíme – ve výchozím stavu vypnuté, varování místo chyb, rozsah rozlišení každého pole připnutý k jeho zdrojovému řádku a vše, co je pouze odvoditelné, jmenovitě vyloučeno. Tam, kde standard zůstává nejednoznačný, by validátor neměl blafovat. (Náš oblíbený příklad: specifikace POA&M říká, že je vyžadován import SSP nebo system-id – „Both may be present.“ Varujeme proto jen tehdy, když neexistuje ani jedno. Žádné vymyšlené exkluzivní nebo.)

Proč TypeScript?

Protože dokumenty žijí v prohlížečích, serverless funkcích, CLI a databázích – a my jsme chtěli jeden validátor ve všech z nich, ne JVM sidecar vedle každého. Validátory jsou předkompilované samostatné moduly Ajv: čistý generovaný JavaScript, žádná kompilace schémat za běhu, bajtově stabilní výstup. Stejný kód, který pohání naše validační rozhraní, běží beze změny ve vaší záložce prohlížeče i v našem CLI. A determinismus není jen provozní vymoženost – je tím, co hashem připnuté důkazy vůbec umožňuje.

import { createDiagnosticsOscalProcessor } from "@secani/oscal/diagnostics";
const result = createDiagnosticsOscalProcessor({ maxIssues: 50 }).validate(doc);

Kde jsme skončili

• Plná podpora OSCAL 1.1.2 → 1.2.2, nativní sémantika 1.2.2
• Úplné rozlišení profilů podle návrhu specifikace, s bezpečným selháním (fail-closed) u všeho, co návrh ponechává nedefinované – a resolver, který odmítá zapsat sémanticky neplatný výstup
• Celé rozhraní Java CLI pro práci s OSCAL, plus validace grafu, kterou nikdy nemělo (validate --resolve-imports --interpretive all)
• A tvrzení, které můžete auditovat: 348/348 výskytů omezení vykázáno ve strojově čitelné evidenci, kterou naše CI přepočítává při každém commitu

Úplná technická zpráva – model autority, uzávěr úplnosti, tabulka diferenciálních dokladů a to, co záměrně netvrdíme – je k dispozici v dokumentaci validátoru. Validátor je v soukromém stagingu před vydáním jako open source; hostované validační API dnes zpřístupňuje úroveň schématu a sémantická vrstva bude následovat.