Walidator

Przygotowanie prywatne: Opisany tutaj walidator jest dostarczany wewnątrz secani/oscal zestaw narzędzi, który pozostaje prywatny, dopóki jest przygotowany na open source. Wszystkie poniższe liczby, cudzysłowy i lokalizatory pochodzą z rejestru czytelnego maszynowo w zestawie narzędzi validation/ katalogu i można je ponownie zweryfikować za pośrednictwem pnpm verify.

Streszczenie

Zestaw narzędzi OSCAL firmy Secani sprawdza dokumenty NIST OSCAL pod kątem tego, co faktycznie stwierdzają przypięte źródła NIST – a nie tego, co dzieje się z jakąkolwiek implementacją referencyjną. Osiąga pełną parzystość możliwości z powierzchnią Java OSCAL CLI 3.2.0, a następnie przechodzi obok niej na cztery sposoby, których stos Java nie próbuje:

1. Sprawdzony maszynowo dowód kompletności: każde z 348 wystąpień ograniczeń możliwych do wykrycia w ośmiu głównych metaschemach OSCAL 1.2.2 jest indywidualnie uzgadniane – sprawdzone, czy jest egzekwowane, czy jest objęte schematem, czy też wyraźnie wykluczone z pisemnym uzasadnieniem. Zero nie zostało uwzględnione.
2. Natywna semantyka OSCAL 1.2.2 z obsługą wielu wydań (1.1.2, 1.1.3, 1.2.1, 1.2.2), gdzie Java CLI 3.2.0 osadza powiązania OSCAL 1.2.1 i może przetwarzać dokumenty 1.2.2 tylko w oparciu o kompatybilność.
3. Weryfikacja przepływu dokumentów między dokumentami – rozwiązywanie i sprawdzanie wykresu referencyjnego w ramach SSP, planów oceny, wyników oceny oraz POA&M – co jest całkowicie poza powierzchnią walidacji Java CLI.
4. Jedna baza kodu TypeScript, która działa wszędzie, gdzie znajdują się dokumenty: te same prekompilowane walidatory działają w przeglądarce, w bezserwerowych trasach API, w interfejsie CLI i na zapleczu – nigdzie nie ma JVM.

Proces ten ujawnił także defekty w samych źródłach NIST (patrz Znajdowanie błędów – w obie strony), czego można się spodziewać po – i co jest najmocniejszym dowodem – weryfikacji na poziomie wystąpienia.

Model władzy: źródła ponad wdrożeniami

Obowiązująca zasada zakresu projektu:

Źródło NIST OSCAL jest autorytetem. Java jest narzędziem porównującym kompatybilność i dowodem wdrożenia, a nie autorytetem.

Konkretnie, każde roszczenie semantyczne jest przypięte do bajtów:

• Źródło nadrzędne: usnistgov/OSCAL, tag v1.2.2, commit 21403b4ad2f162ef1201e5ee70e8b93f254f51ac — osiem głównych modułów Metaschema (katalog, profil, definicja komponentu, SSP, plan oceny, wyniki oceny, POA&M i mapowanie), ich współdzielone importy (metadane, elementy wspólne dla mechanizmów kontrolnych, wdrożeń, ocen i mapowania) oraz zewnętrzne encje ograniczeń. Wszystkie pliki są buforowane bajt po bajcie i przypięte skrótami SHA-256.
• Rozdzielczość profilu: wersja robocza specyfikacji NIST src/specifications/profile-resolution/profile-resolution-specml.xml. Ponieważ jest to projekt/WIP, jego wymagania są wdrażane za jawną możliwością i nigdy nie są po cichu uwzględniane w zwykłej walidacji.
• Komparator: Java OSCAL CLI 3.2.0 z liboscal-Java 7.2.0, który zawiera powiązania OSCAL 1.2.1. Dowody porównawcze są rejestrowane za pomocą lokalizatorów dokładnych zdarzeń; odniesienia bez bajtów w pamięci podręcznej i dokładnych lokalizatorów są oznaczone jako niekwalifikowana kontrola źródła i nie mogą zamknąć bramy pochodzenia.

