walkthrough-nist-ssp.json

{
  "182f55f80a20d69651a02e76030612fa51967de32d587b033842cf8135d1bb70": {
    "input_tokens": 1798,
    "model": "claude-sonnet-4-6",
    "output_tokens": 1748,
    "provider": "bedrock",
    "stop_reason": "end_turn",
    "text": "```json\n{\n  \"refused\": false,\n  \"refusal\": \"\",\n  \"overview\": \"The report contains five groups of findings. One imported document is missing (G1), which directly causes sixteen cross-reference findings to be unresolvable (G5); fixing G1 first will settle most of G5 in a subsequent run. A version mismatch (G2) means every finding was judged against OSCAL 1.2.3 even though the document declares 1.2.2, so some rules may differ from what the document was written against. The remaining groups (G3, G4) record constraints and patterns the tool could not evaluate at all — they are neither passes nor failures and require attention after the structural issues are resolved.\",\n  \"steps\": [\n    {\n      \"title\": \"Supply the missing imported profile (G1 / F22)\",\n      \"labels\": [\"G1\", \"F22\"],\n      \"text\": \"The tool recommends starting here because this is the root blocker for the rest of the report. F22 reports that the href value #b78aa3ec-915d-475b-8097-46813fae1825 in /system-security-plan/import-profile/href points to a document that was not supplied to the validator. The tool notes: 'Identifiers it declares are outside the effective data model this run could see, so references into it are reported as unresolvable.' Until the referenced catalog or profile is provided alongside this SSP in the same validation run, the sixteen findings in G5 cannot be settled. Locate the correct source file for that href and include it in the next validation run. If the href is itself incorrect, update it to point to the intended profile before rerunning.\"\n    },\n    {\n      \"title\": \"Acknowledge the OSCAL version difference and decide whether to upgrade (G2 / F23)\",\n      \"labels\": [\"G2\", \"F23\"],\n      \"text\": \"F23 warns that the document declares oscal-version 1.2.2 at /system-security-plan/metadata/oscal-version, but all findings — including those in G1, G3, G4, and G5 — were produced against the vendored OSCAL 1.2.3 schema and constraint layer (issue #8). A rule present in 1.2.3 may not exist in 1.2.2, or may behave differently. You should either update the document to conform to OSCAL 1.2.3 and change the declared oscal-version field accordingly, or confirm with your toolchain owner which version is authoritative. Until the declared version matches the version the validator uses, every finding carries the caveat that the rule applied may differ from the rule that governs the declared version.\"\n    },\n    {\n      \"title\": \"Revisit the unresolvable control and parameter references after supplying the profile (G5 / F6 – F8 and the 13 additional findings)\",\n      \"labels\": [\"G5\", \"F6\", \"F7\", \"F8\"],\n      \"text\": \"All sixteen findings in G5 are marked UNVERIFIABLE because the imported profile named in F22 was not supplied. For example, F6 reports that control-id au-1 at /system-security-plan/control-implementation/implemented-requirements/0/control-id 'names a control, and no such identifier is declared in the documents supplied'; F7 reports that statement-id au-1_smt 'names a control statement, which is a part, and no such identifier is declared in the documents supplied'; F8 reports that param-id au-1_prm_1 'names a parameter, and no such identifier is declared in the documents supplied.' All three explicitly note that '1 imported document(s) named by this document were not supplied (#b78aa3ec…)'. After completing the step for G1, rerun the validator. If the profile is then found and its identifiers resolve, these findings should clear. Any that remain after that run represent genuine reference mismatches that will need to be corrected in the document.\"\n    },\n    {\n      \"title\": \"Note the constraints the tool did not evaluate (G3)\",\n      \"labels\": [\"G3\", \"F2\", \"F3\", \"F4\"],\n      \"text\": \"G3 contains four UNVERIFIABLE findings that record NIST-published constraints the tool could not evaluate. F2 notes 200 allowed-values constraints were not evaluated, adding that 'most allowed-value sets declare allow-other, so a value outside them is not necessarily an error.' F3 notes 12 expect constraints were not evaluated because 'the test is a Metapath expression, which this tool does not implement.' F4 notes 1 index constraint was not evaluated because 'their target expressions are outside the Metapath subset this tool parses.' The fourth finding (summarised as '1 more in G3') follows the same pattern. These are not passes; they simply record the limits of this tool's evaluation engine. No action can make this tool evaluate them. If full constraint coverage is required, a validator that implements complete Metapath evaluation must be used separately.\"\n    },\n    {\n      \"title\": \"Note the unchecked TokenDatatype pattern values (G4 / F1)\",\n      \"labels\": [\"G4\", \"F1\"],\n      \"text\": \"F1 reports that 59 values declared as TokenDatatype were not checked against the pattern ^(\\\\p{L}|_)(\\\\p{L}|\\\\p{N}|[.\\\\-_])*$ 'because that pattern uses regular-expression syntax this tool does not implement.' This is also UNVERIFIABLE — neither a pass nor a failure. If your toolchain requires that all TokenDatatype values are confirmed to match the NIST-specified pattern, a validator with full Unicode regular-expression support must be used in addition to this tool.\"\n    }\n  ],\n  \"closing\": \"After supplying the missing profile (G1/F22) and rerunning the validator, most of G5 should resolve; G3 and G4 will remain UNVERIFIABLE because they reflect the limits of this tool's Metapath and regular-expression engines — 'UNVERIFIABLE' is explicitly neither a pass nor a fail, and those constraints must be checked with a fully capable validator before any structural conformance conclusion can be drawn.\"\n}\n```"
  }
}