OSCAL integration

mjEdit supports the full OSCAL v1.2.2 standard with specialized editors for each document type.

All 8 OSCAL document types

The OOP principle: components as classes, inventory as instances

mjEdit intuitively maps the OSCAL architecture – based on object-oriented programming:

Component = Class (Blueprint)

"Apache HTTP Server" – Typ: Software, Beschreibung: Webserver

Inventory item = instance (specific asset)

"Apache 2.4.58 auf Server web-01" – IP: 192.168.1.10, FQDN: web-01.example.com

An inventory item dialog opens in the SSP tab, and the associated software/hardware components are linked via multi-select in the “Components” tab. mjEdit automatically creates the implemented-components reference with component-uuid.

Automatic OSCAL document chains

You don’t have to create documents individually. mjEdit can automatically generate the entire compliance chain:

( Catalog (BSI/NIST) → Profile ) → System Security Plan → Assessment Plan → Assessment Results → POA&M

Each step automatically takes UUID references, sets metadata (title, version, last-modified) correctly and validates against the OSCAL v1.2.2 schema.

Evidence workflow with status tracking: SSP → AP → AR

Proof that a planned document has actually been checked is the core of all auditability - and the most error-prone point in practice. mjEdit makes this workflow explicitly visible: Three prominent tree nodes connect the system security plan, the assessment plan and the assessment results into a seamless chain of evidence.

Three documents - three dedicated tree nodes

When opening an assessment result, mjEdit automatically loads the linked assessment plan via import-ap.href and compares the planned evidence from the AP-back-matter against all observation.relevant-evidence[].href anchors in the AR. The result is immediately visible: How many of the X planned documents have already been documented?

One-click observation for outstanding receipts

Instead of setting up an observation manually, all you need to do is right-click on a ⏳ node in the AR tab:

“📋Create observation for this evidence”

mjEdit creates a complete, OSCAL v1.2.2 compliant observation - with UUID, collected timestamp, methods: ["EXAMINE"] and the schema compliant anchor:

"relevant-evidence": [
  {
    "href": "#<uuid-der-ap-ressource>",
    "description": "Beleg aus AP-Planung"
  }
]

Optionally, mjEdit sets props[name=evidence-source, value=ap] as the origin marker.

Why is this so valuable?

• No more gaps: The audit team can immediately see which of the planned documents have not yet been documented - without manual lists or tables.
• Automatic OSCAL compliance: The generated observations follow the NIST OSCAL v1.2.2 schema exactly - relevant-evidence.href as a #uuid anchor is schema-compliant and can be processed across tools.- Complete traceability: The chain SSP (requirements) → AP (planning) → AR (evidence) can be derived directly from the file structure - without a proprietary database.
• Cross-Document-Linking: mjEdit automatically reloads the AP when opening the AR and shows the current test bench in real time.

Test scope: Assessment Subjects with include-all

In the assessment plan and the assessment results, OSCAL determines which assets will be examined - the so-called assessment subjects (examination objects). Each audit object has a type (component, location, inventory-item, user) and defines its scope via two complementary strategies:

Regardless of the strategy chosen, individual UUIDs can be explicitly excluded using exclude-subjects (in the dialog: “Excluded subjects”).

What “Include All” does

If the option is active, mjEdit writes include-all: {} to the OSCAL file. This means:

• No manual follow-up: New components that are later created in the SSP are automatically included in the scope of testing - without opening the AP again.
• Specific exceptions are still possible: Decommissioned systems or out-of-scope areas are removed from “Excluded Subjects” via UUID.
• Auditable: The decision “all except X” is explicitly documented in the OSCAL file – comprehensible for auditors and tools.

If the option not is active, include-subjects appears instead with the explicitly selected UUIDs - useful for targeted partial tests (e.g. only a specific subsystem or a single location).

Advantages according to OSCAL standard

• Scalability: For large infrastructures (100+ components), include-all saves you from manually listing each UUID - the scope automatically grows with the system.
• Consistency: SSP and AP remain synchronous without follow-up maintenance. No risk of forgotten assets within the scope of the check.
• Cross-tool interoperability: include-all is a standardized OSCAL v1.2.2 construct - any compliant tool (OSCAL CLI, IBM Trestle, custom pipelines) can correctly evaluate the scope.
• Machine-readable exclusions: Instead of free text comments like “everyone except server X”, the file contains UUID references - validatable, versionable and auditable.

