Validatore

Preparazione privata: Il validatore qui descritto viene spedito all'interno del secani/oscal toolkit, che rimane privato mentre è preparato per l'open source. Tutti i conteggi, le citazioni e i localizzatori riportati di seguito sono presi dal registro leggibile dalla macchina nel toolkit validation/ directory e sono nuovamente verificabili tramite pnpm verify.

Riepilogo

Il toolkit OSCAL di Secani convalida i documenti OSCAL NIST rispetto a ciò che le fonti NIST effettivamente affermano – non rispetto a ciò che fa qualsiasi implementazione di riferimento. Raggiunge la piena parità di capacità con la superficie Java OSCAL CLI 3.2.0, quindi la supera in quattro modi in cui lo stack Java non tenta:

1. Una prova di completezza controllata dalla macchina: ognuna delle 348 occorrenze di vincoli rilevabili negli otto metaschemi root OSCAL 1.2.2 è riconciliata individualmente: applicata, coperta da schemi dimostrata o esplicitamente esclusa con una motivazione scritta. Zero risultano dispersi.
2. Semantica OSCAL 1.2.2 nativa con supporto multi-release (1.1.2, 1.1.3, 1.2.1, 1.2.2), dove Java CLI 3.2.0 incorpora collegamenti OSCAL 1.2.1 e può elaborare documenti 1.2.2 solo in base alla compatibilità.
3. Convalida del flusso di lavoro tra documenti: risoluzione e controllo del grafico di riferimento tra SSP, piani di valutazione, risultati della valutazione e POA&M, che è completamente esterno alla superficie di convalida della CLI Java.
4. Una base di codice TypeScript che viene eseguita ovunque risiedano i documenti: gli stessi validatori precompilati vengono eseguiti nel browser, in percorsi API serverless, nella CLI e nel backend, senza JVM da nessuna parte.

Il processo ha anche fatto emergere difetti nelle stesse fonti del NIST (vedi Trovare bug – in entrambe le direzioni), che è ciò che ci si aspetterebbe dalla verifica a livello di evento, nonché la prova più forte a favore.

Il modello di autorità: le fonti sulle implementazioni

La regola di ambito vincolante del progetto:

L'autorità è la fonte NIST OSCAL. Java è un comparatore di compatibilità e una prova di implementazione, mai l'autorità.

Concretamente, ogni affermazione semantica è fissata ai byte:

• Autorità: usnistgov/OSCAL, tag v1.2.2, commit 21403b4ad2f162ef1201e5ee70e8b93f254f51ac: gli otto moduli Metaschema radice (catalogo, profilo, definizione dei componenti, SSP, piano di valutazione, risultati della valutazione, POA&M e mappatura), i relativi import comuni (metadati, controlli, implementazione, valutazione e mappatura) e le entità di vincolo esterne. Tutti vengono memorizzati nella cache byte per byte e fissati mediante hash SHA-256.
• Risoluzione del profilo: la bozza delle specifiche del NIST src/specifications/profile-resolution/profile-resolution-specml.xml. Perché è bozza/WIP, i suoi requisiti sono implementati dietro una capacità esplicita e mai inseriti silenziosamente nella validazione ordinaria.
• Confronto: Java OSCAL CLI 3.2.0 con liboscal-java 7.2.0, che incorpora i collegamenti OSCAL 1.2.1. L'evidenza comparativa viene registrata con localizzatori esatti dell'occorrenza; i riferimenti senza byte memorizzati nella cache e localizzatori esatti sono etichettati ispezione della fonte non qualificata e non possono chiudere un cancello di provenienza.

Questa è l'inversione che conta: la maggior parte degli strumenti tratta l'implementazione di riferimento come verità fondamentale. Trattiamo le fonti dello standard come verità fondate e trattiamo l'implementazione di riferimento come un testimone da sottointerrogare.

Esempio: aspetto di un'attestazione bloccata nel localizzatore. Il registro non dice "supportiamo i controlli del ruolo della parte responsabile". Dice: vincolo oscal-metadata-responsible-party-role-ids, fonte oscal_metadata_metaschema.xml@L400, file sorgente SHA-256 bloccato, applicato dalla regola META-002.a, dimostrato da un test denominato di cui viene registrato l'hash AST. Se il NIST modifica quella riga, il perno si rompe e la richiesta deve essere riqualificata.

La chiusura della completezza: tenere conto di ogni vincolo