To jest odwrócenie, które ma znaczenie: większość narzędzi traktuje implementację referencyjną jako podstawową prawdę. Źródła standardu traktujemy jako podstawową prawdę, a implementację referencyjną jako świadectwo do sprawdzenia.

Przykład – jak wygląda roszczenie przypięte w lokalizatorze. W rejestrze nie jest napisane „popieramy weryfikację ról strony odpowiedzialnej”. Mówi: ograniczenie oscal-metadata-responsible-party-role-ids, źródło oscal_metadata_metaschema.xml@L400, plik źródłowy SHA-256 przypięty, wymuszony przez regułę META-002.a, potwierdzone przez nazwany test, którego skrót AST jest rejestrowany. Jeśli NIST zmieni tę linię, szpilka pęknie i roszczenie będzie musiało zostać ponownie rozpatrzone.

Zamknięcie kompletności: uwzględnienie każdego ograniczenia

Źródła Metaschema definiują ograniczenia (allowed-values, is-unique, matches, index, index-has-key, has-cardinality, expect) rozproszone w tysiącach wierszy XML. Walidator może twierdzić, że „obsługuje ograniczenia OSCAL”, a nikt nie jest w stanie sprawdzić, co to oznacza. Sprawiliśmy, że było to możliwe do sprawdzenia.

Zamknięcie kompletności inwentaryzuje leksykalnie 348 wystąpień ograniczeń na przypiętym wykresie modułu – w tym 17 wystąpień anonimowych i 8 wystąpień zachowanych w komentarzach źródłowych, ponieważ decyzja, że ​​się nie liczą, sama w sobie jest decyzją podlegającą przeglądowi. Tożsamość wystąpienia obejmuje ścieżkę i linię źródłową, więc powtarzające się identyfikatory ograniczeń nigdy się nie zawijają.

Każde zdarzenie musi trafić do dokładnie jednego zamkniętego segmentu dowodów:

Przykład – co oznacza w kodzie „dokładny dowód wystąpienia”. Każde udowodnione wystąpienie ma w zestawie testów następującą deklarację:

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",
      ]),
    });
  },
);

Test prowadzi prawdziwego oceniającego po minimalnym dokumencie i potwierdza, że ​​zostało ocenione dokładne wystąpienie źródłowe – plik, identyfikator ograniczenia, linia. Format dowodu jest celowo trudny do sfałszowania: kod TypeScript AST deklaracji jest weryfikowany (zadeklarowany temat musi zostać wykonany dokładnie raz; jego wynik musi wpłynąć do dokładnie jednego najwyższego poziomu expect), a deklaracja, jej akta i SHA-256 przejściowego zamknięcia importu są przypięte. Zmień osobę oceniającą, a każdy skrót dowodu zależnego stanie się nieaktualny, dopóki nie zostanie ponownie uzyskany mechanicznie. Test o zmienionej nazwie, ciało nie podlegające operacji lub zmutowany pomocnik automatycznie unieważniają dowód.

44 wykluczenia nie są przypadkowe: 5 wystąpień znajduje się w komentarzach XML w źródłach NIST (martwy tekst), 2 to defekty poprzedzające (patrz poniżej), 3 to udokumentowane elementy ograniczające model, a 34 to aktywne ograniczenia, które są domyślnie egzekwowane w czasie wykonywania, ale nie mieszczą się w zablokowanym inwentarzu 93 asercji rejestru badawczego – każde wykluczenie określa nazwę wygenerowany ewaluator, który to wymusza.

Z unresolved = 0, artefakt się odwraca exhaustiveRequirementClaimAllowed: true – flaga, którą generator oblicza na podstawie zliczeń segmentów, a nie zdanie zapisywane przez człowieka.