Batch generation for server landscapes via AI using the MCP protocol

oscal_generate_batch_tailored_chain is used for a server landscape - e.g. B. from 8 servers – a complete document chain is generated per system:

• 8 servers → 8 subdirectories (named after system_id)
• 6 OSCAL documents each: Profile → Component Definition → SSP → Assessment Plan → Assessment Results → POA&M
• = 48 validated documents in one call

Per server (target) you can, among other things: define: system ID, name, description, platform/OS, server-specific control selection (tailoring), protection level (sensitivity_level), roles, parties, component definition, assessment actions as well as inventory_items with host name, FQDN, IPv4/IPv6 and MAC addresses. Common fields (shared_roles, shared_parties, shared_sensitivity_level) apply to all systems and can be overwritten per target.

Three-level schema validation

Automatic OSCAL document healing

OSCAL documents today arise from many sources: NIST examples, BSI converters, AI pipelines, legacy generators, or manual editing in any JSON editor. In practice, the result is schematic or outdated structures - e.g. E.g. forbidden fields like description at statement level in the SSP, missing mandatory fields like import-ap in the assessment result, datetime values ​​without a time zone suffix or NIST Pre-1.2.2 containers like system-interconnections.mjEdit solves this problem with a document type-specific, idempotent healing logic that is called automatically when opening and saving:

Why is this important?

• Lossless: Content is migrated, not deleted. Text from forbidden fields moves into semantically appropriate target structures.
• Idempotent: Opening and saving multiple times produces identical results.
• Consistent validation: Since healing runs on both open and save (and before any manual validation), the validator sees exactly what is later in the file.
• Statistics in the log: Each save operation logs how many fields were migrated (e.g. statement_descriptions_migrated: 3, legacy_system_interconnections_migrated: 2).
• Round trip capable: Migrated content will appear in the appropriate dialog the next time it is opened.

Recommendation for “inherited” OSCAL files: An OSCAL document from a third-party tool or an old inventory does not have to be laboriously schema-fixed manually. Open once in mjEdit, save once - done. The next time the schema is run it will be OSCAL v1.2.2 compliant.

Pre-installed compliance frameworks

• BSI IT-Grundschutz++ (2,128 controls)
• NIST SP 800-53 (468 controls)
• BSI criteria catalog C5 according to Christop Puppe (still in progress)
• BSI criteria catalog 200-x compendium 2023 according to Christop Puppe (still in progress)

Mapping Collection — Offline AI powered

The Mapping Tab is one of the outstanding unique selling points of mjEdit: Controls from two OSCAL documents (Source ↔ Target) are systematically mapped to one another - e.g. B. NIST SP 800-53 ↔ BSI IT-Grundschutz, C5 ↔ ISO 27001 or BSI 200-x Compendium 2023 ↔ BSI IT-Grundschutz++.

Why is this so valuable?

Manual mapping between two extensive control catalogs is one of the most time-consuming and error-prone tasks in compliance work:

• A complete mapping between e.g. B. NIST SP 800-53 (468 controls) and BSI IT-Grundschutz++ (2,128 controls) means in the worst case almost a million pair comparisons - reading, understanding, evaluating, documenting each comparison.
• Without tools, you can expect several person weeks to months per mapping project; With mjEdit + AI suggestions, the effort is reduced to a few days - the person only evaluates the AI ​​suggestions instead of reinventing the wheel.
• The result is machine-readable (OSCAL JSON), schema-validated, versionable and reusable for years - no more Excel graveyard.

How does AI work – and what does “offline” mean?

The AI ​​functions run fully locally in mjEdit. An open-source, multilingual Sentence Transformer model (paraphrase-multilingual-MiniLM-L12-v2) is used, which is loaded once onto the computer the first time it is called and then used offline.

Data protection first: No control text, no catalog and no mapping suggestion ever leaves the computer. No cloud, no API key, no token costs - so it can also be used for highly regulated areas (BSI, authorities, KRITIS).

Auto-suggest with four methods

