Funktionen

mjEdit vereint die wichtigsten Werkzeuge für die tägliche Arbeit in einer einzigen Oberfläche.

Was mjEdit von anderen JSON-Editoren unterscheidet

Eigenschaft	Standard-JSON-Editoren	mjEdit
OSCAL-Erkennung	Manuell	Automatisch – erkennt Dokumenttyp und öffnet spezialisierten Tab
Schema-Validierung	Generisch	OSCAL v1.2.2 Schemas vorinstalliert, Echtzeit-Validierung
KI-Integration	Keine	154 MCP-Tools für vollautomatisierte OSCAL-Workflows
Compliance-Daten	Nicht vorhanden	BSI Grundschutz (2.128 Controls), NIST 800-53 (468 Controls)
Dokumentketten	Nicht möglich	Ein Klick: Profil → SSP → AP → AR → POA&M
Inventar-Management	Nicht vorhanden	Komponenten (Klassen) ↔ Inventar (Instanzen)

Die Kernfunktionen

JSON-Editor

Syntax-Highlighting, Echtzeit-Validierung, Auto-Reparatur, Regex-Suche, Code-Faltung und intelligentes Performance-Management für Dateien ab 1 MB+.

qFORM-Formularsystem

JSON-Arrays werden automatisch als editierbare Formulare mit Textfeldern, Checkboxen, Dropdowns, Datumspickern und eingebetteten QC-Scripts in einer Python-Sandbox dargestellt.

Markdown-Editor

Split-View, GitHub Flavored Markdown, erweitertes Task-System (Prioritäten, Zuweisung, Zeiterfassung) sowie PDF- und HTML-Export.

PDF-Viewer

Annotationen (Highlighter, Notizen, Freihand), sichere Text-Schwärzung (Redaction) und Zoom bis 400 %.

Browser-Tab

Chromium-basierter Webbrowser mit Tabs und Lazy-Loading – inklusive zweistufigem Lesezeichen-System (global & privat) und direkter OSCAL-Back-Matter-Integration zum einfachen Erstellen von Referenzen.

Plugin-System

Erweiterbar über Hook-basierte Plugins mit Tab-Registrierung und Menü-Integration.

Systemvoraussetzungen

• Windows 10/11, macOS 10.15+, Linux (Ubuntu 20.04+)
• 4 GB RAM (8 GB empfohlen), 2000 MB freier Speicherplatz
• Es wird keine DATENBANK benötigt – alle Daten werden nativ in JSON-Dateien im Benutzerverzeichnis gespeichert, um maximale Portabilität zu gewährleisten.
• Die meisten Funktionen sind vollständig offline nutzbar, einschließlich der KI-Tools (lokale Modelle) und der automatischen OSCAL-Dokumenten-Heilung. Nur die Translate-Funktion erfordert eine Internetverbindung, da sie auf die DeepL-API zugreift (Bei Sicherheitskritischen Umgebungen kann diese Funktion deaktiviert werden).

Automatische OSCAL-Dokumenten-Heilung

… in der Praxis selten aus genau einem Werkzeug: Generatoren, Skripte, ältere Editoren, KI-Pipelines oder manuelle Bearbeitung produzieren regelmäßig schemawidrige oder veraltete Strukturen (verbotene Top-Level-Felder, falsch verschachtelte Objekte, Legacy-Container, fehlende Pflichtfelder, fehlende Zeitzonen-Suffixe …). Statt den Anwender mit kryptischen Validator-Meldungen alleinzulassen, heilt mjEdit solche Dokumente beim Öffnen und Speichern automatisch und idempotent in einen OSCAL v1.2.2-konformen Zustand – ohne Datenverlust.

Was wird automatisch geheilt? (Auszug, dokumenttyp-spezifisch)