Rejestr wymagań: 40 z 42, z uczciwymi wymaganiami

Nad poziomem występowania znajduje się rejestr 42 wymagań badawczych (93 asercje atomowe) obejmujący routing schematu, semantykę metadanych, katalog/profile reguły, rozpoznawanie profili, rozpoznawanie między dokumentami i sprawdzanie przepływu pracy. 40 jest implemented; każde odwrócenie wymagało nazwanej ścieżki wykonawczej plus rzeczywista wartość dodatnia/negative testy. Dwie otwarte pozycje są zamierzonymi, udokumentowanymi zasobami:

• PRES-004 (mapowania identyfikatorów importu): wersja robocza specyfikacji mówi, że mapowanie ma pięć opcjonalnych podsekcji, ale definiuje tylko jedną konkretnie (mapping[].controls[{from,to}]), a przypięty profil 1.2.2 Metaschema definiuje nie mapping NA import w ogóle. Implementujemy kształt oparty na przykładach i zamykamy wszystko inne:

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

Twierdzenie o pełnej obsłudze mapowania oznaczałoby wynalezienie semantyki, której źródło nie zawiera.

• META-013 (równoważne alternatywne reprezentacje zasobów): źródło wymaga wielu rlink/base64 reprezentacje zasobu „zawierające równoważne informacje” bez operacyjnie definiującego równoważność (równość bajtów? równość semantyczna po konwersji formatu?). Egzekucja pozostaje wstrzymywana w oczekiwaniu na definicję, a nie na jej wymyślenie.

Co robi walidator, czego nie robi Java CLI 3.2.0

Natywna semantyka 1.2.2, routing dla wielu wydań

Java CLI 3.2.0 zawiera liboscal-Java 7.2.0 z powiązaniami OSCAL 1.2.1; niezmieniona analiza dokumentu 1.2.2 oznacza zgodność obserwacyjną, a nie walidację 1.2.2. Firma Secani dostarcza routing schematu uwzględniający wersję i prekompilowane walidatory dla 1.1.2, 1.1.3, 1.2.1 i 1.2.2, z wersją 1.2.2 jako semantycznym celem implementacji – i kończy się niepowodzeniem w przypadku wydań, których nie zakwalifikowała, zamiast cichej weryfikacji pod kątem niewłaściwej generacji.

Wygenerowana warstwa ograniczeń semantycznych

Zwykła (domyślnie włączona) warstwa semantyczna ocenia dla każdego dokumentu inwentarz przypiętych ograniczeń: wszystkie 200 aktywnych allowed-values wystąpienia (w tym cele osi potomka i cele z adresami flagowymi, takie jak action/@type), wszystkie 27 z zakresem is-unique wystąpienia, 24 z 25 aktywnych matches wystąpienia (25. jest wymuszane przez regułę dotyczącą metadanych), wygenerowane expect, has-cardinality, i plik lokalny index/index-has-key oceniających i metadanych/catalog/profile/SSP rodziny reguł semantycznych. Każda diagnostyka ma swoje pochodzenie NIST. To są dokładne dane wyjściowe środowiska wykonawczego dla katalogu, którego metadane action deklaruje "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"
}

Pole sourceId nie jest zwykłą etykietą — to klikalne odwołanie, przypięte do konkretnego commita i dokładnego wiersza Metaschema, który ustanawia daną regułę. Ta diagnostyka pokazuje również rzeczywistą różnicę: Java CLI 3.2.0 akceptuje dokładnie ten dokument zarówno w JSON, jak i XML, mimo że ograniczenie znajduje się w wierszu L877 Metaschema 1.2.1, którego powiązania wykorzystuje; zobacz potwierdzenie R4 poniżej.

Pełna rozdzielczość profilu zgodna z roboczą specyfikacją

resolve-profile implementuje projekt uchwały NIST od początku do końca – i kończy się niepowodzeniem, gdy projekt jest nieokreślony, a nie zgadywany:

$ 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'