Le fonti Metaschema definiscono i vincoli (allowed-values, is-unique, matches, index, index-has-key, has-cardinality, expect) sparsi su migliaia di righe di XML. Un validatore può affermare di "supportare i vincoli OSCAL" senza che nessuno sia in grado di verificare cosa significhi. Lo abbiamo reso controllabile.

La chiusura di completezza inventaria lessicalmente 348 occorrenze di vincoli nel grafico del modulo bloccato, incluse 17 occorrenze anonime e 8 occorrenze conservate all'interno dei commenti della fonte, perché decidere che non contano è di per sé una decisione rivedibile. L'identità dell'occorrenza include il percorso e la linea di origine, pertanto gli ID dei vincoli ripetuti non vengono mai compressi.

Ogni occorrenza deve rientrare esattamente in un contenitore di prove chiuso:

Esempio: cosa significa "evidenza esatta dell'occorrenza" nel codice. Ogni occorrenza provata ha una dichiarazione come questa nella suite di test:

closureEvidenceTest(
  {
    assertionIds: ["META-012.b"],
    name: "allowed-values assessment-common oscal-assessment-objective-types@L65 occurrence",
    releases: [],
    subject: "evaluateBuiltinAllowedValues",
  },
  () => {
    const evaluation = evaluateBuiltinAllowedValues(
      {
        "assessment-results": {
          "local-definitions": {
            "objectives-and-methods": [{ parts: [{ name: "assessment" }] }],
          },
        },
      },
      "assessment-results",
    );
    expect(evaluation).toMatchObject({
      evaluatedInventoryIds: expect.arrayContaining([
        "oscal_assessment-common_metaschema.xml#oscal-assessment-objective-types@L65",
      ]),
    });
  },
);

Il test guida il valutatore reale su un documento minimo e asserisce che è stata valutata l'esatta occorrenza della fonte: file, ID vincolo, riga. Il formato dell'evidenza è deliberatamente difficile da falsificare: l'AST TypeScript della dichiarazione è verificato (il soggetto dichiarato deve essere eseguito esattamente una volta; il suo risultato deve confluire esattamente in uno di livello superiore expect) e la dichiarazione, il relativo file e lo SHA-256 della chiusura dell'importazione transitiva vengono bloccati. Cambia il valutatore e ogni hash di prova dipendente diventa obsoleto fino a quando non viene nuovamente derivato meccanicamente. Un test rinominato, un organismo non operativo o un aiutante mutato invalidano automaticamente le prove.

Le 44 esclusioni non sono improvvisate: 5 occorrenze si trovano all'interno di commenti XML nelle fonti NIST (testo morto), 2 sono difetti a monte (vedi sotto), 3 sono elementi di confine del modello documentati e 34 sono vincoli attivi che vengono applicati in fase di esecuzione per impostazione predefinita ma non rientrano nell'inventario bloccato di 93 asserzioni del registro di ricerca: ciascuna esclusione nomina il valutatore generato che lo applica.

Con unresolved = 0, l'artefatto si ribalta exhaustiveRequirementClaimAllowed: true – un flag che il generatore calcola dai conteggi del bucket, non una frase scritta da un essere umano.

Registro dei requisiti: 40 su 42, con prese oneste

Al di sopra del livello di occorrenza si trova un registro di 42 requisiti di ricerca (93 asserzioni atomiche) che abbracciano l'instradamento dello schema, la semantica dei metadati, il catalogo/profile regole, risoluzione del profilo, risoluzione tra documenti e convalida del flusso di lavoro. 40 sono implemented; ogni rotazione richiedeva un percorso di runtime denominato più un vero positivo/negative test. I due punti aperti sono prese deliberate e documentate:

• PRES-004 (mappature degli identificatori di importazione): la bozza delle specifiche afferma che la mappatura ha cinque sottosezioni facoltative ma ne definisce concretamente solo una (mapping[].controls[{from,to}]), e il profilo 1.2.2 bloccato Metaschema definisce n mapping SU import affatto. Implementiamo la forma supportata dall'esempio e falliamo la chiusura su tutto il resto:

  $ oscal-cli resolve-profile --to JSON profile-with-param-mapping.json
  oscal-cli: unsupported import mapping subsection 'params' in pinned draft

Rivendicare il supporto completo della mappatura significherebbe inventare una semantica che la sorgente non contiene.

• META-013 (rappresentazioni di risorse alternative equivalenti): la fonte richiede più rlink/base64 rappresentazioni di una risorsa per "contenere informazioni equivalenti" senza definire operativamente l'equivalenza (uguaglianza dei byte? uguaglianza semantica dopo la conversione del formato?). L'applicazione resta in attesa di una definizione, piuttosto che inventarne una.

