Skip to content
ClearedStack

Tools · CLIN 0003 Cybersecurity & compliance

OSCAL Validator

Planned

Check OSCAL catalogs, profiles and system security plans against the schema, locally.

This tool is planned. There is nothing to open yet. What follows is the plan, and it can change before the tool ships. The guide below covers the same job by hand in the meantime. Jump to the full specification.

What it will do

Open an OSCAL catalog, profile, component definition or system security plan. The tool checks that the file is well-formed and that it matches NIST’s schema for the OSCAL version named in its metadata, and lists each problem with its location. It cannot tell you whether the content describes your system accurately.

You bring

  • An OSCAL file

You get

  • Whether the file is well-formed and schema-valid
  • Each error, with where in the file it is

Built from

Only material the government has officially released to the public. Where the rules live shows how to find and cite each one.

Do it by hand today

  • STIGs, OSCAL and SBOMs · Checking an OSCAL fileThree machine-readable formats that security compliance work runs on: what each one is, what is inside the file and how to check one.

True of every tool

Free and open source.
No paid tier, no ads, and the code is public.
Runs in your browser.
What you type or open is not sent anywhere.
No tracking.
No accounts, cookies or analytics.
Shows its sources.
Each result names the rule it rests on, so you can check it.
Says what it does not do.
It is an aid for your own work, not professional advice.

What happens to what you type shows how to confirm this yourself, and Check a tool’s answer is the method for verifying a result.

Want it sooner?

Requests decide what is built first. Say what you would use it for, and what you do by hand today.

Ask by emailOpen an issue on GitHub

Issues are public. Leave out real contract data, real rates and anything controlled. How to write a useful request.

Specification · draft

How it is meant to work, in detail

The inputs, the logic, the checks the tool has to pass and the worked examples it is tested against. It is a draft, and the tool is built from it, so it can change until the tool ships.

3 min readLast revised November 2026Source of this specification

Overview & Role#

The OSCAL Validator (slug: oscal-validator, CLIN 0003 — Cybersecurity & compliance, template family validator) is a static, browser-only tool that checks Open Security Controls Assessment Language (OSCAL) JSON documents locally without sending system security plans or assessment data to a remote server. It separates validation into three distinct stages—well-formedness, official NIST schema conformance, and internal reference integrity—so engineers know exactly why a file passes or fails.

Scope boundaries:

  • Validates OSCAL JSON documents locally against bundled NIST OSCAL JSON schemas.
  • Does not fetch remote profiles, catalogs, or external href targets over the network (blocked by connect-src 'self').
  • Does not determine whether an OSCAL System Security Plan (SSP) accurately describes a real-world system; a file can be schema-valid and still factually wrong.

Governing Regulations & Sources#

  • NIST OSCAL (Open Security Controls Assessment Language) at pages.nist.gov/OSCAL/: Official JSON Schemas and model definitions across all three OSCAL layers:
    • Controls layer: catalog, profile
    • Implementation layer: component-definition, system-security-plan
    • Assessment layer: assessment-plan, assessment-results, plan-of-action-and-milestones
  • RFC 8259 (JSON Data Interchange Format) and JSON Schema specifications used by the bundled NIST OSCAL schema releases.

Inputs, Processing Logic & Outputs#

Inputs

  • OSCAL document: Local .json file upload (FileReader) or pasted JSON text.
  • Bundled sample fixtures: Built-in synthetic catalog, profile, and system-security-plan samples for offline testing.
  • Optional version override: Defaults to auto-detecting metadata.oscal-version from the document; allows selecting from bundled NIST OSCAL schema versions (e.g., 1.0.4, 1.1.2, 1.1.3).

Deterministic Three-Stage Processing Logic

  1. Stage 1 — Well-formedness check:
    • Parses input with JSON.parse().
    • If parsing fails, reports the syntax error message and position and halts Stages 2 and 3.
  2. Stage 2 — Schema-valid check:
    • Detects the root OSCAL model property (catalog, profile, component-definition, system-security-plan, assessment-plan, assessment-results, or plan-of-action-and-milestones) and reads metadata.oscal-version.
    • Selects the exact bundled NIST OSCAL JSON Schema for that oscal-version. If the version is not bundled, fails closed with an explicit unsupported-version error rather than validating against a mismatched schema.
    • Runs the deterministic schema validator and collects every violation with its JSON Pointer path (e.g., #/system-security-plan/metadata/last-modified) and schema keyword.
  3. Stage 3 — Reference & meaningful integrity checks:
    • Verifies that uuid fields match UUID syntax and checks for duplicate UUIDs within the document.
    • Verifies that internal fragment references (#uuid) in import-profile, link, or rlink resolve to an existing uuid in back-matter.resources or the document's own elements.
    • Flags external http:// or https:// href references as info: external reference not fetched offline so users know external links were not resolved.
    • Checks presence of key metadata fields (title, last-modified, version, oscal-version).

Outputs

  • Three-stage status summary: Pass/Fail/Skipped badges for Stage 1 (Well-Formed), Stage 2 (Schema-Valid), and Stage 3 (References Checked).
  • Detected document header: Model type, oscal-version, document uuid, and metadata.title.
  • Diagnostics table: Severity (error | warning | info), Stage (1 | 2 | 3), JSON Pointer path, and message.
  • Exportable validation report: Downloadable JSON or Markdown summary generated client-side.

Clean-Room & 5-Condition QA Requirements#

  • Browser-only execution: JSON parsing, schema validation, and reference checks run entirely in browser memory with zero backend APIs.
  • Strict Content Security Policy: Enforces default-src 'self', connect-src 'self', and form-action 'none' so sensitive SSPs, assessment results, and POA&Ms never leave the user's workstation.
  • Zero tracking or accounts: Zero login walls, analytics, cookies, or remote schema fetches.
  • Offline operation: Official NIST OSCAL JSON schemas and synthetic test fixtures are bundled inside the static repository; validation works with the network disconnected.
  • Clean-room & data hygiene: Bundled samples are synthetic/public only. Reminds users that real SSPs and assessment results may be CUI and should only be opened on approved systems (linking to What happens to what you type), and includes MIT LICENSE and NIST OSCAL citations.

Worked Example & Verification#

Worked Example (Minimal Synthetic system-security-plan):

  • Valid fixture: A synthetic system-security-plan JSON with oscal-version: "1.1.2", valid UUIDv4 identifiers, required metadata, import-profile, system-characteristics, system-implementation, and control-implementation → passes Stage 1, Stage 2, and Stage 3 with 0 errors.
  • Stage 1 failure: Trailing comma added to metadata → Stage 1 fails with JSON syntax error; Stages 2 and 3 are marked skipped.
  • Stage 2 failure: metadata.last-modified removed → Stage 1 passes; Stage 2 fails with missing required property last-modified at #/system-security-plan/metadata.
  • Stage 3 failure/warning: import-profile.href set to #00000000-0000-4000-8000-000000000099 when no matching resource exists → Stage 1 and Stage 2 pass; Stage 3 reports an unresolved internal reference error.