Objęte: pozyskiwanie importu z cyklem/depth/byte budżety, wewnętrzne #uuid import, w tym dokumenty osadzone w base64, obejmują/exclude wybór z with-child-controls ekspansja, keep/use-first połączyć semantykę, as-is/custom/flat strukturyzacja, deterministyczne zastosowanie parametrów i zmian oraz materiał wyjściowy łączą się z dokładnymi zasadami porządkowania zawartymi w wersji roboczej (później duplikaty zastępują na późniejszej pozycji; keep=always bloki zasobów, nieoznaczona wymiana).

Finalizacja wyników ma miejsce w przypadku kilku subtelnych gwarancji: zadeklarowanych oscal-version wyniku jest przypisane do najwyższego obsługiwanego wydania tego samego głównego; klucze są emitowane w kanonicznej kolejności OSCAL; a rozwiązany katalog jest ponownie sprawdzany – ograniczenia schematu i semantyki – przed serializacją, więc nieprawidłowy wynik rozdzielczości jest odmową, a nie wyjściem. Interfejs Java CLI nie sprawdza tego na własnych wynikach: jego mechanizm rozpoznawania nazw napisze katalog, który następnie zostanie odrzucony przez jego własny moduł sprawdzania poprawności (potwierdzenie R6 poniżej).

Walidacja przepływu pracy między dokumentami (nie w środowisku Java)

To jest wyróżnik. Artefakty zgodności OSCAL tworzą wykres – wynik oceny importuje plan oceny, który importuje SSP, który importuje profil, który jest porównywany z katalogami – a dokumentacja modelu stwierdza relacje, których żaden schemat JSON nie może sprawdzić. Walidator wykresu dokumentu rozpoznaje te krawędzie i je weryfikuje.

Przykład. Dostawca SSP twierdzi, że wdraża kontrolę ac-99, ale linia bazowa, którą importuje, nigdy nie zapewnia takiej kontroli. Po włączeniu reguł interpretacji moduł sprawdzania poprawności wykresów rozpoznaje linię bazową poprzez potok pełnego rozdzielczości profilu aż do katalogów, oblicza wybrany zestaw kontrolny i emituje (dosłowny kształt problemu):

{
  "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"
}

Nawet tutaj zwróć uwagę na dyscyplinę pochodzenia: autorytet jest secani-policy według wersjonowanego źródła interpretacji – nie nist-metaschema – ponieważ ta kontrola jest naszą udokumentowaną interpretacją, a nie ograniczeniem maszynowym NIST-u. Z interfejsu CLI kontrole są dostępne za pośrednictwem oscal-cli validate --resolve-imports --interpretive SSP-003.b ssp.json (powtarzalne lub --interpretive all; --warnings-as-errors promuje ich do nieudanego wyjścia).

Pełna rodzina reguł, każda przypięta do kotwicy w źródłach:

Przykład – dokładne wdrożenie prozy. Uwaga Metaschematu POA&M brzmi:

„Należy zaimportować SSP oparty na OSCAL lub określić unikalny identyfikator systemowy. Obydwa mogą być obecne.” – oscal_poam_metaschema.xml @L58-60

POAM-001.a ostrzega tylko wtedy, gdy nie ma żadnego. Pin testowy, który zasila oba, pozostaje cichy – ponieważ wynalezienie wyłączności – lub źródło nie podaje, jest dokładnie tym rodzajem nadmiernej weryfikacji, której ten projekt odmawia.

Dwie decyzje projektowe są równie ważne jak kontrole:

• Uczciwość interpretacyjna. Te relacje są udokumentowane prozą, a nie ograniczeniami maszynowymi – co odkrywcze, stanowią własność planu oceny index-has-key dla tych identyfikatorów UUID istnieje w źródle NIST jedynie jako skomentowany „fałszywy przykład”. Zatem reguły są domyślnie wyłączone, emitują ostrzeżenia, nigdy nie powodują zmiany dokumentu na nieprawidłowy i działają tylko wtedy, gdy osoba wywołująca wyraźnie je nazwie.
• Zakres przypięty przed kodem. Notatka rejestracyjna każdej reguły rejestruje, w każdym polu referencyjnym, udokumentowany zakres rozdzielczości i lokalizator – oraz to, co zostało wykluczone z nazwy. subject-uuid, na przykład jest udokumentowane jako rozwiązujące „każdy plik importowany bezpośrednio lub pośrednio” (@L652-654) - przechodnio między dokumentami - więc jest wyraźnie poza zakresem, a nie w połowie zaimplementowane.

Powierzchnia CLI: parzystość plus

Wszystkie 22 funkcje Java CLI dostępne w środowisku OSCAL są objęte obserwowalnymi umowami akceptacji (polecenie, opcje, dane wejściowe, sukces/failure wyjście, kody wyjścia): zatwierdź/convert poprzez JSON/XML/YAML, resolve-profile, list-allowed-values, deterministyczny SARIF (--sarif-include-pass, --sarif-timing), --threads podział pracowniczy z kanoniczną kolejnością wyników, metapath/xpath/jsonpointer renderowanie ścieżki, aliasy poleceń modelu, uzupełnianie powłoki. Na górze: --prune, --interpretive, eksport schematu z przypiętą wersją oraz interfejs API diagnostyki programistycznej.

Dlaczego TypeScript

1. Jeden artefakt, w każdym środowisku wykonawczym. Walidatorami są samodzielne, prekompilowane moduły AJV – zwykły generowany JavaScript, bez kompilacji schematu w czasie wykonywania, bez refleksji, bez interpretera Metaschema. Identyczna ścieżka kodu działa w przeglądarce, w bezserwerowych trasach API, w węźle (CLI) i wewnątrz zaplecza. Stos Java wymagałby maszyny JVM w każdej z tych lokalizacji lub portu stratnego.

2. Na platformie znajdują się dokumenty. Produktem Secani jest platforma internetowa; jego interfejs API walidacji, środowisko autorskie i serwer MCP korzystają z zestawu narzędzi jako biblioteki wpisywanej w procesie:

   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 }

Żadnego podprocesu IPC w stosunku do pliku binarnego Java, żadnego kontenera bocznego, żadnej maszyny JVM zimnego startu. 3. Determinizm jako cecha. Wstępnie skompilowane walidatory + wygenerowane oceny + kanoniczna kolejność kluczy sprawiają, że wyniki są stabilne pod względem bajtów – co pozwala systemowi dowodowemu przede wszystkim przypinać skróty do zachowania. 4. Dystrybucja. Pakiet maszynowy z dedykowanymi punktami wejścia (., ./browser, ./versioned, ./diagnostics) dociera do ekosystemu, w którym faktycznie tworzone są interfejsy użytkownika zapewniające zgodność. 5. Bezpieczeństwo typów w stosunku do modelu. Wygenerowane mapy modeli sprawiają, że „to ograniczenie dotyczy flagi, a nie elementu” i jest właściwością sprawdzalną statycznie – z testem ochronnym potwierdzającym brak flagi/element kolizja nazw występuje we wszystkich 1011 kształtach węzłów przypiętego modelu.

To, czego TypeScript nie nam kupił, to zwolnienie z dowodu: zamknięcie kompletności istnieje dokładnie tak, że wybór języka jest poparty dowodami na poziomie wystąpienia, a nie twierdzeniami dotyczącymi doświadczenia programistów.

Znajdowanie błędów – w obie strony

Weryfikacja na poziomie wystąpienia wykazała rzeczywiste defekty po obu stronach, co jest najmocniejszym argumentem na rzecz skuteczności tej metodologii.