Dokumenttyp	Beispielhafte Heilung
SSP	Fehlende system-ids, leere role-id in responsible-parties, kaputte by-components-Einträge, schemawidriges description-Feld auf Statement-Ebene → automatische Migration in by-components[this-system].description
SSP	Veraltetes system-interconnections (NIST-Pre-1.2.2) → Migration in moderne components[type=interconnection]
SSP	Schemawidriges import-component-definitions → Migration in OSCAL-konforme back-matter.resources mit rlinks
SSP	Entfernen verbotener Top-Level-Container (control-implementations), Bereinigen leerer Pflicht-Arrays
Assessment Results	Fehlendes import-ap (Pflichtfeld) wird mit Platzhalter-Stub ergänzt
Assessment Results	Fehlendes assessment-platforms in local-definitions.assessment-assets wird ergänzt
Assessment Results	Datetime-Felder ohne Zeitzonen-Suffix (start, end in Result, Assessment-Log-Entries) → automatisch UTC (Z)
POA&M	Legacy-remarks auf Risk-Ebene → verlustfrei in props[name=legacy-remarks]
Component-Definition	Erkennung und Konvertierung älterer Strukturformate
Mapping-Collection	NIST-spezifische Pflicht- und Strukturanpassungen (provenance, map-entry) automatisch vor Schema-Validierung

Eigenschaften der Heilung:

• Verlustfrei: Inhalte werden migriert, nicht gelöscht. Texte aus verbotenen Feldern landen in semantisch korrekten Zielfeldern (z. B. this-system-Beschreibung oder remarks).
• Idempotent: Wiederholtes Öffnen/Speichern führt zum gleichen Ergebnis – die Heilung „wackelt" nicht zwischen zwei Zuständen.
• Beim Öffnen UND beim Speichern aktiv: So sieht die Validierung exakt das, was tatsächlich gespeichert wird.
• Statistiken im Log: Pro Save wird mitprotokolliert, wie viele Felder welchen Typs migriert wurden (z. B. statement_descriptions_migrated: 3).
• Round-Trip-fähig: Migrierte Inhalte werden beim erneuten Öffnen wieder im passenden Dialog angezeigt – der Anwender merkt von der internen Umstrukturierung nichts.

Praxistipp: Wer ein OSCAL-Dokument aus einem fremden Tool oder einem alten Bestand erbt, muss es nicht manuell schema-fixen. Einmal in mjEdit öffnen, einmal speichern – fertig. Das Dokument ist anschließend sauber gegen OSCAL v1.2.2 validierbar.

Übergreifende Funktionen

• Effizientes Tree-View mit Echtzeit-Filter
• Automatische Backups und Versions-Archiv
• Vollständige Zweisprachigkeit (Deutsch/Englisch)
• Intelligente Pfad-Korrektur für portable OSCAL-Projekte
• Automatische OSCAL-Dokumenten-Heilung (siehe oben)
• Druck und Export als XML, CSV, PDF, HTML, Markdown

Neueste Verbesserungen – Mai 2026

In den letzten Wochen wurde die OSCAL-Arbeit mit mjEdit in mehreren Schritten weiter verfeinert.

Smart-Open für Evidenz-Dateien. Klickt der Anwender im Assessment-Plan oder Assessment-Results auf eine Back-Matter-Ressource, erkennt mjEdit den Dateityp und öffnet sie im passenden Tab: JSON in Editor/Form, Markdown im Markdown-Tab, PDFs im PDF-Tab und Bilder direkt im neuen Screenshot-Tab.

Konsistente Back-Matter-UX in AP, AR, SSP und Profile:

• Neuer Menüpunkt „Vorschau anzeigen" in AP und AR (analog zum SSP).
• „Ressource bearbeiten" gibt bei ungültigen Indizes eine klare Rückmeldung.
• Doppelter Eintrag „Evidenz bearbeiten" wurde aus dem AP-Kontextmenü entfernt.
• Im Profile-Tab erscheint der Knoten 📚 Back-matter jetzt immer – auch bei leeren Profilen.

Dual-Subject-Workflow: Komponente UND Inventory-Item. Der Subject-Picker liest den Pool über die volle Importkette AR → AP → SSP (import-ap.href → import-ssp.href). Wählt der Anwender inventory-item als Haupttyp, zeigt der Picker zusätzlich passende Komponenten (implemented-components). Im AP-Tree erscheinen typabhängige Icons (🧩 Component, 📦 Inventory-Item, 👤 User, 🏢 Party, 📍 Location, 🖥️ this-system) sowie Marker [alle], [inkl. N], [excl. M].

Sprachqualität. Mehrere EN-Übersetzungen wurden korrigiert und neue Strings ergänzt – die zweisprachige Oberfläche bleibt auch bei den neuen Funktionen konsistent.