mjEdit offers a button “Generate suggestions” in the mapping editor. The method can be set per run:

| Method | Procedure | When to use? || ———— | ——————————————————————————- | ——————————————————————————- | | syntactic | String/text similarity (SequenceMatcher via normalized titles + statements) | Very similar frameworks, identical language, familiar choice of words | | semantic | Comparison of multilingual vector embeddings (similarity in meaning) | Different choice of words, different languages ​​(DE/EN/FR/IT) | | functional | Functional similarity (intended effect of a control, not the formulation) | Structurally very different frameworks (e.g. NIST → BSI) | | auto | Cascade Semantic → Functional → Syntactic until a hit is above threshold | Standard for most projects – gets the best out of every pair |

Additionally:

• Auto-acceptance toggle: Suggestions above the configurable threshold (default 0.4) are accepted directly - the person only checks borderline cases.
• Cross-language: Source in German, Target in English? The embedding model natively supports cross-language semantics.
• Bulk operations, schema validation, Markdown export for reviews and reports.

Examples of mapping hits

Specific use case: BSI 200-x Compendium 2023 → BSI IT-Grundschutz++

Task: “How can the contents of the existing BSI-IT-Grundschutz Compendium 2023 be incorporated into the new Grundschutz++? Which contents of which modules should be incorporated into which practices of Grundschutz++ - and where do gaps arise?”

With mjEdit, this question can be answered in a clearly structured 9-step process:

1. Specify the task

Source = BSI 200-x Compendium 2023 (modules), Target = BSI IT-Grundschutz++ (practices). Specify the scope (e.g. only the blocks ORP.* and OPS.*), protection requirement classes and language orientation.

2. Crop source catalog

The complete 2023 compendium opens in mjEdit as an OSCAL catalog. Areas that should not be included in the comparison (e.g. outdated blocks) are marked using the catalog editor.

3. Create source profile → resolve → derive tailored catalog

• A source profile is created in the profile editor: include-controls for the relevant blocks, add modifications for comments/additions from your own organization.
• A resolved profile is created via Profile Resolution (all inheritances, tailoring rules and modifications have been evaluated).
• With one click, a tailored source catalog is exported as an independent catalog.json - the clean comparison basis for the mapping.

4. Crop target catalog

Similarly, the Grundschutz++ catalog (2,128 controls) is opened and filtered to the relevant scope of practices (e.g. only the practices that match the scope from step 1).

5. Create target profile → resolve → derive tailored catalog

Same as step 3, only for the target. The resolved Target profile ensures that comments, organization-specific parameters and additions end up neatly in the tailored target catalog.

6. Create mapping file

Datei → Neu → OSCAL Mapping Collection. The empty mapping collection gets two resource entries with relative href paths to the two tailored catalogs from steps 3 and 5.

7. Select source and target catalog in the mapping tabBoth catalogs are loaded in the mapping tab. mjEdit shows the source controls on the left, the target controls on the right, and the mapping table in the middle with columns for method, reason (matching-rationale), relationship (equivalent, subset-of, superset-of, intersects-with) and statement preview.

8. Automatic mapping

Select method auto, threshold e.g. E.g. set to 0.5, press “Generate suggestions”. mjEdit runs through the cascade Semantic → Functional → Syntactic for each source control and writes the best hit for each pair, including the score and method, into the table. With auto-acceptance activated, hits above threshold go directly to the mapping collection; everything below ends up in the review column.

At e.g. B. 250 source × 350 target controls, 87,500 pair evaluations are completed in a few minutes - an effort that would not be possible manually.

9. Use result – generate reports & follow-up artifacts

The following can be derived automatically from the finished mapping collection with a click:

• Resolved Profile (tailoring based on mapping)
• SSP proposal (System Security Plan with adopted implementations)
• Cross-Reference Report (Markdown/CSV: which source control covers which target control)
• Gap analysis (which target practices are not covered by any source → action required)
• Component definition stub (reusable component with mapping references)
• POA&M-Stub (an entry with suggested measures for each gap)

What benefits do the individual roles derive from the mapping?

In short: a manual Excel spreadsheet lasting several months becomes a reproducible, AI-supported, schema-validated workflow of just a few days - with testable follow-up artifacts for the entire compliance chain.