KORTHEXDocumentation

Docs / OUTPUT & MIGRATION

OUTPUT & MIGRATION

Output & Reports

Written and maintained by Hendrik Schneider · Last reviewed · How we check this

Korthex produces structured reports in multiple formats. Each format serves a different workflow - from in-Korthex review to CI/CD integration to compliance auditing. Tier policy - output formats are license-gated. All Korthex editions emit reports in the native encrypted formats ( .kxr , .kxi , .kxg.* , …), which are consumable inside Korthex (CLI, Dashboard, IDE plugins, Mobile). Plain-JSON and plain-PDF export are Enterprise-only features. Every other edition (Free, Community, Business) cannot emit raw JSON or PDF - outputs stay encrypted and tied to Korthex tooling. Standardized industry formats (CycloneDX CBOM, SPDX SBOM, SARIF) fall under separate per-tier rules - see Output Format Tier Matrix below.

Output Format Tier Matrix

Why this restriction exists. Korthex reports contain sensitive cryptographic-posture data that, in unprotected form, can be consumed by anything outside Korthex. The encrypted formats keep findings tied to the Korthex toolchain (CLI / Dashboard / IDE plugins / Mobile), where access control, redaction, and audit logging apply. Enterprise customers with their own data-governance pipelines can opt into plain-JSON / plain-PDF for downstream integration; other editions stay in the encrypted-only path.

FormatFreeCommunityBusinessEnterprise
.krx (native encrypted report)YesYesYesYes
.kxi (encrypted inventory)-YesYesYes
.kxg.* (encrypted dataflow graph)--YesYes
.kxsim (encrypted simulation state)--YesYes
SARIF 2.1.0-YesYesYes
CycloneDX CBOM (industry standard)-YesYesYes
SPDX SBOM (industry standard)--YesYes
JUnit XML (CI consumption)-YesYesYes
Plain JSON export---Yes (Enterprise only)
Plain PDF export---Yes (Enterprise only)
Custom output templates---Yes (Enterprise only)

.kxr / .krx Format (native)

The native Korthex report format is an encrypted, signed binary that preserves all scan metadata, finding details, context evidence, and cluster information. Available on every license tier. Tamper-proof: cryptographically signed to prevent modification. Encrypted at rest with authenticated encryption. Full fidelity: all scan data preserved, including suppressed findings. Consumed by the Korthex CLI, Dashboard, IDE plugins, and Mobile companion. # Generate the native encrypted report (default) korthex scan . # Read it back as plain JSON korthex reports --export .korthex/reports/scan_20260406.krx report.json # Same thing, low-level, with an explicit key korthex decrypt .korthex/reports/scan_20260406.krx --output report.json

CBOM (CycloneDX)

Korthex exports a Cryptographic Bill of Materials in CycloneDX format - the industry standard for software supply chain transparency. Community tier and above. The CycloneDX emitter lives in the Inventory engine and produces a CycloneDX 1.5 crypto-BOM covering all discovered cryptographic components: algorithms, key sizes, certificate chains, library references, and their locations in your codebase. No client reaches it yet. Neither the CLI nor the Dashboard can currently write a CycloneDX document - --format on scan takes text, json, sarif, html or pdf, and there is no export verb. The command below is the interface being built, not one you can run today. What you can export right now is the Dashboard's Export CBOM (JSON or CSV rows). # Planned - not yet available korthex export report.krx --format cyclonedx --output cbom.cdx.json

SARIF

SARIF (Static Analysis Results Interchange Format) output integrates directly with GitHub Code Scanning, Azure DevOps, and other SARIF-compatible tools. Community tier and above. korthex scan . --format sarif --output results.sarif - name: Korthex Scan run: korthex scan . --format sarif --output results.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: results.sarif

JSON & PDF (Enterprise only)

Enterprise tier only. Plain-JSON and plain-PDF export require an Enterprise license. Free, Community, and Business editions cannot produce these formats - their outputs stay in the native encrypted formats consumable inside Korthex tooling. The industry-standard formats (CycloneDX CBOM, SPDX SBOM, SARIF) are not affected by this restriction. Plain JSON Machine-readable scan results for custom integrations, downstream pipelines, and scripting. Enterprise customers typically use this to feed Korthex findings into internal data-governance, GRC, or SIEM platforms. # Enterprise only korthex scan . --format json | jq '.findings[] | select(.severity == "CRITICAL")' # Or decrypt an existing native report into plain JSON korthex reports --export report.krx report.json Plain PDF Human-formatted reports for stakeholder presentation: executive summary, finding details, compliance mapping. Rendered locally by the CLI from the native report - nothing leaves the machine. # Enterprise only korthex scan . --format pdf --output audit-report.pdf # Executive layout instead of the full finding list korthex scan . --format pdf --report-type executive --output board.pdf Non-Enterprise alternatives. Free / Community / Business customers who need a portable view should use: SARIF (CI dashboards), CycloneDX CBOM (supply-chain tooling), the Dashboard's built-in shareable view, or the .kxw Workspace Bundle for passing a sealed package to another Korthex installation.