W naszym własnym ewaluatorze (znalezionym przez bramkę zamykającą). Dwa ograniczenia metadanych dotyczą flag (atrybutów), a nie elementów potomnych – dozwolone wartości action/@system I action/@type (oscal_metadata_metaschema.xml @L874, @L877). Kompilowały się one z obsługiwanym inwentarzem, ale nigdy nie zostały uruchomione: osoba przechadzająca się po ścieżce rozwiązała kroki podrzędne tylko względem elementów modelu, więc oba ograniczenia po cichu niczego nie oceniały. Brama zamykająca odmówiła przyjęcia dla nich dowodów i dlatego pojawił się błąd. Naprawiono prawidłową rozdzielczość kroku flagi; statyczne przejście po wykresie definicji wykazało, że miało to wpływ dokładnie na te dwa zdarzenia.

W naszym własnym ewaluatorze (znaleziono na podstawie przebiegu różnicowego na żywo – oba ustalone tego samego dnia). Po pierwsze, index osoba oceniająca potraktowała brakującą wartość pola klucza jako błąd, który odrzucił każdy katalog zawierający a prop bez uuid – w tym własny katalog NIST SP 800-53 rev5 (20 zgłoszonych błędów; Java 3.2.0 to akceptuje). Specyfikacja Metaschema wyraźnie stwierdza, że ​​brakująca wartość pola klucza daje klucz indeksu o wartości null, a nie naruszenie; 800-53 sprawdza teraz czystość. Po drugie, słownictwo OSCAL dotyczące typu działania pozostało niezmienne nawet wtedy, gdy action/@system zadeklarował niestandardowy URI – co jest sprzeczne z uwagami NIST-u, że @system „zapewnia sposób na segmentację przestrzeni wartości dla type„na organizację. Obie poprawki zostały dostarczone z testami regresyjnymi i ponownie uzyskanymi skrótami dowodów.

W źródłach NIST:

• Osierocone ograniczenie. oscal_mapping-common_metaschema.xml @L657 ogranicza flagę zdefiniowaną w @L652 – do której nikt się nigdy nie odwołuje flag ref. Żaden węzeł modelowy go nie przenosi; ograniczenie jest niespełnialne dla żadnego dokumentu, który może istnieć.
• Orzeczenie niemożliwe. oscal_implementation-common_metaschema.xml @L567 ogranicza nazwy właściwości w ramach a @type orzekać na inventory-item - Ale inventory-item deklaruje, że nie type flaga (jej rodzeństwo asset-id flaga sama w sobie jest skomentowana w @L456-461). Predykat nigdy nie może się zgadzać.
• Ograniczenia występujące w komentarzach. Pięć wystąpień – w tym a with-child-controls wartościuj słownictwo w profilu Metaschema – istnieje tylko w blokach komentarzy: tekst, który czytelnik leksykalny znajdzie, ale skompilowany schemat nigdy go nie wymusza.

Każdy jest zapisywany jako excluded-with-rationale z dokładnym lokalizatorem – możliwym do sprawdzenia i raportowanym wcześniej: usnistgov/OSCAL#2254 (osierocona flaga), #2255 (orzeczenie niemożliwe), #2256 (ograniczenia w komentarzach). Lukę w egzekwowaniu flag w narzędziach referencyjnych podaje się jako metaschema-framework/oscal-cli#279.

Bieg różnicowy na żywo: wpływy, w obu kierunkach

18.07.2026 zamknęliśmy lukę pomiędzy twierdzeniami komparatora sprawdzonego pod kątem źródła a wykonanymi dowodami: Java OSCAL CLI 3.2.0 został pobrany z Maven Central, zweryfikowany bajtowo względem przypiętego do rejestru SHA-256/SHA-512, i przeglądaj stworzoną rodzinę osprzętu, której dokumenty bazowe sprawdzają się czysto w obu łańcuchach narzędzi – więc każdą różnicę można przypisać pojedynczej wprowadzonej zmianie. Wbudowane zatwierdzenie OSCAL (26df0501) to zatwierdzenie wydania łatki 1.2.1, potwierdzające lukę w powiązaniach w czasie wykonywania. Pełne transkrypcje, terminy i kody wyjścia są rejestrowane na rachunkach różnicowych obok rejestru.

