OSCAL Workbench is a local Windows application for turning structured security and compliance records into reviewable OSCAL documents. It helps you prepare source data, map it to an OSCAL model, validate relationships and schemas, repair missing information, inspect provenance, and export a saved result.
The 0.1.0 Windows prerelease is designed for one person working on one computer. It is useful for preparing OSCAL content and evidence workflows; it does not certify compliance, decide whether a control is effective, replace an assessor, or provide a shared compliance service.
Review before relying on results. Software and documentation are provided “as is” under the MIT License, without warranty. Check source data, mappings, generated OSCAL artifacts, evidence claims, AI suggestions, and monitoring findings independently before relying on or submitting them. See the full disclaimer; schema validation does not prove factual accuracy, control effectiveness, compliance, authorization, or government acceptance.
Download the latest prerelease from the GitHub Releases page. The asset is named OSCALWorkbench-0.1.0-windows-x64.zip.
- Extract the ZIP to a local folder.
- Keep the complete
OSCALWorkbenchfolder together. The executable needs its bundled libraries, reference pack, templates, examples, and documentation. - Start
OSCALWorkbench.exe. - The launcher opens the interface in your default browser. Keep the executable running while you work.
The portable build does not require a separate Python or Node.js installation. It serves the interface locally and keeps its default workspace beside the application. Choose a local folder for working data; avoid cloud-synchronized folders for the workspace and for browser downloads. This prerelease is a portable ZIP, not an installer, and it is unsigned.
Developers who want to run a checkout can follow the development quickstart. Packaged users can start with the steps above and skip Python setup.
Watch the 78-second narrated walkthrough with spoken narration and on-screen captions, or read the written walkthrough.
The repository includes a fictional Catalog example so you can see the whole review loop without using company data.
- Open Convert files, choose Catalog, and leave Rules only selected.
- Upload
templates/catalog.example.zip, or download the Catalog synthetic example from the Artifact library in the app. - Give the conversion a title and check the source roles. Keep the example classified as synthetic.
- Select Convert & validate.
- Read the Issues tab, then inspect the artifact preview and source references. A schema pass does not prove that the source claims are correct.
- If a field is missing, correct the source records or use Edit records and save a new revision. The app validates the revision again.
- Export the saved revision as JSON, YAML, XML, or a review ZIP. The ZIP contains the artifact, dependencies, validation and provenance records, the mapping recipe, a human-readable summary, and checksums. It does not include raw uploads or credentials.
The same flow applies to company records. Use a blank model template, supply the required fields, add exact dependency filenames, and review the result before using it elsewhere.
Choose the model that matches the job before organizing your files. The builder covers these OSCAL 1.2.3 models:
| Model | Use it for |
|---|---|
| Catalog | Requirements and control statements you author or maintain |
| Profile | Exact selection and tailoring of controls from referenced catalogs |
| Component Definition | Reusable implementation capabilities and control statements |
| System Security Plan | A system boundary, components, implementation narratives, and parameters |
| Assessment Plan | Planned assessment scope, subjects, activities, tasks, and dependencies |
| Assessment Results | Assessment runs, observations, evidence references, findings, and risks |
| Plan of Action & Milestones | Remediation items, linked risks or observations, and owners |
| Control Mapping | Reviewed relationships between source and target controls |
The supported-features guide explains the implemented subset and its limits. An existing OSCAL document can contain more of the standard than the tabular authoring templates expose.
Use the exact lowercase snake_case headers documented in the field guide. One CSV or TSV file represents one logical table. XLSX workbooks use the logical table name as the sheet name and must contain values with a header row. Keep identifiers as text, including identifiers with leading zeroes, and use ISO 8601 timestamps with a timezone.
The templates README explains the blank and synthetic ZIP and XLSX bundles. Each model has a .blank.zip for authoring and a .example.zip for a small fictional example. The examples README explains the developer fixtures and expected OSCAL outputs. For dependencies, use the exact filename in reference_sources.href and include that file in the upload or ZIP.
| Input | Supported handling |
|---|---|
| CSV / TSV | UTF-8, including an optional BOM; exact headers or an explicit mapping |
| XLSX | Named values-only data sheets; formulas and macros are rejected |
| JSON / YAML / JSONL | Named tables, arrays of row objects, or existing OSCAL documents |
| XML | Existing OSCAL through the bundled NIST converters and schemas |
| DOCX | Paragraph/table extraction for AI, or explicitly mapped tables for rules mode |
| Searchable PDF, TXT, Markdown, HTML | Bounded text extraction for AI-assisted review |
| ZIP | Safe bundles of supported files and OSCAL dependencies |
Scanned PDFs and image files do not have a local OCR or vision adapter. Parquet, legacy XLS, ODS, PPTX, and email archives need an approved CSV/XLSX or searchable-text export first. Limits include 25 MiB per file, 100 MiB per batch, 100,000 rows per logical table, and bounded archive, Office, and text expansion; see supported features and limits.
Rules mode is offline after the application is running. It builds from the fields and relationships you provide, checks implemented structural and consistency rules, and does not call an AI provider.
AI-assisted conversion is optional. Configure either Gemini or Azure OpenAI in Connections, choose a model or deployment, select the data policy, and explicitly authorize transmission for each AI conversion. Gemini's public-only policy is for public or synthetic records; nonpublic company records require an organization-approved provider configuration and permission. Azure supports API-key authentication and Microsoft Entra service principals. The provider receives selected source spans and tables plus the field dictionary; it has no database, browser, code-execution, or unrestricted URL access. Every proposal needs human review before export.
Snowflake is an optional read-only workflow for browsing visible databases, schemas, tables or views, selecting bounded columns, and importing a snapshot. Browser SSO, password with organization-required MFA, and RSA key-pair authentication are supported. Use a dedicated Snowflake role with only the required SELECT and warehouse privileges. The app does not accept arbitrary SQL and rejects a snapshot that exceeds the selected limit.
The Monitoring page evaluates an explicitly approved comparison against a control and assessment objective. It keeps satisfied, not-satisfied, unknown, stale, and out-of-scope records visible. Saved schedules collect snapshots only while the app is open; they are not an unattended Windows service. A generated Assessment Results input bundle still needs the actual Assessment Plan and dependency closure before normal conversion and review.
Every conversion has a saved revision. Use the Issues tab to find a field, source, row, and suggested remedy. Use Edit records for verified table corrections or supply missing metadata in the repair panel. AI repairs reuse the saved extracted tables and do not silently run a new provider call. Review the artifact, source references, validation scope, and dependency versions before export.
OSCAL is a machine-readable exchange format, not a certification. Read the NIST OSCAL overview, OSCAL model reference, and NIST continuous monitoring guidance alongside your organization's control, assessment, and evidence procedures.
Rules-only work can remain local and offline. On Windows, saved records and configuration use an encrypted local store whose key is protected with Windows DPAPI; API responses omit saved secrets. Browser downloads and exported OSCAL files are plaintext and should be handled under your normal retention and access controls. This is local protection, not an enterprise secrets vault or multi-user isolation.
The local parser is bounded by time, memory, size, and archive limits, but it is not a complete operating-system sandbox or malware scanner. Do not open untrusted exports in another tool without your normal security controls. Provider and Snowflake connections are opt-in network operations; credentials, source data, and private key files are never needed for a rules-only conversion.
See Security for the full boundary description and reporting guidance.
- The browser cannot connect: start the executable again and use the new launch window. The one-use local launch link expires after the session is established.
- A conversion needs information: open Issues, follow the file/table/row reference, and repair the source or saved revision. Empty cells are not treated as a pass, false, zero, or not-applicable decision.
- A dependency is missing: check that
reference_sources.hrefexactly matches the uploaded filename, including its extension. - AI conversion is unavailable: verify the provider endpoint, model or deployment, data policy, and explicit transmission consent. Provider tests use synthetic content but may consume quota.
- Snowflake browsing fails: verify the account identifier, authentication method, role privileges, warehouse usage, and network policy. Use a governed view when you need filtering or a stable population.
- A scheduled monitor does not run: the app must remain open, the interval is at least five minutes, and the selected authentication must be able to complete without an interactive prompt.
| Guide | What it covers |
|---|---|
| Quickstart | Packaged use, first conversion, optional connections, monitoring, and checkout setup |
| Field guide | Exact tables, headers, required values, joins, and relationships |
| Supported features | Implemented scope, formats, limits, and boundaries |
| Security | Local storage, parser boundaries, provider transmission, and Snowflake scope |
| Templates | Blank and synthetic CSV/XLSX/ZIP authoring bundles |
| Examples | Synthetic inputs and expected OSCAL outputs |
| Release verification | Current source and packaged verification evidence |
For a development checkout, install the Python requirements, run npm ci and npm run build in ui, then run the tests and launcher self-check described in Quickstart. The original implementation plan, data contract, architecture and security design, AI conversion specification, and research notes are historical approved design and research records. They are not the current feature list; use the guides above and the shipped templates for current behavior.
This project is released under the MIT License. See the third-party notices for dependency and NIST OSCAL reference-pack attribution information.