Sample Finding (JSON)

Every finding in a Korthex report follows the same shape regardless of the originating engine. The document below is the shape the JSON formatter emits in Korthex 1.0.0 ; keys are snake_case and severities are lower-case throughout. { "korthex_version": "1.0.0", "scan_timestamp": "2026-05-14T10:23:18Z", "scan_duration_ms": 48213, "target": { "path": "/projects/payments-service", "files_scanned": 1842, "files_skipped": 37 }, "summary": { "total_findings": 48, "by_severity": { "critical": 2, "high": 7, "medium": 15, "low": 24 }, "by_category": { "weak_algorithm": 31, "hardcoded_key": 9, "insecure_random": 8 } }, "compliance": { "nist": { "pass": 12, "fail": 31, "not_applicable": 0 } }, "findings": [ { "id": "KRX-001", "severity": "high", "category": "weak_algorithm", "algorithm": "AES-ECB", "status": "deprecated", "baseline_id": "CIP-E-B-AESECB", "file": "src/main/java/com/acme/auth/TokenSigner.java", "line": 142, "column": 17, "code_snippet": "Cipher.getInstance(\"AES/ECB/PKCS5Padding\")", "message": "Block cipher mode ECB exposes patterns in plaintext.", "backed_by": "NIST SP 800-38A, BSI TR-02102-1", "source_details": ["NIST SP 800-38A §6.1"], "replace_with": ["AES-256-GCM"], "compliance_violations": ["nist"], "cve_references": [], "fix_available": true } ], "databases": { "summary": { "totalFindings": 0, "databaseTypes": [] } }, "metadata": { "engine_version": "1.0.0", "baseline_version": 1, "baseline_source": "online", "jurisdictions_applied": ["us", "eu"] } } This schema was read off the emitting code ( JsonReportFormatter ) at Korthex 1.0.0 , not off a sample file. Pin your integration to a Korthex version and re-check on upgrade: the document carries korthex_version for exactly that purpose, and there is no separate schema-version field. Field reference for the fields that aren't self-explanatory: There is no fingerprint field. For cross-scan deduplication build your own key from the fields above - file , line , algorithm and baseline_id are the stable ones - and note that any key including line will drift when code moves.

FieldMeaning
idPer-finding identifier as supplied by the engine. When the engine supplies none, the formatter falls back to the finding's position in the array (KRX-001, KRX-002, …) - that fallback is NOT stable across scans, so do not key on it blindly.
severityLower-case: critical, high, medium, low. by_severity counts these four; there is no info bucket and no suppressed count.
categoryFormatter classification, e.g. weak_algorithm, weak_key_length, hardcoded_key, insecure_random, insecure_padding, deprecated_algorithm, deprecated_protocol, weak_key_exchange, insecure_cert_validation, missing_encryption, weak_password, plus the database_* family.
statusBaseline Registry verdict for the algorithm. Defaults to disallowed when the engine reports none.
baseline_idRegistry entry the verdict came from. Emitted only when the engine supplied one.
code_snippetCode context at the finding site. Sanitized: never includes secret material verbatim.
backed_byComma-separated standards the verdict rests on, as a single string - not an array.
replace_withRecommended replacements. fix_available is simply whether this array is non-empty.
key_usageKeyUsageProfile block. Emitted only when the engine attached one, so treat it as optional.
compliancePer-framework pass/fail/not_applicable tallies, derived from the findings' backed_by values when the report carries no compliance block of its own.

Auxiliary Formats

Korthex emits a number of auxiliary file formats around the primary report. This is the at-a-glance list. See the dedicated File Format Reference section for the complete catalog with magic bytes, encryption, and user-editability flags.

PurposeExtensionDescription
Dataflow Graph.kxg (+ sub-variants)Serialized dataflow graph: code, binary, runtime, config, tls, git.
Crypto Inventory.kxiEncrypted inventory of all cryptographic assets discovered.
Migration Plan.krxSequenced migration plan with per-item replacements and dependency order.
Policy File.kxp (encrypted) or .korthex_policy.json (plain)Organizational policy: permitted algorithms, key sizes, exemptions.
Scan History.kxfhTracks finding-IDs across scans so you see deltas (new / resolved / regressed).
Simulation State.kxsimMigration-simulation persistence: re-loadable, incremental.
Workspace Bundle.kxwCross-user portable export: passphrase-encrypted archive.
Runtime Report.krxrEncrypted output from the Runtime Agent.