Trzy wzorce, szczerze rozdzielone: ​​R1–R3 to czyste różnice w przestarzałych powiązaniach – wersja 1.2.2 zmieniła dokładnie dwa ograniczenia poza nierównościami wersji, oba w modelu SSP, a Java znajduje się po złej stronie wszystkich trzech obserwowalnych zachowań (jedno fałszywie ujemne, dwa fałszywie dodatnie, w jednym z nich błędny ze względu na brak opcjonalnego pola). R4 to luka w egzekwowaniu niezależna od odchylenia wersji: tekst ograniczenia jest identyczny pod względem bajtów w źródłach osadzonych w Javie, a klasa, której dotyczy problem, jest w pełni zmapowana: mechaniczne wyliczenie na podstawie przypiętych zasobów pokazuje dokładnie 2 z 200 aktywnych flag docelowych wystąpień dozwolonych wartości; jedynym członkiem o klasie błędów jest ten przetestowany na żywo, więc nie ma nieprzetestowanych reszta istnieje. R5 to luka w możliwościach, a nie wada – a nasza kontrola pozostaje ostrzeżeniem, na które się zgodziliśmy, ponieważ źródłem jest proza, a nie ograniczenia maszyny. R6 i R7 jako pierwsze przecięły nam drogę i zostały naprawione tego samego dnia; pozostają w tabeli, ponieważ wiązka mechanizmu różnicowego, która zawsze znajduje tylko błędy drugiej strony, nie jest wiązką.

Czego świadomie nie twierdzimy

• Specyfikacja rozdzielczości profilu jest wersja robocza; Zachowanie rodziny PRES jest zależne od funkcji, a ograniczenia na poziomie OSTRZEŻENIA NIST pozostają ostrzeżeniami.
• Reguły przepływu pracy są interpretacjami udokumentowanych relacji, domyślnie oznaczonymi jako takie.
• Dowody porównawcze rejestrów są oznaczone jako „sprawdzone u źródła”; przebieg różnicowy na żywo uzupełnia go wykonanymi, przypiętymi do hash pokwitowaniami, ale nie podnosi po cichu poziomu dowodów w rejestrze – złożenie transkryptów do formalnej bramki kwalifikacyjnej jest śledzone osobno.
• 34 ograniczenia narzucone w czasie wykonywania oczekują na przegląd zakresu, zanim uzyskają pierwszorzędne potwierdzenia w rejestrze; nie ma to wpływu na egzekwowanie ich w czasie wykonywania.
• Gospodarzem API walidacyjne obecnie eksponuje poziom schematu; Opisana tutaj warstwa ograniczeń semantycznych jest dostarczana z późniejszą wersją interfejsu API.

Dodatek: przypięte odniesienia

• Źródła OSCAL: usnistgov/OSCAL @ 21403b4ad2f162ef1201e5ee70e8b93f254f51ac (v1.2.2) – Metaschematy, schematy JSON, specyfikacja robocza dotycząca rozdzielczości profili
• Obsługiwane wersje OSCAL: 1.1.2, 1.1.3, 1.2.1, 1.2.2 (cel semantyczny: 1.2.2)
• Dokumentacja modelu: https://pages.nist.gov/OSCAL/
• Komparator: Java OSCAL CLI 3.2.0 / liboscal-Java 7.2.0 (powiązania OSCAL 1.2.1)
• Akceptacja do odczytu maszynowego: validation/requirements.json (42 wymagania / 93 twierdzenia), validation/capabilities.json (22 umowy dotyczące zdolności), validation/completeness-closure.json (348 wystąpień), validation/scope-lock.json
• Weryfikacja: ponad 1000 testów; pnpm verify (kontrola typu → testy → 13 bramek wygenerowanych artefaktów → kompilacja → sprawdzanie pakietów → dym)