Ciò che il validatore fa rispetto a Java CLI 3.2.0

Semantica nativa 1.2.2, routing multi-release

Java CLI 3.2.0 incorpora liboscal-java 7.2.0 con collegamenti OSCAL 1.2.1; un'esecuzione invariata su un documento 1.2.2 è compatibilità osservativa, non convalida 1.2.2. Secani fornisce routing dello schema sensibile alla versione e validatori precompilati per 1.1.2, 1.1.3, 1.2.1 e 1.2.2, con 1.2.2 come obiettivo di implementazione semantica – e fallisce la chiusura sui rilasci non qualificati invece di convalidare silenziosamente contro la generazione sbagliata.

Il livello di vincolo semantico generato

Il livello semantico ordinario (attivato per impostazione predefinita) valuta, per documento, l'inventario dei vincoli bloccati: tutti 200 attivi allowed-values occorrenze (inclusi target dell'asse discendente e target indirizzati a flag come action/@type), tutti con ambito **27 is-unique**occorrenze, 24 su 25 attive matches occorrenze (la 25 viene applicata da una regola di metadati proprietaria), il file generato expect, has-cardinality, e file locale index/index-has-key valutatori e i metadati/catalog/profile/SSP famiglie di regole semantiche. Ogni diagnostica porta la sua provenienza NIST. Questo è l'output di runtime letterale per un catalogo i cui metadati action dichiara "type": "invented-type":

{
  "ruleId": "oscal-metadata-action-type-values",
  "sourceId": "https://raw.githubusercontent.com/usnistgov/OSCAL/21403b4ad2f162ef1201e5ee70e8b93f254f51ac/src/metaschema/oscal_metadata_metaschema.xml#L877",
  "sourceType": "oscal-constraint",
  "authority": "nist-metaschema",
  "severity": "error",
  "phase": "semantic",
  "path": "/catalog/metadata/actions/0/type",
  "message": "value \"invented-type\" is not one of the allowed values: \"approval\", \"request-changes\"",
  "keyword": "allowed-values"
}

IL sourceId non è un'etichetta: è un puntatore cliccabile e bloccato sulla linea esatta del Metaschema che impone la regola. (Questa particolare diagnostica è anche un differenziale in tempo reale: Java CLI 3.2.0 accetta questo documento esatto – in JSON e XML – anche se il vincolo si trova a L877 del Metaschema di metadati 1.2.1 incorporato dai suoi collegamenti; vedere la ricevuta R4 di seguito.)

Risoluzione completa del profilo secondo la bozza delle specifiche

resolve-profile implementa il processo di risoluzione della bozza del NIST dall'inizio alla fine – e fallisce quando la bozza è indefinita piuttosto che indovinare:

$ oscal-cli resolve-profile --to JSON baseline-profile.json resolved-catalog.json
$ oscal-cli resolve-profile --to JSON legacy-combine.json
oscal-cli: deprecated combine method 'merge' has undefined resolution behavior

$ oscal-cli resolve-profile --to JSON mixed-major.json
oscal-cli: major OSCAL version mismatch between '1.2.2' and '2.0.0' at 'file:///…/legacy.json'

In copertura: acquisizione import con ciclo/depth/byte budget, interni #uuid le importazioni inclusi i documenti incorporati in Base64 includono/exclude selezione con with-child-controls espansione, keep/use-first combinare la semantica, as-is/custom/flat strutturazione, parametri deterministici, applicazione di alterazioni e materiale di fondo si fondono con le esatte regole di ordinamento della bozza (i duplicati successivi vengono sostituiti nella posizione successiva; a keep=always la risorsa blocca la sostituzione non contrassegnata).

La finalizzazione dell'output è il luogo in cui vivono diverse garanzie sottili: quelle dichiarate oscal-version del risultato è limitato alla versione più alta supportata della stessa major; le chiavi sono emesse nell'ordine canonico OSCAL; e il catalogo risolto viene riconvalidato – schema e vincoli semantici – prima della serializzazione, quindi un risultato di risoluzione non valido è un rifiuto, non un output. La CLI Java non esegue quel controllo sul proprio output: il suo risolutore scriverà un catalogo che il suo stesso validatore poi rifiuterà (ricevuta R6 di seguito).

Convalida del flusso di lavoro tra documenti (non nella superficie Java)

Questo è l'elemento di differenziazione. Gli artefatti di conformità OSCAL formano un grafico – un risultato di valutazione importa un piano di valutazione, che importa un SSP, che importa un profilo, che si risolve rispetto ai cataloghi – e la documentazione del modello indica le relazioni che nessuno schema JSON può verificare. Il validatore del grafico del documento risolve questi bordi e li verifica.

Esempio. Un SSP afferma di implementare il controllo ac-99, ma la linea di base che importa non fornisce mai quel controllo. Con le regole interpretative abilitate, il validatore del grafico risolve la linea di base attraverso l'intera pipeline di risoluzione del profilo fino ai suoi cataloghi, calcola il set di controlli selezionato ed emette (forma letterale del problema):

{
  "ruleId": "SSP-003.b",
  "sourceId": "secani:oscal-ssp-import-profile-interpretation:v1",
  "sourceType": "validation-dispatch",
  "authority": "secani-policy",
  "severity": "warning",
  "phase": "resolution",
  "path": "/system-security-plan/control-implementation/implemented-requirements/1/control-id",
  "message": "implemented control 'ac-99' is not supplied by the resolved import-profile 'file:///…/baseline.json'",
  "keyword": "implemented-control-supplied"
}

Da notare la disciplina della provenienza anche qui: l'autorità c'è secani-policy sotto una fonte di interpretazione con versione – no nist-metaschema – perché questo controllo è la nostra interpretazione documentata, non il vincolo della macchina del NIST. Dalla CLI i controlli sono raggiungibili tramite oscal-cli validate --resolve-imports --interpretive SSP-003.b ssp.json (ripetibile, o --interpretive all; --warnings-as-errors li promuove ad un'uscita fallita).

L'intera famiglia di regole, ciascuna fissata al suo ancoraggio nelle fonti:

Esempio: implementare esattamente la prosa. L'osservazione POA&M Metaschema recita:

"È necessario importare un SSP basato su OSCAL oppure specificare un ID di sistema univoco. Entrambi potrebbero essere presenti." – oscal_poam_metaschema.xml @L58-60

POAM-001.a avvisa solo quando nessuno è presente. Un test pin che fornisca entrambi rimane silenzioso, perché inventare un'esclusiva o la fonte non lo dichiara è esattamente il tipo di convalida eccessiva che questo progetto si rifiuta di fare.

Due decisioni di progettazione contano tanto quanto i controlli:

• Onestà interpretativa. Queste relazioni sono documentate in prosa, non come vincoli della macchina – in modo rivelatore, il piano di valutazione stesso index-has-key per questi UUID esiste nella fonte NIST solo come "esempio fasullo" commentato. Pertanto le regole sono disattivate per impostazione predefinita, emettono avvisi, non trasformano mai un documento in non valido e vengono eseguite solo quando un chiamante le nomina esplicitamente.
• Ambito bloccato prima del codice. La nota del registro di ciascuna regola registra, per campo di riferimento, l'ambito e il localizzatore della risoluzione documentata e ciò che è stato escluso per nome. subject-uuid, ad esempio, è documentato come risolto in "ogni file importato direttamente o indirettamente" (@L652-654) - transitivamente tra documenti - quindi è esplicitamente fuori dall'ambito piuttosto che implementato a metà.

Superficie CLI: parità più

Tutte le 22 funzionalità Java CLI rivolte a OSCAL sono coperte da contratti di accettazione osservabili (comando, opzioni, input, successo/failure output, codici di uscita): convalidare/convert attraverso JSON/XML/YAML, resolve-profile, list-allowed-values, SARIF deterministico (--sarif-include-pass, --sarif-timing), --threads partizionamento dei lavoratori con ordine canonico dei risultati, metapath/xpath/jsonpointer rendering del percorso, alias dei comandi del modello, completamento della shell. In alto: --prune, --interpretive, esportazioni di schemi aggiunti alla versione e API di diagnostica programmatica.

Perché TypeScript

1. Un artefatto, ogni runtime. I validatori sono moduli Ajv precompilati autonomi: JavaScript generato semplicemente, nessuna compilazione di schemi runtime, nessuna riflessione, nessun interprete Metaschema. Il percorso del codice identico viene eseguito nel browser, nei percorsi API serverless, nel nodo (CLI) e all'interno del backend. Lo stack Java richiederebbe una JVM in ciascuna di queste posizioni o una porta con perdite.

2. La piattaforma è dove vivono i documenti. Il prodotto di Secani è una piattaforma web; la sua API di convalida, il workbench di creazione e il server MCP utilizzano il toolkit come una libreria tipizzata in-process:

   import { createDiagnosticsOscalProcessor } from "@secani/oscal/diagnostics";
   
   const processor = createDiagnosticsOscalProcessor({ maxIssues: 50 });
   const result = processor.validate(document);
   // OscalValidationResult:
   // { ok, complete, modelType, oscalVersion, layers,
   //   errors, issues, totalIssueCount, truncated }

Nessun IPC sottoprocesso contro un binario Java, nessun contenitore sidecar, nessuna JVM con avvio a freddo. 3. Determinismo come caratteristica. I validatori precompilati + i valutatori generati + l'ordinamento canonico delle chiavi rendono gli output stabili in termini di byte - che è ciò che consente al sistema di prove di fissare gli hash sul comportamento in primo luogo. 4. Distribuzione. Un pacchetto digitato con punti di ingresso dedicati (., ./browser, ./versioned, ./diagnostics) raggiunge l'ecosistema in cui vengono effettivamente realizzate le UI di conformità. 5. Sicurezza del tipo rispetto al modello. Le mappe del modello generate rendono "questo vincolo prende di mira un flag, non un elemento" una proprietà controllabile staticamente – con un test di guardia che non asserisce alcun flag/element esiste una collisione dei nomi in tutte le 1.011 forme di nodo del modello bloccato.

Ciò che TypeScript non ci ha comprato è l'esenzione dalla prova: la chiusura della completezza esiste proprio per cui la scelta del linguaggio è supportata da prove a livello di occorrenza, non da affermazioni sull'esperienza dello sviluppatore.

Trovare bug – in entrambe le direzioni

La verifica a livello di occorrenza ha rilevato difetti reali da entrambe le parti, che è l’argomentazione più forte a sostegno del fatto che la metodologia funziona.

Nel nostro valutatore (trovato dal cancello di chiusura). Due vincoli di metadati prendono di mira i flag (attributi) anziché gli elementi secondari: i valori consentiti di action/@system E action/@type (oscal_metadata_metaschema.xml @L874, @L877). Sono stati compilati nell'inventario supportato ma non sono mai stati attivati: il percorso del valutatore ha risolto i passaggi secondari solo rispetto agli elementi del modello, quindi entrambi i vincoli non hanno valutato silenziosamente nulla. Il cancello di chiusura ha rifiutato di accettare prove per loro, ed è così che è emerso il bug. Risolto il problema con la corretta risoluzione del passo di bandiera; una passeggiata statica sul grafico di definizione ha dimostrato che erano interessati esattamente questi due eventi.

Nel nostro valutatore (trovato dalla corsa differenziale in tempo reale – entrambi risolti lo stesso giorno). Innanzitutto, il index valutatore ha trattato un valore mancante del campo chiave come un errore, rifiutando qualsiasi catalogo contenente un file prop senza a uuid – incluso il catalogo SP 800-53 rev5 del NIST (20 errori segnalati; Java 3.2.0 lo accetta). La specifica Metaschema specifica esplicitamente che un valore del campo chiave mancante produce una chiave dell'indice nulla, non una violazione; 800-53 ora convalida pulito. In secondo luogo, il vocabolario di tipo azione OSCAL è rimasto vincolato anche quando action/@system ha dichiarato un URI personalizzato, contraddicendo le osservazioni del NIST secondo cui @system "fornisce un mezzo per segmentare lo spazio dei valori per il type"per organizzazione. Entrambe le correzioni sono state fornite con test di regressione e hash di prova nuovamente derivati.

Nelle fonti NIST:

• Un vincolo orfano. oscal_mapping-common_metaschema.xml @L657 vincola un flag definito in @L652 – a cui non fa mai riferimento nessuno flag ref. Nessun nodo del modello lo supporta; il vincolo è insoddisfacibile per qualsiasi documento che possa esistere.
• Un predicato impossibile. oscal_implementation-common_metaschema.xml @L567 vincola i nomi delle oggetti di scena in a @type fare affidamento su inventory-item - Ma inventory-item dichiara n type flag (il suo fratello asset-id flag è esso stesso commentato in @L456-461). Il predicato non può mai corrispondere.
• Vincoli che vivono all'interno dei commenti. Cinque occorrenze – tra cui a with-child-controls vocabolario di valori nel profilo Metaschema – esiste solo all'interno dei blocchi di commento: testo che un lettore lessicale trova ma che lo schema compilato non applica mai.

Ciascuno è registrato come excluded-with-rationale con il suo localizzatore esatto – verificabile e riportato a monte: usnistgov/OSCAL#2254 (bandiera orfana), #2255 (predicato impossibile), #2256 (vincoli nei commenti). Il divario nell'applicazione delle bandiere negli strumenti di riferimento è riportato come metaschema-framework/oscal-cli#279.

La corsa differenziale in tempo reale: incassi, entrambe le direzioni

Il 18 luglio 2026 abbiamo colmato il divario tra le affermazioni ricavate dall’ispezione del comparatore e le prove eseguite. Abbiamo scaricato Java OSCAL CLI 3.2.0 da Maven Central, verificato i byte rispetto agli hash SHA-256/SHA-512 registrati ed eseguito entrambe le toolchain su una famiglia di casi di test i cui documenti di base risultano validi su entrambi i lati. Ogni differenza è quindi attribuibile a una sola modifica introdotta. Il commit OSCAL incorporato (26df0501) corrisponde alla release patch 1.2.1 e conferma il divario dei binding a runtime. Trascrizioni complete, fixture e codici di uscita sono registrati nelle ricevute differenziali insieme al registro.

Tre modelli, onestamente separati: R1–R3 sono differenziali puri vincolanti obsoleti – 1.2.2 ha modificato esattamente due vincoli oltre i bump di versione, entrambi nel modello SSP, e Java è dalla parte sbagliata di tutti e tre i comportamenti osservabili (un falso negativo, due falsi positivi, uno dei quali errore sull'assenza di un campo opzionale). R4 è un gap nell'applicazione indipendente dalla distorsione della versione: il testo del vincolo è identico in byte nei sorgenti incorporati in Java e la classe interessata è completamente mappata: un'enumerazione meccanica sull'inventario bloccato mostra esattamente 2 dei 200 flag di destinazione delle occorrenze di valori consentiti attivi; l'unico membro con grado di errore è quello testato dal vivo, quindi non non testato il resto esiste. R5 è un gap di capacità, non un difetto e il nostro controllo rimane un avviso di adesione perché la fonte è prosaica, non un vincolo della macchina. R6 e R7 ci hanno tagliato la strada per primi e sono stati riparati lo stesso giorno; rimangono nella tabella perché un cablaggio differenziale che trova sempre e solo i bug dell'altro lato non è un cablaggio.

Ciò che volutamente non rivendichiamo

• La specifica della risoluzione del profilo è bozza; Il comportamento della famiglia PRES è limitato alle funzionalità e i vincoli a livello di AVVISO NIST mantengono gli avvisi.
• Le regole del flusso di lavoro sono interpretazioni di relazioni documentate, contrassegnate come tali e disattivate per impostazione predefinita.
• Le prove comparative del registro rimangono etichettate in base al controllo della fonte; l'esecuzione differenziale in tempo reale la integra con ricevute eseguite e contrassegnate da hash, ma non aggiorna silenziosamente il livello di prova del registro: l'inserimento delle trascrizioni nel cancello di qualificazione formale viene monitorato separatamente.
• 34 vincoli imposti dal runtime attendono una revisione dell'ambito prima di ottenere asserzioni di registro di prima classe; la loro applicazione in fase di esecuzione non viene influenzata.
• L'ospitato API di convalida attualmente espone il livello dello schema; il livello di vincolo semantico qui descritto viene fornito con una versione successiva dell'API.

Appendice: riferimenti appuntati

• Fonti OSCAL: usnistgov/OSCAL @ 21403b4ad2f162ef1201e5ee70e8b93f254f51ac (v1.2.2) – Metaschemi, schemi JSON, bozza di specifiche di risoluzione del profilo
• Versioni OSCAL supportate: 1.1.2, 1.1.3, 1.2.1, 1.2.2 (target semantico: 1.2.2)
• Documentazione del modello: https://pages.nist.gov/OSCAL/
• Comparatore: Java OSCAL CLI 3.2.0 / liboscal-java 7.2.0 (binding OSCAL 1.2.1)
• Accettazione leggibile dalla macchina: validation/requirements.json (42 requisiti / 93 asserzioni), validation/capabilities.json (22 contratti di capacità), validation/completeness-closure.json (348 occorrenze), validation/scope-lock.json
• Verifica: oltre 1.000 test; pnpm verify (controllo del tipo → test → 13 porte degli artefatti generati → build → controlli del pacchetto → fumo)