# Korthex - Complete Site Content > Korthex is an on-premise cryptography scanner built by Flowence. It inventories every cipher, certificate, and key in a codebase, detects weak, broken, deprecated, and quantum-vulnerable cryptography, generates a Cryptographic Bill of Materials (CBOM), and produces a concrete migration path to post-quantum and compliance standards. 100% on-premise; source code never leaves your infrastructure. This file is the full-content companion to https://korthex.io/llms.txt (the curated index). It is generated from the same sources as the website on every build. Content last reviewed: 2026-07-10. ## Product, Solution and Compliance Pages ### Post-Quantum Cryptography Scanner URL: https://korthex.io/pqc-scanner Korthex scans source code, dependencies, binaries, TLS certificates and git history for quantum-vulnerable cryptography - RSA, ECC, Diffie-Hellman and DSA - buckets every finding by post-quantum readiness, and generates a concrete migration plan to ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). 100% on-premise: source never leaves your infrastructure. #### What is a post-quantum cryptography scanner? A post-quantum cryptography scanner is a static-analysis tool that finds every use of asymmetric cryptography that a cryptographically relevant quantum computer could break. Shor's algorithm solves integer factorization and discrete logarithms, so the affected primitives are RSA, ECC (ECDSA, ECDH, EdDSA), finite-field Diffie-Hellman, and DSA. Symmetric ciphers and hashes are affected differently: Grover's algorithm halves their effective strength, which is why AES-128 is commonly upgraded to AES-256 during a PQC migration. Korthex scans 18 languages plus dependencies, binaries, TLS / PKI certificates, databases and git history. Every quantum-vulnerable finding lands in one inventory with file and line, severity, a taint-based verdict, and a post-quantum readiness bucket - a quantum-vulnerable code finder whose output you can hand directly to the team that has to fix it. #### Why scan now? Harvest now, decrypt later Encrypted data recorded today can be stored and decrypted once a sufficiently large quantum computer exists. For anything with a long confidentiality lifetime - health records, financial data, state secrets, firmware signing keys - the migration deadline is set by the attacker's recorder, not by the arrival of the quantum computer. The regulatory timelines reflect that. We track these rather than restate them: each row above maps to rules in the NIST, BSI and CISA channels, and a change in one of them changes what a scan reports. #### What does Korthex find, and what replaces it? - RSA and ECDH key exchange: replaced by ML-KEM (FIPS 203), typically run in hybrid mode with a classical algorithm during transition - RSA, ECDSA and EdDSA signatures: replaced by ML-DSA (FIPS 204) - Long-lived signing such as firmware and code signing: SLH-DSA (FIPS 205) as the conservative, hash-based option - TLS endpoints and certificates negotiating quantum-vulnerable key exchange or signed with weak algorithms - 128-bit symmetric configurations: flagged for upgrade to 256-bit keys in line with BSI and CNSA 2.0 guidance - Every finding carries file:line evidence, severity, a taint verdict, and its post-quantum readiness bucket in the CBOM #### From scan to migration plan A scan produces a Cryptographic Bill of Materials (CBOM) with a per-finding post-quantum bucket. Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. From the CBOM, Korthex generates a topologically-ordered migration plan: per item the file and line, the replacement algorithm, a deadline, an effort estimate in hours, and the dependency order - with an impact simulation that shows what a change touches before you make it. Weak cryptography is proven, not pattern-matched: extracted cryptography is graded by emulation against NIST Known-Answer Tests, with a side-channel timing verdict. #### A quantum-vulnerable code finder in CI Korthex ships a GitHub Actions step, a GitLab CI template and a generic CLI exit code for any pipeline. Scans fail above a configurable risk threshold, and SARIF integration puts findings inline in pull requests - so new quantum-vulnerable code fails the build before it merges, and the PQC inventory stays current on every commit. #### Frequently asked questions Q: What makes code quantum-vulnerable? A: Any use of RSA, ECC (ECDSA, ECDH, EdDSA), finite-field Diffie-Hellman or DSA for key exchange, encryption or signatures. These primitives rely on integer factorization or discrete logarithms, both of which Shor's algorithm breaks on a cryptographically relevant quantum computer. Q: Is Korthex a NIST FIPS 203 scanner? A: Yes. Korthex maps every quantum-vulnerable finding to its NIST successor standard: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for signatures, SLH-DSA (FIPS 205) for hash-based signatures - and reports FIPS 140-3 compliance status alongside. Q: Can Korthex plan an ML-KEM migration? A: Yes. The migration plan lists every RSA / ECDH key-exchange site with file and line, the ML-KEM replacement, dependency order and an effort estimate, and recommends hybrid (classical plus ML-KEM) modes where appropriate during transition. Q: Is Korthex only a post-quantum scanner? A: No. Korthex is a full cryptography scanner: weak and broken primitives (MD5, SHA-1, DES, 3DES, RC4, Blowfish, AES-ECB / CBC misuse), hardcoded keys and leaked secrets, insecure TLS configurations, and quantum exposure - all in one CBOM. Q: Does source code leave my infrastructure? A: No. Korthex runs 100% on-premise as a CLI or inside CI/CD, including air-gapped operation. Only anonymized metadata is transmitted for the dashboard report. Q: How long does a post-quantum scan take? A: Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. All 18 supported languages are covered in the same pass. ### Cryptographic Bill of Materials (CBOM) Generator URL: https://korthex.io/cbom-generator Korthex generates a complete CBOM from source code, dependencies, binaries, TLS / PKI certificates, databases and git history: every cryptographic primitive with file:line evidence, severity, taint verdict, post-quantum readiness and compliance status - exported as CycloneDX, SARIF, JSON, PDF or .kxr. 100% on-premise. #### What is a cryptographic bill of materials? A cryptographic bill of materials (CBOM) is a machine-readable inventory of every cryptographic asset in a software system: algorithms, modes, key sizes, certificates, protocols, libraries, and the dependencies between them. CycloneDX 1.6, standardized as ECMA-424, defines the industry format. A CBOM is to cryptography what an SBOM is to dependencies: the inventory you need before you can migrate anything, and increasingly the artifact auditors ask for. Regulation is catching up: PCI DSS 4.0 requirement 12.3.3 requires a documented inventory of cipher suites and protocols in use, and NIST, BSI and EU post-quantum migration guidance all name a cryptographic inventory as the mandatory first step. #### What must a useful CBOM contain? - Every primitive with algorithm, mode and key size: hashes (MD5, SHA-1, SHA-256, SHA-3), symmetric ciphers (DES, 3DES, RC4, Blowfish, AES with mode), asymmetric primitives (RSA, ECC, Diffie-Hellman, DSA) - File and line evidence for every entry, so each finding is directly actionable - A severity score and a taint-based verdict that separates reachable production usage from dead code and test fixtures - A post-quantum readiness bucket per finding - Compliance status against NIST FIPS 140-3, FIPS 203 / 204 / 205, BSI IT-Grundschutz, BSI TR-02102, PCI-DSS and ISO 27001 - Certificates, TLS configurations and database encryption state - not just application code #### How does Korthex generate a CBOM? Five correlating engines (Scanner, Context, KorthexNN, plus the binary and TLS / PKI analyzers) read the codebase as one pass across 18 languages, including dependencies, binaries and git history. The CBOM exports as CycloneDX, SARIF, JSON, PDF or the native .kxr format. Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. Findings from code, configuration, TLS / PKI, databases and git history merge into cross-engine attack paths - one reachability-scored chain per issue instead of flat, file-local findings - so the CBOM shows not only that a weak primitive exists, but how it is actually reachable. #### Open-source CBOM tools, and where Korthex differs If you want a free, open-source starting point, IBM's CBOMkit is the reference toolset: it scans git repositories and container images, produces CycloneDX CBOMs, and ships a viewer and compliance checks. The CycloneDX project maintains the CBOM specification itself and general SBOM tooling around it. Korthex is a commercial, fully on-premise scanner that differs in four ways: cross-engine detection (code, binaries, TLS, databases, git history - not source alone), taint-based false-positive filtering with a verdict per finding, a generated migration plan with impact simulation attached to every CBOM entry, and offensive verification that grades extracted cryptography by emulation against NIST Known-Answer Tests. Teams that outgrow inventory-only tooling typically move up when they need the migration plan and the proof. #### From CBOM to crypto agility Crypto agility is the ability to swap algorithms when standards change without breaking production. It rests on four building blocks: a current inventory (the CBOM), risk scoring, a migration path, and a CI/CD gate that keeps the inventory honest on every commit. Korthex ships all four - the CBOM is the foundation, the migration plan and the pipeline gate make it operational. #### Frequently asked questions Q: Which formats does the Korthex CBOM export? A: CycloneDX, SARIF, JSON, PDF, and the native .kxr format. The CBOM lists every cryptographic primitive with file path, line number, severity, taint verdict, post-quantum readiness and compliance status. Q: Is a CBOM required by regulation? A: Increasingly, yes. PCI DSS 4.0 requirement 12.3.3 requires a documented inventory of cipher suites and protocols. NIST IR 8547, BSI guidance and the EU post-quantum roadmap all define a cryptographic inventory as the first migration step. A CBOM is the standard machine-readable way to satisfy these. Q: What is the difference between an SBOM and a CBOM? A: An SBOM inventories software components and their versions. A CBOM inventories cryptographic assets - algorithms, keys, certificates, protocols - and their dependencies. They are complementary, and CycloneDX defines both. Q: Does CBOM generation work air-gapped? A: Yes. Korthex runs 100% on-premise, including air-gapped operation. Source code never leaves your infrastructure. Q: Can I gate CI/CD on the CBOM? A: Yes. The GitHub Actions step, GitLab CI template and generic CLI exit code fail the build above a configurable risk threshold - for example when new weak or quantum-vulnerable cryptography appears in a pull request. ### Recognized Authorities & Frameworks URL: https://korthex.io/compliance Korthex does not invent its own opinion of what counts as weak cryptography. Findings are graded against baseline channels curated from the recognized authorities (NIST, BSI, ANSSI, CISA, IETF, OWASP) plus jurisdiction overlays for regulated regions, delivered as signed updates, and every finding carries the framework tags it trips. This page is the map. #### How do authority baselines work? Each authority is a baseline channel: a deterministic rule set curated from that authority's primary documents. Most regulatory upstreams publish PDFs, so their channels are hand-curated through reviewed changes; the OWASP ASVS channel is pulled live from the official OWASP repository. The backend re-checks every channel on a 24-hour cycle and ships differences as signed update patches, so a new deprecation reaches your scans without a product update. When authorities disagree (they do: key-size floors and deprecation dates differ between NIST, BSI and ANSSI), a documented priority order decides the reported verdict, and the finding still lists every authority's stance in its sources, so an auditor sees the full picture instead of a single opinion. #### Per-finding evidence Every finding carries the framework tags of the rule that graded it. A single MD5 hit can trip NIST FIPS 140-3, BSI TR-02102, NIS2 and PCI DSS 4.0 at once, and the scan report says so, with file and line. The CBOM export aggregates this into the artifact compliance teams hand to auditors: which frameworks are affected, where, and what replaces the finding. #### Which channels should you activate? - US Federal (FedRAMP, FISMA): NIST + CISA channels - EU critical infrastructure (NIS2): BSI + ANSSI channels - EU payments and FinTech: BSI + ANSSI + the EU Payments overlay - German enterprise: BSI channel; French enterprise: ANSSI + France overlay - United Kingdom: NIST + the UK overlay; Australia: the ASD ISM overlay; Canada: NIST + the CCCS overlay - Generic global SaaS: NIST + BSI + IETF + OWASP - Default when nothing is configured: every channel the backend advertises #### Standards & authorities - NIST (https://korthex.io/compliance/nist) - SP 800-131A Rev. 2, FIPS 180-4, FIPS 197 - 24 rules, highest priority - BSI (https://korthex.io/compliance/bsi) - TR-02102-1 - 16 rules, carries NIS2 tags - ANSSI (https://korthex.io/compliance/anssi) - RGS Annexe B1 v2.0 - 9 rules, carries NIS2 tags - CISA (https://korthex.io/compliance/cisa) - Post-Quantum Initiative, BOD 18-01 - 7 rules - IETF (https://korthex.io/compliance/ietf) - RFC deprecation track (8996, 8429, 6151, 6194) - 11 rules - OWASP (https://korthex.io/compliance/owasp) - ASVS v5 chapters V11 + V12, live source - 33 rules #### Jurisdictional mappings - EU Cyber Resilience Act (https://korthex.io/compliance/eu-cra) - CRA readiness: inventory, state-of-the-art evidence, CI gate - EU Payments (https://korthex.io/compliance/eu-payments) - PSD2, DORA, PCI DSS 4.0 - payment-infrastructure overlay - Germany (https://korthex.io/compliance/germany) - BSI TR-02102, IT-Grundschutz, NIS2 implementation - France (https://korthex.io/compliance/france) - ANSSI RGS, OIV critical-infrastructure overlay - United Kingdom (https://korthex.io/compliance/united-kingdom) - NCSC Foundation Profile overlay - Australia (https://korthex.io/compliance/australia) - ASD ISM overlay for OFFICIAL-classified data - Canada (https://korthex.io/compliance/canada) - CCCS ITSP.40.111 overlay #### Framework deep dives - NIST FIPS 140-3 (https://korthex.io/compliance/fips-140-3) - Approved algorithms, the 140-2 sunset, audit evidence - PCI-DSS (https://korthex.io/compliance/pci-dss) - Requirements 3, 4, 8 and the 12.3.3 inventory - ISO 27001 (https://korthex.io/compliance/iso-27001) - Annex A 8.24 evidence generation - BSI IT-Grundschutz (https://korthex.io/compliance/bsi-it-grundschutz) - CON.1 Kryptokonzept and TR-02102 checks #### Frequently asked questions Q: How current are the authority baselines? A: The backend re-checks every channel on a 24-hour cycle and publishes signed patch updates. Clients verify the signature before applying, and updates reach scans without reinstalling anything. Q: What happens when two authorities disagree? A: A documented priority order (NIST before BSI before ANSSI, down to the Korthex-curated fallback) decides the reported verdict. The finding keeps every authority's stance in its sources, so nothing is hidden behind the winner. Q: Do the baselines work air-gapped? A: Yes. Baseline updates are signed files; clients verify them before applying, and they can be transferred into air-gapped environments on your own schedule. Q: Is there a Korthex opinion channel? A: Yes, a Korthex-curated consensus channel exists as the lowest-priority fallback for algorithms the authorities have not yet ruled on. It never overrides an authority. ### NIST Cryptography Compliance URL: https://korthex.io/compliance/nist The NIST channel is the highest-priority baseline source in Korthex: 24 rules curated from SP 800-131A Rev. 2 (algorithm transitions), FIPS 180-4 (secure hash standard) and FIPS 197 (AES), tagged against FIPS 140-3, with the FIPS 203 / 204 / 205 post-quantum successors mapped per NIST IR 8547. #### What does the NIST transition schedule require? - 3DES: disallowed for encryption after 2023 (SP 800-131A Rev. 2) - SHA-1: disallowed for digital signature generation; hash migration to SHA-2 / SHA-3 - RSA below 2048 bit and legacy finite-field parameter sets: disallowed - AES (FIPS 197) and the SHA-2 family (FIPS 180-4) as the approved symmetric baseline - Post-quantum: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) approved since August 2024; RSA and ECC deprecated after 2030 and disallowed after 2035 per NIST IR 8547 #### The Korthex NIST channel The channel's 24 rules are hand-curated from the primary documents through reviewed changes, re-checked on the 24-hour cycle, and shipped as signed updates. NIST sits first in the authority priority order, so when authorities disagree, the NIST stance decides the reported verdict, and every finding graded by a NIST rule carries the FIPS 140-3 framework tag into the report and the CBOM. #### From findings to audit evidence For FIPS-facing audits, the CBOM lists every non-approved algorithm with file, line, severity and the NIST rule that flagged it. The FIPS 140-3 deep dive covers the 140-2 sunset in September 2026 and what Korthex does and does not do around module certification. #### Frequently asked questions Q: Which NIST documents feed the channel? A: SP 800-131A Rev. 2 for algorithm transitions, FIPS 180-4 for hashes, FIPS 197 for AES, plus the FIPS 203 / 204 / 205 post-quantum standards and NIST IR 8547 timelines for successor mapping. Q: Does this cover post-quantum requirements? A: Yes. Quantum-vulnerable findings carry their FIPS 203 / 204 / 205 successor and the IR 8547 timeline (deprecated after 2030, disallowed after 2035), and the migration plan orders the replacements. Q: Why is NIST the highest-priority authority? A: Most customers anchor on NIST because FIPS 140-3 has the broadest procurement reach. The priority order is documented and the other authorities' stances stay visible on every finding regardless. ### BSI Cryptography Compliance (TR-02102) URL: https://korthex.io/compliance/bsi We curated 16 rules from BSI TR-02102-1, the German federal office's cryptographic recommendations: key-size floors, approved hashes and modes, and quantum-safe hybrid guidance. Each rule is tagged against BSI TR-02102 and NIS2, so one finding serves both the German baseline and the EU directive. #### What does TR-02102 require? - RSA and discrete-log systems: at least 3000 bit - Elliptic-curve cryptography: at least 250 bit - Hashes: SHA-256 or stronger; MD5 and SHA-1 out - Authenticated encryption modes over bare CBC / ECB - Quantum-safe hybrid key exchange recommended for new systems - TR-02102-2 applies the same logic to TLS configuration #### TR-02102-1 thresholds and the rules that enforce them The rule IDs below are the ones that appear in a Korthex finding, so a TR-02102 question in an audit can be answered by grepping the CBOM rather than by reading the report. #### The Korthex BSI channel We curated 16 rules from TR-02102-1 and put BSI second in the authority priority order, behind NIST and ahead of IETF. They are re-checked on the 24-hour cycle and shipped as signed updates. Because we co-tag the BSI rules with NIS2 alongside ANSSI, an EU critical-infrastructure operator activates exactly these two channels to grade against the directive's state-of-the-art expectation. #### Beyond the baseline: Grundschutz evidence TR-02102 defines the numbers; IT-Grundschutz building block CON.1 demands the documented Kryptokonzept around them. The BSI IT-Grundschutz deep dive covers how the CBOM serves as the living inventory annex to that concept. #### Frequently asked questions Q: How does the BSI channel relate to IT-Grundschutz? A: The channel grades algorithms against TR-02102-1. IT-Grundschutz (CON.1 Kryptokonzept) is the process framework around it; the dedicated Grundschutz page covers the evidence workflow. Q: Does the BSI channel help with NIS2? A: Yes. BSI rules carry the NIS2 framework tag (alongside ANSSI), so findings translate directly into NIS2 state-of-the-art evidence for critical-infrastructure operators. Q: Are reports available in German? A: Reports are in English; every finding carries the TR-02102 reference regardless of language, and German requirement identifiers are preserved verbatim. ### ANSSI Cryptography Compliance (RGS B1) URL: https://korthex.io/compliance/anssi The ANSSI channel carries 9 rules curated from RGS Annexe B1 v2.0, the Référentiel Général de Sécurité's cryptographic annex maintained by France's national cybersecurity agency. Rules are tagged against ANSSI-RGS-B and NIS2; the France overlay adds critical-infrastructure (OIV) scope on top. #### What does RGS B1 set? RGS Annexe B1 is the French reference for approved cryptographic mechanisms: key-size floors, approved hash and signature mechanisms, and validity horizons. It is the yardstick French administrations and their suppliers are assessed against, and like BSI it feeds the NIS2 state-of-the-art expectation for EU operators. #### The Korthex ANSSI channel 9 hand-curated rules from RGS Annexe B1 v2.0, re-checked on the 24-hour cycle and shipped as signed updates. ANSSI sits directly after NIST and BSI in the priority order; findings graded by an ANSSI rule carry the ANSSI-RGS-B and NIS2 framework tags into the report and CBOM. French enterprises typically activate the ANSSI channel plus the France jurisdiction overlay, which layers OIV critical-infrastructure scope on top of the baseline. #### Frequently asked questions Q: What is the difference between the ANSSI channel and the France overlay? A: The ANSSI channel grades algorithms against RGS B1 for everyone who activates it. The France overlay adds jurisdiction-specific rules for French critical infrastructure (OIV) on top; it assumes the ANSSI channel underneath. Q: Does ANSSI grading help with NIS2? A: Yes. ANSSI rules carry the NIS2 framework tag alongside BSI, so EU operators get directive-ready evidence from either or both. Q: How current is the RGS mapping? A: The channel is curated from RGS Annexe B1 v2.0 and re-checked on the 24-hour update cycle like every other source, with changes arriving as signed patches. ### CISA Directives & Post-Quantum Initiative URL: https://korthex.io/compliance/cisa The CISA channel carries 7 rules curated from CISA's Post-Quantum Cryptography Initiative (Strategic Plan FY2024-2026) and Binding Operational Directive 18-01: the removal of weak protocols and ciphers from federal services and the migration path toward quantum-resistant cryptography. Rules are tagged against FIPS 140-3 and BOD 18-01. #### What do the directives demand? - BOD 18-01: legacy SSL/TLS versions and weak ciphers such as RC4 and 3DES removed from federal-facing services - PQC Initiative: inventory of quantum-vulnerable cryptography as the first migration step, aligned with the NIST FIPS 203 / 204 / 205 standards - Strategic Plan FY2024-2026: agencies expected to know where vulnerable cryptography lives before replacement budgets land #### The Korthex CISA channel We hand-curated 7 rules, re-check them on the 24-hour cycle and ship them as signed updates, co-tagged FIPS 140-3 and BOD 18-01 so one finding answers both a federal directive and the algorithm baseline underneath it. #### Frequently asked questions Q: Who should activate the CISA channel? A: US federal agencies, FedRAMP-facing vendors and anyone aligning with CISA's PQC migration guidance. The recommended profile pairs it with the NIST channel. Q: Does Korthex produce the PQC inventory CISA asks for? A: Yes. The CBOM lists every quantum-vulnerable primitive with location and successor mapping, which is the inventory step both CISA and NIST IR 8547 define as the migration's start. Q: Is BOD 18-01 only about web services? A: The directive targets federal-facing services, but the underlying weak-protocol rules (RC4, 3DES, legacy SSL/TLS) apply to any TLS configuration Korthex scans, so the channel flags them wherever they appear. ### IETF RFC Deprecation Track URL: https://korthex.io/compliance/ietf We curated 11 rules from the RFC deprecation trail - RFC 8996 (TLS 1.0 and 1.1), RFC 8429 (3DES and RC4 out of Kerberos), RFC 6151 (MD5) and RFC 6194 (SHA-1). Where a regulator tells you what an auditor expects, these tell you what the internet's own standards body has already retired. #### Why does an IETF channel matter? Regulatory baselines tell you what an auditor expects; the RFC track tells you what the internet itself has retired. A TLS endpoint still negotiating TLS 1.0 is not just a compliance finding, it is running a protocol version the IETF formally deprecated in RFC 8996. Grading against the RFC trail catches this class regardless of which regulator applies to you. #### Which RFC retired what, and the rule that finds it Each row is a deprecation the IETF published and the Korthex rule that detects it. The status column is the rule's own verdict in the baseline registry, not a restatement of the RFC. #### What does the channel track? - RFC 8996: TLS 1.0 and TLS 1.1 deprecated, TLS 1.2+ required - RFC 8429: 3DES and RC4 removed from Kerberos suites - RFC 6151: MD5 no longer acceptable where collision resistance matters - RFC 6194: SHA-1 security considerations and migration expectations - Tagged as IETF-Standard on every finding the channel grades #### Frequently asked questions Q: Who should activate the IETF channel? A: Everyone running TLS. It is part of the recommended global profile (NIST + BSI + IETF + OWASP) because protocol deprecations apply regardless of jurisdiction. Q: How does this differ from the TLS audit itself? A: The TLS certificate audit finds the configurations; the IETF channel supplies the deprecation rules they are graded against, with the RFC reference attached to each finding. Q: Is the channel updated when new RFCs land? A: Yes, through the same 24-hour signed update cycle as every other channel. ### OWASP ASVS Cryptography Verification URL: https://korthex.io/compliance/owasp The OWASP channel is the first live baseline source in Korthex: instead of a hand-curated snapshot, it pulls ASVS v5.x directly from the official OWASP repository on the 24-hour cycle and maps the cryptography chapters (V11 Cryptography, V12 Secure Communication) into 33 verification rules. When ASVS moves, the baseline moves with it. #### What does ASVS ask of your cryptography? - V11 Cryptography: approved algorithms only, no broken hashes in security contexts, sound key management and randomness - V12 Secure Communication: current TLS versions and strong cipher suites on every connection - The verification standard behind OWASP Top 10 A02 (Cryptographic Failures): ASVS is what you test against, the Top 10 is what goes wrong when you do not #### The live-source model Most authorities publish PDFs, so their channels are curated by hand. OWASP publishes ASVS as versioned files in the open, which lets Korthex consume it live: the 24-hour cron checks the official repository, short-circuits when nothing changed, and emits a signed update when it did. Your scans grade against the ASVS that exists today, not the copy someone pasted last year. Because ASVS is the standard development teams actually adopt, the CI/CD gate doubles as automated ASVS cryptography verification: a pull request that introduces a non-approved algorithm fails the check with the ASVS-tagged finding attached. #### Frequently asked questions Q: Which ASVS version does the channel track? A: The live 5.x line from the official OWASP repository. The channel re-checks daily and updates itself when OWASP publishes changes. Q: Does this cover the OWASP Top 10? A: The channel grades against ASVS, the verification standard behind Top 10 A02 (Cryptographic Failures). Findings map to concrete ASVS requirements rather than the Top 10's category level. Q: Who should activate the OWASP channel? A: Development-led organizations and anyone whose security program is ASVS-based. It is part of the recommended global profile alongside NIST, BSI and IETF. ### NIST FIPS 140-3 Scanner URL: https://korthex.io/compliance/fips-140-3 Korthex maps every cryptographic finding in your stack against NIST FIPS 140-3: it flags non-approved algorithms, weak key sizes and risky modes across source code in 18 languages, dependencies, binaries, TLS certificates and databases, with file and line evidence and a compliance status per finding. 100% on-premise. #### What does FIPS 140-3 require? FIPS 140-3 is the current US and Canadian standard for cryptographic modules, superseding FIPS 140-2. It defines which algorithms are approved (AES, the SHA-2 and SHA-3 families, approved RSA and ECDSA parameter sets, and since August 2024 the post-quantum standards ML-KEM, ML-DSA and SLH-DSA) and which are not (MD5, SHA-1 for signatures, DES, 3DES, RC4). The deadline pressure is concrete: the CMVP moves remaining FIPS 140-2 certificates to the historical list in September 2026. Any system that claimed FIPS 140-2 compliance needs to know exactly which cryptography it actually runs before pointing at a 140-3 module. #### What does Korthex flag against FIPS 140-3? - Non-approved primitives: MD5, SHA-1 signatures, DES, 3DES, RC4, Blowfish, wherever they appear in code, dependencies or binaries - Legacy key sizes: RSA below 2048 bit, ECC below 256 bit, in code and in certificates - Risky mode usage: AES-ECB, CBC without integrity protection, missing IVs, key reuse - Weak randomness sources feeding key or IV material - TLS configurations negotiating non-approved cipher suites - Post-quantum exposure: RSA, ECC and DH findings carry their FIPS 203 / 204 / 205 successor per NIST IR 8547 timelines (deprecated after 2030, disallowed after 2035) #### Audit-ready evidence Every finding lands in the Cryptographic Bill of Materials with file path, line number, severity, a taint-based verdict and its compliance status. Export as PDF for assessors or CycloneDX, SARIF and JSON for tooling. The CBOM is the artifact you hand to an auditor to show where your cryptography stands, and the CI/CD gate keeps it current between assessments. #### What does Korthex not do? Korthex does not certify cryptographic modules. Certification is performed by accredited laboratories under the CMVP. Korthex answers the question that comes before and after certification: where does non-approved cryptography live in your actual codebase, what replaces it, and has anything regressed since the last assessment. #### Frequently asked questions Q: Is FIPS 140-2 still valid? A: FIPS 140-2 certificates remain on the active list only until September 2026, when the CMVP moves them to the historical list. New procurement references FIPS 140-3. The practical consequence: inventory your cryptography now so the migration is planned rather than forced. Q: Which algorithms are FIPS-approved? A: AES, the SHA-2 and SHA-3 families, approved RSA and ECDSA parameter sets, and since August 2024 ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). MD5, SHA-1 for signatures, DES, 3DES and RC4 are not approved. Q: Can Korthex certify my product as FIPS 140-3 compliant? A: No. Certification is done by accredited labs under the CMVP. Korthex finds every place non-approved cryptography is used, maps it to the approved replacement, generates the migration plan, and gates CI/CD so you do not regress between assessments. Q: Does the scan run offline? A: Yes. Korthex runs 100% on-premise as a CLI or in CI/CD, including air-gapped operation. Source code never leaves your infrastructure. Q: How are findings mapped to FIPS 140-3? A: Each CBOM entry carries a compliance status against NIST FIPS 140-3 and FIPS 203 / 204 / 205, alongside BSI, PCI-DSS and ISO 27001, so one scan serves multiple frameworks. ### PCI-DSS Cryptography Scanner URL: https://korthex.io/compliance/pci-dss Korthex scans code, configuration, TLS and databases for cryptography that violates PCI DSS 4.0, and generates the documented inventory of cipher suites and protocols that requirement 12.3.3 demands, as a CBOM with file and line evidence. 100% on-premise, so cardholder-data environments never expose source code. #### Where does PCI DSS demand strong cryptography? - Requirement 3.5.1: PAN rendered unreadable anywhere it is stored, using strong cryptography - Requirements 3.6 and 3.7: documented key-management processes for the keys that protect cardholder data - Requirement 4.2.1: strong cryptography for PAN transmitted over open, public networks - Requirement 8.3.2: passwords and credentials protected with strong cryptography - Requirement 12.3.3: an inventory of all cipher suites and protocols in use, documented and reviewed at least every 12 months - Since March 31, 2025 the future-dated PCI DSS 4.0 requirements are mandatory, not best practice #### What does Korthex find in a cardholder-data environment? - Weak hashes protecting stored data: MD5, SHA-1, unsalted or fast hashes where strong cryptography is required - Legacy ciphers in code and dependencies: DES, 3DES, RC4, Blowfish, AES-ECB misuse - TLS configurations accepting weak protocol versions or cipher suites on data-in-transit paths - Hardcoded keys, credentials and API tokens in source, configuration and git history - Database and storage-layer encryption state - Key provenance: taint classification shows where every key originates #### Requirement 12.3.3: the inventory, automated The CBOM is the documented cipher-suite and protocol inventory that 12.3.3 asks for: every cryptographic primitive and protocol in use, with file and line evidence. Because it regenerates on every scan or commit, the review requirement turns from an annual scramble into a byproduct of CI. Export as PDF for your QSA or as CycloneDX and JSON for tooling. #### Honest scope Korthex covers the cryptography slice of PCI DSS: parts of requirements 3, 4 and 8, and the 12.3.3 inventory. It does not do network segmentation testing, ASV scanning or the full SAQ / RoC process. It pairs with, and feeds evidence into, your assessor workflow. #### Frequently asked questions Q: Is a cryptographic inventory mandatory under PCI DSS? A: Yes. PCI DSS 4.0 requirement 12.3.3 requires an inventory of all cipher suites and protocols in use, documented and reviewed at least once every 12 months. Since March 31, 2025 this is mandatory. The Korthex CBOM is that inventory, generated from what your systems actually run. Q: Does Korthex find TLS below 1.2 on cardholder-data flows? A: Yes. TLS configurations and cipher suites are scanned for weak protocol versions, weak suites and weak certificate signatures, and mapped to requirement 4.2.1. Q: Can I hand the report to a QSA? A: Yes. The CBOM exports as PDF for assessors and as CycloneDX, SARIF or JSON for tooling, with file:line evidence, severity and a taint verdict per finding. Q: Does source code leave the CDE? A: No. Korthex runs 100% on-premise as a CLI or inside CI/CD, including air-gapped operation. Only anonymized metadata is transmitted for the dashboard report. Q: Which PCI DSS requirements does Korthex cover? A: The cryptographic requirements: strong cryptography for stored PAN (3.5.1), key management context (3.6, 3.7), data in transit (4.2.1), credential protection (8.3.2), and the cipher-suite inventory (12.3.3). Segmentation, ASV scans and the assessment process itself remain with your QSA. ### ISO 27001 Cryptography Audit Tool URL: https://korthex.io/compliance/iso-27001 ISO/IEC 27001:2022 Annex A control 8.24 requires rules for the effective use of cryptography, including key management. Korthex produces the evidence side: a complete cryptographic inventory (CBOM) of the algorithms, key sizes, certificates and protocols actually in use, with weaknesses flagged and mapped, exported as PDF or CycloneDX for the audit file. 100% on-premise. #### What do auditors ask for under A.8.24? The 2022 revision folded the 2013 A.10 cryptography controls into control 8.24 (use of cryptography). Auditors want two things: a documented policy on cryptographic controls, and evidence that reality matches it: which algorithms run where, how keys are handled, and what the exceptions are. The gap is almost always on the reality side. The policy says AES-256 and SHA-256; the codebase says MD5 in a password path, a 1024-bit RSA key in a forgotten service, and a hardcoded API token from 2023. Korthex closes exactly that gap. #### Policy versus reality: what Korthex finds - Primitives that violate a typical crypto policy: MD5, SHA-1, DES, 3DES, RC4, Blowfish, AES-ECB and CBC-without-integrity misuse - Certificates and TLS configurations that do not match the policy: weak signatures, short keys, expired or near-expiry certificates - Hardcoded keys and secrets in source, configuration and git history: a key-management violation by definition - Quantum-vulnerable cryptography where long-term confidentiality is classified: RSA, ECC, Diffie-Hellman with their PQC successors - A compliance status per finding, mapped to ISO 27001 alongside NIST FIPS, BSI and PCI-DSS #### Evidence generation The CBOM exports as PDF for the audit file and as CycloneDX or JSON for GRC tooling. Because a scan is fast enough to run per commit, evidence generation is repeatable: run it per commit in CI and the annual audit stops being an archaeology project. Every entry carries file, line, severity and a taint verdict, so sampled findings survive auditor scrutiny. #### Honest scope Korthex covers the cryptography controls of an ISMS, not the whole ISO 27001 management system. Risk treatment, scope statements and organizational controls remain yours; Korthex supplies the technical inventory and the recurring proof for the cryptography slice. #### Frequently asked questions Q: Does ISO 27001 require a cryptographic inventory? A: Not in those words. Control 8.24 requires rules for the effective use of cryptography and their implementation. In practice, auditors accept a current inventory of cryptographic assets as the core evidence that the rules are implemented, and a CBOM is the standard machine-readable form of that inventory. Q: What changed between ISO 27001:2013 and 2022 for cryptography? A: The 2013 controls A.10.1.1 (policy on the use of cryptographic controls) and A.10.1.2 (key management) were merged into the 2022 control 8.24 (use of cryptography). The expectations are unchanged: documented rules plus evidence of implementation. Q: Can I use Korthex during certification preparation? A: Yes. A first scan shows the gap between your crypto policy and your codebase; the migration plan orders the fixes; re-scans document progress. The same CBOM then serves as evidence during the certification and surveillance audits. Q: Does the tool run on-premise? A: Yes. 100% on-premise or air-gapped, as a CLI or in CI/CD. Source code never leaves your infrastructure. Q: Which export formats does the audit evidence support? A: PDF for the audit file, CycloneDX, SARIF and JSON for tooling, plus the native .kxr format. All exports carry file:line evidence and per-finding compliance status. ### BSI IT-Grundschutz Crypto Scanner URL: https://korthex.io/compliance/bsi-it-grundschutz Korthex scans source code, TLS, databases and git history against the German BSI baseline: IT-Grundschutz building block CON.1 (Kryptokonzept) and the TR-02102 algorithm and key-length recommendations. Every finding carries the affected requirement, file and line, and a concrete replacement. Built in Germany, 100% on-premise, air-gapped capable. #### What does BSI expect? The IT-Grundschutz Kompendium requires a documented Kryptokonzept (building block CON.1): which algorithms, key lengths and protocols are used where, and how keys are managed. BSI TR-02102-1 supplies the concrete numbers: RSA and discrete-log systems at least 3000 bit, elliptic curves at least 250 bit, SHA-256 or stronger, authenticated encryption modes, and quantum-safe hybrid key exchange recommended for new systems. TR-02102-2 applies the same logic to TLS. #### What does Korthex flag against TR-02102? - RSA below 3000 bit (TR-02102 recommendation; below 2048 bit critical under every framework) - Elliptic-curve cryptography below 250 bit - MD5 and SHA-1 anywhere they carry security: signatures, integrity, password paths - Non-AEAD modes: AES-ECB, CBC without integrity protection, missing IVs, key reuse - Legacy TLS protocol versions and cipher suites per TR-02102-2 - Quantum-vulnerable RSA, ECC and Diffie-Hellman, with the ML-KEM / ML-DSA migration path that matches the BSI hybrid guidance #### Kryptokonzept evidence, generated The CBOM is the living annex to your Kryptokonzept: the inventory of what is actually deployed, regenerated per scan or per commit, with file and line evidence, severity, taint verdict and compliance status. Export as PDF for Grundschutz assessments and audits, or as CycloneDX and JSON for tooling. #### Built for German and EU environments Korthex runs 100% on-premise and air-gapped, the deployment model German federal, state and KRITIS environments typically require: source code never leaves the infrastructure. It is built in Germany by Flowence, and the same scan also maps findings to NIST FIPS 140-3, FIPS 203 / 204 / 205, PCI-DSS and ISO 27001, so international teams satisfy BSI and their other frameworks in one pass. The EU coordinated PQC roadmap expects first migration steps by the end of 2026; the quantum-exposure bucket in the CBOM is that first step. #### Frequently asked questions Q: What is CON.1 in IT-Grundschutz? A: CON.1 is the Kryptokonzept building block of the IT-Grundschutz Kompendium. It requires organizations to document and implement rules for cryptographic procedures: which algorithms, key lengths and protocols are used, where, and how keys are managed. Q: Which key lengths does BSI TR-02102 recommend? A: TR-02102-1 recommends at least 3000 bit for RSA and discrete-log systems, at least 250 bit for elliptic curves, SHA-256 or stronger hashes, and authenticated encryption modes. For new systems it recommends quantum-safe hybrid key exchange. Q: Does Korthex work in air-gapped environments? A: Yes. Korthex runs fully on-premise including air-gapped operation, as a CLI or inside CI/CD. Source code never leaves your infrastructure. Q: Does Korthex replace the Kryptokonzept document? A: No. The Kryptokonzept remains your policy document. Korthex generates the inventory and evidence side of it: what is actually deployed, where it deviates, and the ordered migration plan to fix deviations. Q: Is the report available in German? A: Reports are in English. Findings are mapped to the German standards (IT-Grundschutz, TR-02102) regardless of report language, with the requirement reference attached per finding. ### EU Cyber Resilience Act: Cryptography Readiness URL: https://korthex.io/compliance/eu-cra The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024; reporting obligations start in September 2026 and the main obligations apply from December 2027. For cryptography it demands what Korthex produces: proof that products protect data with state-of-the-art encryption, and documentation that stays current across the product lifecycle. #### What does the CRA expect from your cryptography? - Essential requirements (Annex I): protection of confidentiality and integrity with state-of-the-art mechanisms, including encryption of data at rest and in transit - Technical documentation that shows how those requirements are met, kept current across the support period - Vulnerability handling: knowing what is inside the product, so a broken algorithm is a locatable component, not a research project #### What does Korthex contribute? The CBOM is the cryptography slice of CRA technical documentation: every algorithm, key size, certificate and protocol in the product with file and line evidence. The state-of-the-art yardstick comes from the EU-relevant baseline channels (BSI and ANSSI, both carrying NIS2 tags), and the CI/CD gate regenerates the evidence on every commit, which is exactly the keep-it-current posture the CRA assumes. Honest scope: Korthex does not have a dedicated CRA rule channel today, because the act sets outcome requirements rather than an algorithm list. The framework-tagging model is deliberately extensible; when harmonised standards under the CRA name concrete cryptographic requirements, they land as tags without a format change. #### Frequently asked questions Q: When does the CRA actually apply? A: It entered into force on 10 December 2024. Vulnerability-reporting obligations apply from September 2026, the main obligations from December 2027. Products placed on the EU market after that date need the documentation in place. Q: Does a Korthex scan make my product CRA-compliant? A: No single tool does. Korthex produces the cryptographic inventory and the state-of-the-art evidence that the technical documentation and vulnerability-handling processes require; conformity assessment covers far more than cryptography. Q: Which baseline channels serve as the CRA yardstick? A: The EU-relevant channels: BSI and ANSSI (both NIS2-tagged), plus NIST for the global algorithm baseline. The overview page lists the recommended activation per profile. ### EU Payments Cryptography (PSD2, DORA, PCI DSS) URL: https://korthex.io/compliance/eu-payments The EU Payments overlay layers payment-specific cryptography rules on top of the authority baselines: 6 jurisdiction rules scoped to EU payment infrastructure and cardholder data, tagged against PSD2, DORA and PCI DSS 4.0. Activate it together with the BSI and ANSSI channels for the full EU payments posture. #### What does the overlay add? - PSD2: strong-cryptography expectations around authentication and communication in payment services - DORA: ICT-risk management evidence for financial entities, where a current cryptographic inventory is the concrete artifact supervisors can check - PCI DSS 4.0: strong cryptography for cardholder data at rest and in transit, and the requirement 12.3.3 cipher-suite inventory - Overlay model: jurisdiction rules layer on top of active authority channels instead of replacing them #### Recommended activation EU payments and FinTech organizations activate BSI + ANSSI as the authority base (both NIS2-tagged) plus this overlay. Findings then carry the payment-framework tags a supervisor or QSA expects, and the PCI-DSS deep dive covers the cardholder-data specifics, including the automated 12.3.3 inventory. #### Frequently asked questions Q: Does this overlay replace a PCI DSS assessment? A: No. It grades your cryptography against the payment frameworks and produces the evidence (inventory, findings, file:line). The assessment process itself stays with your QSA; DORA supervision stays with your authority. Q: How do DORA and this overlay fit together? A: DORA demands managed ICT risk with demonstrable control over cryptographic assets. The recurring CBOM plus per-finding framework tags is the concrete, checkable artifact that satisfies the cryptography slice of that expectation. Q: What exactly is a jurisdiction overlay? A: A rule layer that sits on top of the authority channels you activate. Authorities define the algorithm baseline; overlays add region- and sector-specific requirements without duplicating the base rules. ### Germany: BSI, NIS2 and Grundschutz URL: https://korthex.io/compliance/germany Germany's cryptographic expectations are set by one authority with three faces: BSI TR-02102 defines the algorithm baseline, IT-Grundschutz (building block CON.1) demands the documented Kryptokonzept around it, and the German NIS2 implementation holds critical infrastructure to the state of the art. Korthex covers all three from one scan, with the German enterprise profile activating the BSI channel as its base. #### The German regulatory stack - BSI TR-02102-1: key-size floors (RSA 3000 bit, ECC 250 bit), approved hashes and modes, hybrid PQC guidance - covered by the 16-rule BSI channel - IT-Grundschutz CON.1: the documented Kryptokonzept, with the CBOM as its living inventory annex - NIS2 implementation (KRITIS and important entities): state-of-the-art cryptography evidence via the NIS2 tags the BSI channel carries - Air-gapped and on-premise operation as the deployment default German federal and KRITIS environments typically require #### Recommended configuration German enterprises activate the BSI channel (plus the Korthex-curated fallback); operators under NIS2 add ANSSI for the second EU authority stance. There is deliberately no separate Germany overlay: BSI is the national authority, so the authority channel IS the jurisdiction mapping, and the Grundschutz deep dive covers the audit-evidence workflow. #### Frequently asked questions Q: Why is there no separate Germany rule overlay? A: Because BSI is the German authority: TR-02102 is the national baseline, so the BSI channel carries the jurisdiction. Overlays exist where a region adds rules on top of foreign authorities (UK on NIST, for example). Q: Does this cover KRITIS obligations? A: The cryptography slice, yes: BSI-channel findings carry NIS2 tags, and the recurring CBOM documents the state of the art. Registration, incident reporting and the wider KRITIS duties live outside a scanner. Q: Is Korthex itself a German product? A: Yes. Korthex is built in Germany by Flowence and runs fully on-premise, including air-gapped, so source code never leaves your infrastructure. ### France: ANSSI RGS and OIV Scope URL: https://korthex.io/compliance/france France's cryptographic baseline is ANSSI's RGS Annexe B1; the France overlay adds 4 jurisdiction rules scoped to critical infrastructure (OIV, operateurs d'importance vitale) on top of the 9-rule ANSSI authority channel. Together they are the recommended activation for French enterprises and public-sector suppliers. #### The French stack - ANSSI RGS Annexe B1 v2.0: approved mechanisms, key sizes and validity horizons - the authority channel - OIV scope: stricter expectations for operators of vital importance, carried by the France overlay - NIS2: ANSSI-channel findings carry the NIS2 tag, serving the EU directive from the same scan #### Recommended configuration French enterprises activate the ANSSI channel plus the France overlay. Findings carry the ANSSI-RGS-B framework tag with file and line evidence, and the CBOM gives assessment teams the mechanism inventory RGS-aligned audits start from. #### Frequently asked questions Q: Do I need the overlay if I already run the ANSSI channel? A: For general RGS alignment the authority channel is enough. The overlay matters for OIV-classified infrastructure and suppliers who must meet the stricter critical-infrastructure posture. Q: Does this help with NIS2 in France? A: Yes. The ANSSI channel co-carries the NIS2 framework tag, so the same findings serve both the national baseline and the EU directive. Q: Are RGS references preserved in reports? A: Yes. Findings carry the rule's framework tags and references; reports are in English with the French requirement identifiers preserved. ### United Kingdom: NCSC Foundation Profile URL: https://korthex.io/compliance/united-kingdom The UK overlay carries 4 jurisdiction rules built on the NCSC Foundation Profile, the National Cyber Security Centre's baseline for TLS and cryptographic configuration. The recommended UK activation layers it on top of the NIST authority channel: NIST supplies the algorithm baseline, the overlay supplies the NCSC-specific posture. #### What does the overlay grade? - TLS configuration against the NCSC Foundation Profile: current protocol versions and recommended suites - Cryptographic mechanisms against NCSC guidance for UK enterprise and public-sector use - Tagged NCSC-Foundation on every finding the overlay grades, with file and line evidence #### Recommended configuration UK organizations activate the NIST channel plus the UK overlay. Where NCSC guidance is stricter than the global baseline, the overlay's verdict is visible alongside the NIST stance on the same finding, so procurement and assurance reviews see both. #### Frequently asked questions Q: Why does the UK profile build on NIST? A: NCSC guidance aligns closely with the NIST algorithm baseline; the overlay adds the UK-specific profile on top instead of duplicating an entire authority channel. Q: Is this only about TLS? A: The Foundation Profile is TLS-centred, and TLS findings are where the overlay bites hardest, but its cryptographic-mechanism rules apply to code and configuration findings too. Q: Does the overlay cover Cyber Essentials? A: Cyber Essentials is broader than cryptography. The overlay covers the cryptographic slice of UK assurance work; scheme-level certification stays with your assessor. ### Australia: ASD Information Security Manual URL: https://korthex.io/compliance/australia The Australia overlay carries 4 jurisdiction rules built on the cryptography chapter of the ASD Information Security Manual (ISM), scoped to OFFICIAL-classified data. Findings graded by the overlay carry the ASD-ISM framework tag, giving Australian government entities and their suppliers ISM-aligned evidence with file and line detail. #### What does the ISM expect? - Approved cryptographic algorithms and protocols for OFFICIAL data, per the ISM's cryptography guidelines - Deprecated and legacy mechanisms flagged wherever they appear in code, configuration or TLS - An inventory posture: knowing which cryptography protects which data is the premise of the ISM's controls #### Recommended configuration The Australian Government profile activates the Korthex-curated base plus this overlay. For suppliers working across jurisdictions, the overlay stacks cleanly on NIST or BSI channels, and the CBOM provides the evidence artifact ISM-aligned assessments (including IRAP engagements) ask to see for the cryptography controls. #### Frequently asked questions Q: Does the overlay cover classified levels above OFFICIAL? A: The shipped rules target OFFICIAL-classified data. Higher classifications carry requirements beyond a source-level scanner's scope. Q: Can this support an IRAP assessment? A: It produces the cryptographic evidence slice: which mechanisms are in use, where, and how they grade against the ISM's cryptography guidelines. The assessment itself remains with your IRAP assessor. Q: How current are the ISM rules? A: The overlay follows the same 24-hour signed update cycle as every channel, so ISM guideline changes propagate without a product update. ### Canada: CCCS ITSP.40.111 URL: https://korthex.io/compliance/canada The Canada overlay carries 4 jurisdiction rules built on ITSP.40.111, the Canadian Centre for Cyber Security's catalogue of approved cryptographic algorithms for UNCLASSIFIED and PROTECTED information. The recommended Canadian activation layers it on the NIST channel; findings carry the ITSP-40.111 framework tag. #### What does ITSP.40.111 set? - Approved algorithms, key lengths and usage periods for UNCLASSIFIED and PROTECTED information - Alignment with the NIST algorithm baseline, with Canadian-specific scoping on top - The premise that departments know their cryptographic inventory - which is what the CBOM delivers #### Recommended configuration The Canadian Government profile activates the NIST channel plus this overlay. Where ITSP guidance scopes an algorithm differently from the global baseline, both stances appear on the finding, and the CBOM gives assessors the inventory with file and line evidence. #### Frequently asked questions Q: Which protection levels does the overlay address? A: UNCLASSIFIED and PROTECTED information, following ITSP.40.111's scope. Classified systems carry requirements beyond a source-level scanner. Q: Why pair it with the NIST channel? A: ITSP.40.111 tracks the NIST algorithm baseline closely; the overlay adds the Canadian scoping instead of duplicating the base rules, and both verdicts stay visible per finding. Q: How do updates arrive? A: Through the same 24-hour signed update cycle as every other channel and overlay. ### Korthex GitHub Actions Integration URL: https://korthex.io/integrations/github-actions Korthex ships a GitHub Actions step that scans every push and pull request for weak, broken, deprecated and quantum-vulnerable cryptography. Findings appear inline in the pull request via SARIF and GitHub Code Scanning, and the build fails above the risk threshold you configure. Runs on GitHub-hosted or self-hosted runners, fully on-premise. #### How does the integration work? The Actions step runs the Korthex CLI inside your workflow. The exit code gates the job: you choose the risk threshold (Critical, High, Medium or Low) above which the check fails. The SARIF output feeds GitHub Code Scanning, so findings annotate the exact changed lines in the pull request instead of living in a separate dashboard. Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. For most repositories that keeps the gate fast enough to run on every push rather than nightly. #### What does a pull-request gate catch? - New MD5, SHA-1, DES, 3DES or RC4 usage introduced by a diff or a dependency bump, before it merges - AES-ECB and CBC-without-integrity misuse in changed code - Hardcoded keys, credentials and API tokens, in the diff and in history - TLS configuration regressions: weakened protocol versions, suites or certificates - New quantum-vulnerable RSA / ECC usage, bucketed against FIPS 203 / 204 / 205 - CBOM drift: the cryptographic inventory stays current on every commit #### Self-hosted runners and on-premise operation Korthex runs 100% on-premise, so the step works on self-hosted runners, including GitHub Enterprise Server environments. Source code never leaves your infrastructure; only anonymized metadata is transmitted for the optional dashboard report. #### Beyond GitHub The same gate runs everywhere: a GitLab CI template, a Jenkins pipeline snippet, and a generic CLI exit code for Azure DevOps, CircleCI, Bitbucket Pipelines, Drone and Buildkite. See the CI/CD integration overview for the full pattern. #### Frequently asked questions Q: Does the Korthex step block merges? A: The check fails when findings exceed your configured risk threshold. Combined with GitHub branch protection, a failing check blocks the merge, exactly like a failing test suite. Q: Do findings show up inside the pull request? A: Yes. Korthex emits SARIF, which GitHub Code Scanning renders as inline annotations on the changed lines, plus a summary in the checks tab. Q: How long does the scan add to CI? A: Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. All 18 supported languages are covered in the same pass. Q: Does the runner need internet access? A: No. The scanner runs fully on-premise, including air-gapped self-hosted runners. Only the optional dashboard report transmits anonymized metadata. Q: Which plan includes CI/CD templates? A: CI/CD templates ship with the Community plan and above. The Free plan includes the CLI, which any pipeline can gate on via its exit code. ### CI/CD Cryptography Scanning URL: https://korthex.io/integrations/ci-cd Korthex turns cryptographic compliance into a pipeline gate: scan on every commit, fail the build above a configurable risk threshold, and keep the Cryptographic Bill of Materials current automatically. GitHub Actions, GitLab CI and Jenkins ship ready-made; every other pipeline works through the CLI exit code. 100% on-premise. #### One gate, every pipeline - GitHub Actions: a step with SARIF output into GitHub Code Scanning and inline pull-request findings - GitLab CI: a template with SARIF into the GitLab Security Dashboard - Jenkins: a pipeline snippet gating on the CLI exit code - Azure DevOps, CircleCI, Bitbucket Pipelines, Drone, Buildkite: the generic CLI exit code works in any job - IntelliJ and VS Code plugins surface the same findings inline before code ever reaches the pipeline #### Why gate cryptography in CI? Cryptographic regressions are silent. A dependency bump reintroduces 3DES, a copy-pasted helper brings MD5 back, a config change weakens TLS, and no unit test notices. A per-commit scan makes the regression visible in the pull request that causes it, when it costs minutes to fix instead of an audit finding later. There is a second, newer reason: AI coding assistants rewrite cryptography non-deterministically. Korthex is the deterministic gate behind them: let an assistant refactor, then verify that the result is genuinely compliant, that no weak primitive slipped back in, and that the CBOM changed exactly as expected. #### Performance and rollout Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. For most repositories that is fast enough for every push. Roll out in two steps: run report-only first to see the baseline, then enable the threshold (Critical, High, Medium or Low) once the existing findings are triaged, so the gate never blocks a team on day one. #### Compliance as a byproduct Every pipeline run regenerates the CBOM with per-finding compliance status against NIST FIPS 140-3, FIPS 203 / 204 / 205, BSI IT-Grundschutz, TR-02102, PCI-DSS and ISO 27001. The recurring inventory that PCI DSS 12.3.3 and every migration framework demand stops being a manual exercise. #### Frequently asked questions Q: Which CI systems does Korthex support? A: GitHub Actions, GitLab CI and Jenkins with ready-made integrations; Azure DevOps, CircleCI, Bitbucket Pipelines, Drone, Buildkite and anything else through the generic CLI exit code. Q: How does the gating work? A: The CLI returns a non-zero exit code when findings exceed the configured risk threshold (Critical, High, Medium or Low). The pipeline treats it like a failing test. Q: Which tools consume the SARIF output? A: GitHub Code Scanning (inline pull-request annotations) and the GitLab Security Dashboard; SARIF 2.1 is a standard format, so other SARIF consumers work too. Q: How do I roll this out without breaking builds? A: Start report-only to establish the baseline, triage the existing findings with the migration plan, then enable the threshold. New regressions fail from that point on; legacy findings are burned down on the plan's order. Q: Does the pipeline need internet access? A: No. Scans run fully on-premise, including air-gapped runners. Only the optional dashboard report transmits anonymized metadata. ### Weak Cipher Detection Tool URL: https://korthex.io/weak-cipher-detection A weak cipher is an encryption algorithm or mode that no longer resists modern attacks: DES and 3DES (64-bit blocks, Sweet32), RC4 (keystream biases), Blowfish (64-bit blocks), AES in ECB mode, and CBC without integrity protection. Korthex finds every use across source code in 18 languages, dependencies, binaries, TLS configurations and databases, and proves weakness by emulation against NIST Known-Answer Tests instead of relying on pattern matching. #### What counts as a weak cipher in 2026? - DES: a 56-bit key, brute-forceable on commodity hardware for decades - 3DES: 64-bit blocks make it vulnerable to Sweet32 birthday attacks; NIST disallowed it for encryption after 2023 - RC4: keystream biases; prohibited in TLS by RFC 7465 since 2015 - Blowfish: 64-bit blocks, the same Sweet32 class as 3DES - AES-ECB: identical plaintext blocks produce identical ciphertext, structure leaks through - AES-CBC without integrity protection: padding-oracle territory; use an AEAD mode instead - Weak randomness feeding key or IV material, which silently weakens even strong ciphers #### Detection that follows the data Regex-level scanners flag the call site and stop. Korthex follows the value: dataflow across 16 import hops, taint-classified key sources, and cross-file union-find clustering decide whether a weak primitive actually guards production data or sits in dead code and test fixtures. Extracted cryptography is then graded by emulation against NIST Known-Answer Tests, so weak means proven weak, with a side-channel timing verdict on top. #### Replacement guidance - Symmetric encryption: AES-256-GCM or ChaCha20-Poly1305 (AEAD) as the default replacements - The migration plan orders every finding topologically with file:line, replacement algorithm, effort estimate and dependency order - TLS: modern suite recommendations per finding, mapped to BSI TR-02102-2 and PCI-DSS 4.2.1 #### Keep weak ciphers from coming back A one-time cleanup decays. The CI/CD gate fails builds when a diff or a dependency bump reintroduces a weak cipher, so detection turns into prevention on every commit. #### Frequently asked questions Q: Is 3DES still allowed? A: NIST disallowed 3DES for encryption after 2023 (legacy decryption remains permitted), and PCI DSS strong-cryptography guidance excludes it. Anything still encrypting with 3DES is a finding, not a preference. Q: Is AES-CBC weak? A: CBC itself is not broken, but CBC without integrity protection enables padding-oracle attacks, and real-world usage regularly omits the MAC. Korthex flags CBC-without-integrity and recommends AEAD modes (AES-GCM, ChaCha20-Poly1305). Q: Does it scan binaries too? A: Yes. The binary analyzer detects cipher usage in compiled artifacts, alongside source code in 18 languages, dependencies, TLS configurations and databases. Q: How are false positives handled? A: Every finding carries a taint-based verdict: dataflow decides whether the cipher processes reachable, security-relevant data or lives in dead code and test fixtures, and the finding is prioritized accordingly. Q: Which languages are covered? A: TypeScript, JavaScript, C#, Java, Python, Go, PHP, Ruby, Rust, Kotlin, Scala, C, C++, Swift, Dart, VB.NET, COBOL and Zig. ### MD5 and SHA-1 Scanner for Source Code URL: https://korthex.io/md5-sha1-scanner MD5 has had practical collisions since 2004 and SHA-1 since 2017 (SHAttered), with chosen-prefix collisions since 2020. Broken-hash detection is one detection class of the Korthex crypto vulnerability scanner, not a separate tool: the same scan finds every MD5 and SHA-1 usage across source code in 18 languages, dependencies, binaries, TLS certificates and git history, attaches a taint-based verdict that separates security-critical usage from benign checksums, and generates the migration to SHA-256 or SHA-3. #### Why are MD5 and SHA-1 broken? MD5 collisions were demonstrated in 2004 and are now computable in seconds on commodity hardware; chosen-prefix collisions make forged certificates and documents practical. SHA-1 followed: the SHAttered attack produced real colliding PDFs in 2017, and chosen-prefix collisions arrived in 2020. Both are banned for signatures by NIST and BSI, and certificates signed with either are rejected by every modern browser and operating system. #### Graded by the authorities, not by opinion A broken-hash finding is not Korthex's opinion. Each hit is graded against the authority baseline channels and carries the framework tags it trips: a single MD5 usage can surface FIPS 140-3 (NIST SP 800-131A), BSI TR-02102, NIS2 and PCI DSS 4.0 at once, and the IETF channel attaches the protocol-level references (RFC 6151 for MD5, RFC 6194 for SHA-1). The scan report and the CBOM show exactly which frameworks each finding affects, with file and line. #### Not every MD5 is a vulnerability Cache keys, content de-duplication and non-security checksums do not become exploitable because MD5 is collision-broken. The problem is telling those apart from the MD5 that hashes a password or verifies untrusted input. Korthex attaches a taint-based verdict to every finding: dataflow across 16 import hops decides whether the digest guards something security-relevant, and the finding is prioritized or de-prioritized accordingly. You burn down real risk instead of chasing every hit. #### Where do broken hashes hide? - Password hashing: the worst case, and still common in legacy code paths - Integrity checks of attacker-influenced input: downloads, uploads, webhooks - Certificate signatures: MD5 or SHA-1 signed certificates in internal PKI - HMAC-MD5 and HMAC-SHA1: not collision-affected, but deprecated and on every migration list - Dependencies and binaries: the hash you did not write but still ship - Git history: removed code that still defines what was exposed - Databases: MD5() and SHA1() functions in SQL and stored procedures #### The migration path General hashing migrates to SHA-256 or SHA-3; password storage migrates to a dedicated password-hashing function rather than any fast hash; certificates get re-issued with modern signatures. The Korthex migration plan orders every item topologically with file:line, the concrete replacement, an effort estimate and dependency order, so the cleanup is a plan instead of a grep session. #### Frequently asked questions Q: Is MD5 ever acceptable? A: For non-security purposes like cache keys or de-duplication of trusted data, MD5 is not exploitable. It is unacceptable wherever an attacker can influence the input or benefits from a collision: passwords, signatures, integrity checks. The Korthex taint verdict makes exactly that distinction per finding. Q: Is HMAC-SHA1 broken? A: No practical break exists for HMAC-SHA1, because HMAC does not rely on collision resistance. It is still deprecated by NIST and BSI guidance and should migrate to HMAC-SHA-256 on the normal schedule rather than as an emergency. Q: Does the scanner cover more than source code? A: Yes: dependencies, compiled binaries, TLS certificates, databases and the full git history, across 18 languages. Q: How should password hashes be migrated? A: Not to SHA-256. Password storage belongs in a dedicated password-hashing function; migrate opportunistically on next login and expire stragglers. Korthex flags fast-hash password paths as their own finding class. Q: Which compliance frameworks care? A: All of them: NIST FIPS 140-3 (MD5 and SHA-1 signatures are non-approved), BSI TR-02102 (SHA-256 minimum), PCI DSS (strong cryptography requirements) and ISO 27001 A.8.24. Each finding carries its mapping. ### TLS Certificate Audit Tool, On-Premise URL: https://korthex.io/tls-certificate-audit Korthex audits TLS and PKI material where cloud scanners cannot reach: certificates, keys and TLS configurations inside repositories, containers and internal infrastructure. It flags weak signature algorithms (SHA-1, MD5), legacy key sizes (RSA below 2048, ECC below 256), expired and near-expiry certificates, and insecure protocol and cipher-suite configuration. 100% on-premise. #### Why does TLS auditing have to run on-premise? Public endpoint scanners only see what is exposed to the internet. Internal PKI, mTLS between services, admin planes and air-gapped estates stay dark, and that is where legacy certificates accumulate. The certificates and TLS configuration inside your repositories and containers are the source of truth before anything is deployed; auditing them means auditing the future state, not yesterday's snapshot. #### What does the audit cover? - Signature algorithms: certificates signed with SHA-1 or MD5 - Key sizes: RSA below 2048 bit, elliptic curves below 256 bit - Validity: expired and near-expiry certificates, before they page you - TLS configuration in code and infrastructure files: weak protocol versions, weak cipher suites, disabled verification - Cipher-suite analysis mapped to BSI TR-02102-2 and PCI-DSS requirement 4.2.1 - Quantum exposure: key exchange and signatures bucketed against FIPS 203 / 204, because certificates are on every PQC migration path #### Cross-engine context instead of a flat list A weak certificate is worse when reachable code actually uses it. Korthex correlates TLS findings with the code, configuration, database and git-history engines into one reachability-scored chain, and git history surfaces keys and certificates that were committed once and later removed, which still means they leaked. #### Frequently asked questions Q: Does Korthex probe live endpoints? A: Korthex audits certificates, keys and TLS configuration in repositories, containers and infrastructure files, fully on-premise. For public internet-facing endpoint checks, pair it with an endpoint scanner; for everything internal or pre-deployment, Korthex is the audit. Q: Can it catch certificates before they expire? A: Yes. Expired and near-expiry certificates are findings, and because the scan runs in CI, expiry shows up in a pull request or scheduled run instead of an outage. Q: What about post-quantum TLS? A: Quantum-vulnerable key exchange and signatures are bucketed per finding against ML-KEM (FIPS 203) and ML-DSA (FIPS 204), with the migration plan ordering certificate and configuration changes. Q: Does it work air-gapped? A: Yes. 100% on-premise including air-gapped operation; nothing about your PKI leaves your infrastructure. Q: Which compliance mappings apply? A: BSI TR-02102-2 for TLS configuration, PCI-DSS 4.2.1 for data in transit, NIST FIPS 140-3 approved-algorithm lists, and ISO 27001 A.8.24, attached per finding in the CBOM. ### Hardcoded Keys and Secrets Scanner (SAST) URL: https://korthex.io/hardcoded-secrets-scanner Korthex performs credential scanning across source code in 18 languages, configuration files and the entire git history: hardcoded cryptographic keys, API tokens, passwords and private keys, including secrets that were committed once and later removed. Taint classification shows where every key originates, and dataflow across 16 import hops separates real leaks from test fixtures. #### What does it find, and what replaces it? - Hardcoded symmetric keys and private keys in source and configuration - API tokens and cloud credentials committed to the repository - Passwords and connection strings in configuration files - Private keys and certificates checked into version control - Secrets in git history: removed from HEAD, still recoverable from every clone - Key material assembled across files, followed through up to 16 import hops #### Why does git history matter? A secret that was committed and later deleted is not gone: it lives in every clone, every fork and every backup of the repository. Deleting the line changes nothing about the exposure; rotation is the only fix. Korthex scans the full history and flags historical leaks separately, so you know exactly which credentials to rotate instead of guessing. #### Fewer false positives than pure pattern scanners Pattern-only secret scanners are fast and broad, and they drown teams in test fixtures and dummy keys. Korthex adds provenance: taint classification records where a key originates (a literal in code, a config file, an environment variable, a secret store), and dataflow decides whether it reaches real cryptographic use. A dummy key in a test fixture gets a different verdict than a production credential, and the verdict is attached to the finding. #### From finding to fix Findings map to the practical fix: move the secret to environment or a secret store, rotate what leaked, and let the CI/CD gate fail any pull request that introduces a new hardcoded credential. Secrets findings live in the same CBOM as the rest of your cryptography, with severity, compliance mapping and file:line evidence. #### Frequently asked questions Q: How is this different from dedicated secret scanners like gitleaks or truffleHog? A: Those are good, fast open-source secret scanners built on patterns and entropy. Korthex integrates secrets into a full cryptographic inventory: taint-classified provenance for every key, dataflow to real usage, a verdict that separates fixtures from leaks, and the same CBOM, compliance mapping and migration plan as every other cryptographic finding. Q: Does it scan the entire git history? A: Yes. Credential scanning covers source, configuration and git history, so secrets that were committed and later removed are still found and flagged for rotation. Q: What should I do after a secret is found? A: Rotate the credential first: history means it already leaked to every clone. Then move it to an environment variable or secret store, and enable the CI gate so the next hardcoded secret fails the pull request instead of landing. Q: Does the scanner send my code or secrets anywhere? A: No. Korthex runs 100% on-premise, including air-gapped. Only anonymized metadata is transmitted for the optional dashboard report. Q: Which compliance requirements does this serve? A: Hardcoded credentials violate key-management requirements across frameworks: PCI DSS 3.6 / 8.3.2, ISO 27001 A.8.24, BSI CON.1 and NIST guidance. Each finding carries its mapping in the CBOM. ### Crypto Vulnerability Scanner CLI URL: https://korthex.io/crypto-vulnerability-scanner Korthex is a cryptography vulnerability scanner built CLI-first: run one command locally or in CI, get every cryptographic weakness across source code in 18 languages, dependencies, binaries, TLS certificates, databases and git history, a gateable exit code, and a CBOM export in CycloneDX, SARIF, JSON or PDF. Scan duration estimated per repository and machine at korthex.io/scan-duration. 100% on-premise. #### What does one scan cover? - Weak and broken primitives: MD5, SHA-1, DES, 3DES, RC4, Blowfish - Misuse of strong primitives: AES-ECB, CBC without integrity, missing IVs, key reuse, weak randomness - Hardcoded keys, credentials and API tokens, including git history - TLS and PKI: weak certificate signatures, short keys, expiry, insecure configuration - Database and storage-layer cryptography state - Quantum-vulnerable RSA, ECC, Diffie-Hellman and DSA, bucketed against FIPS 203 / 204 / 205 #### CLI-first by design The exit code gates any pipeline; the formats feed any toolchain: CycloneDX and JSON for machines, SARIF for code-scanning UIs, PDF for auditors, plus the native .kxr format. It runs on Windows, Linux and macOS, works air-gapped, and the IntelliJ and VS Code plugins surface the same findings inline while you type. The dashboard is optional; only anonymized metadata ever leaves the machine, never source. #### Five engines behind one command Five correlating engines (Scanner, Context, KorthexNN, plus the binary and TLS / PKI analyzers) read the codebase as one pass. A 2-pass context engine adds dataflow tracking, taint analysis and cross-file union-find clustering, following values across 16 import hops, so findings reflect reachable reality instead of call-site pattern matches. Extracted cryptography is graded by emulation against NIST Known-Answer Tests: weak is proven, not guessed. #### Start free The Free plan includes 10 scans per month with up to 1,000 files per scan, one seat, no credit card: enough for open-source projects and a serious evaluation. Paid plans add scan volume, migration-plan generation, CI/CD templates and compliance reports. #### Detection deep dives - Weak Cipher Detection (https://korthex.io/weak-cipher-detection) - DES, 3DES (Sweet32), RC4, Blowfish, AES-ECB, CBC without integrity - MD5 / SHA-1 Detection (https://korthex.io/md5-sha1-scanner) - Broken hashes with taint verdicts and SHA-256 / SHA-3 migration - TLS Certificate Audit (https://korthex.io/tls-certificate-audit) - Certificates, keys and TLS configuration, fully on-premise - Hardcoded Keys / Secrets (https://korthex.io/hardcoded-secrets-scanner) - Credentials in source, config and full git history #### Frequently asked questions Q: Which platforms does the CLI run on? A: Windows, Linux and macOS, fully on-premise, including air-gapped operation. Q: Is there a free version? A: Yes. The Free plan offers 10 scans per month, up to 1,000 files per scan and one seat, for open-source and solo developers. Q: What output formats exist? A: CycloneDX, SARIF, JSON, PDF and the native .kxr format, all with file:line evidence, severity, taint verdict and compliance status per finding. Q: How fast is a scan? A: Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. All 18 supported languages are covered in the same pass. Q: Which languages are supported? A: TypeScript, JavaScript, C#, Java, Python, Go, PHP, Ruby, Rust, Kotlin, Scala, C, C++, Swift, Dart, VB.NET, COBOL and Zig. ### Crypto Agility Tool URL: https://korthex.io/crypto-agility Crypto agility is the capability to replace cryptographic algorithms, keys and protocols quickly, without breaking running systems, when standards change or an algorithm falls. Korthex ships the four technical building blocks: a current inventory (CBOM), risk and quantum-exposure scoring, a topologically-ordered migration plan with impact simulation, and a CI/CD gate that keeps the inventory honest on every commit. #### What does crypto agility actually require? NIST runs a dedicated crypto-agility project for a reason: the post-quantum transition is the first industry-wide test of whether organizations can swap algorithms at all. Four capabilities decide it: knowing what you run (inventory), knowing what matters (scoring), knowing what to change in which order (migration planning), and making sure it stays fixed (continuous gating). Most organizations discover during the PQC transition that they lack the first one. #### Inventory first: the CBOM You cannot swap what you cannot see. The Korthex CBOM inventories every cryptographic asset across source code in 18 languages, dependencies, binaries, TLS and PKI certificates, databases and git history, with file:line evidence and a taint verdict per entry, exported as CycloneDX, SARIF, JSON or PDF. That is the foundation every agility framework, from NIST to the EU PQC roadmap, names as step one. #### Scoring and simulation before change Every finding carries severity, a taint-based reachability verdict and a post-quantum bucket. The migration plan orders changes topologically, with the replacement algorithm, an effort estimate in hours and the dependency order per item, and the impact simulation shows what a change touches before you make it. Swapping an algorithm stops being a leap of faith. #### Agility as a pipeline property An inventory from last quarter is trivia. The CI/CD gate regenerates the CBOM on every commit and fails builds that reintroduce weak or newly-deprecated cryptography, which turns agility from a project into a property of the pipeline. It also makes AI-assisted refactoring safe: assistants rewrite cryptography non-deterministically, and the deterministic gate verifies the result every time. #### What tooling cannot do Crypto agility also has an organizational half: ownership, key-management processes and vendor contracts. Korthex covers the technical half completely (visibility, scoring, planning, gating) and produces the evidence the organizational half runs on. #### Frequently asked questions Q: How does crypto agility relate to post-quantum migration? A: PQC migration is the first industry-wide exercise of crypto agility: RSA and ECC must give way to ML-KEM and ML-DSA on regulator timelines (NIST IR 8547: deprecated after 2030, disallowed after 2035). An organization that builds the inventory-score-migrate-gate loop for PQC keeps it for every future algorithm change. Q: Is a cryptographic inventory required? A: Increasingly yes. PCI DSS 4.0 requirement 12.3.3 mandates a documented cipher-suite and protocol inventory, and NIST, BSI and EU migration guidance all define inventory as the first step. The CBOM is the machine-readable standard form. Q: How often should the inventory refresh? A: Every commit. A scan is fast enough to run per commit on most repositories, so the CI/CD gate regenerates the CBOM continuously instead of annually. Scan duration estimated per repository and machine at korthex.io/scan-duration. Q: Does Korthex rewrite the code automatically? A: It generates the migration plan with per-item file:line, replacement algorithm, effort and dependency order, plus an impact simulation. Automated rewriting is on the roadmap (V2); today the plan drives your engineers or your AI assistant, and the gate verifies the result deterministically. ### How long does a scan actually take? URL: https://korthex.io/scan-duration Enter your project and your machine. You get a span for the first scan and a span for every scan after it, together with the measurements the span is built from. Where the model runs out of evidence it says so, instead of extrapolating. #### What the number is built from The calculator is a cost model over measured runs, not a marketing figure with a slider attached. Every factor is either a measurement with its input shape named, or a declared assumption, and the page states which is which for each one. The interactive version needs JavaScript; the model itself is below either way. - Project size: the code, context, AST, TLS, config and database path grows as files raised to about 1.37. Measured at two sizes: 900 files across 12,101,499 bytes and all 18 languages in 11.052 s, and 25,684 files with about 7 million lines in 1,080.5 s. Two points fix the exponent exactly and say nothing about the shape between them. - History depth: about 18.9 ms per commit, linear. Measured once, at 674,780 commits in a 5.7 GB pack, taking 12,759 s. For most repositories this is the single largest term in the estimate. - CPU cores: Amdahl scaling with a 13.4 % serial share, fitted through one measured ratio. Two workers to sixteen gave a 3.02 times wall-clock speedup while CPU efficiency fell to 38 %. The consequence is a ceiling: an unlimited core count buys at most 1.41 times over the sixteen-core reference machine. - RAM: a threshold, not a factor. Demand is about 56 kB per file plus 27 kB per commit, derived from a 110 MB peak on the small corpus and a 19.5 GB peak on the large one. Above the demand, more RAM changes nothing. Below it the scan degrades, and below half of it the calculator declines to give a figure, because at that ratio the reference run aborted with an allocation failure rather than merely slowing down. - Storage: it acts almost exclusively on the history phase. The code path cannot be storage-bound, since it consumes source at about 1.1 MB/s, which even a hard disk outruns by two orders of magnitude. Reading a multi-gigabyte pack with one random access per commit is a different regime. Only the reference NVMe was measured; the other device classes are declared figures. - Follow-up scan: not a fixed percentage. A re-run with nothing changed still costs a floor of roughly 17 % of the first scan, and the changed share of the files decides the rest. Measured at both ends: 40 parse-heavy modules with one changed went from 1.626 s to 0.553 s, and the reference corpus re-run unchanged went from about 1,080 s to about 180 s. - GPU: no factor and deliberately no control. #### Why there is no GPU slider? There is no GPU control here because there is no GPU effect to control. The two phases that dominate a scan are a git tree diff and a set of language parsers. Both are branch-heavy work with unpredictable memory access, which is precisely what a GPU is worst at. Korthex does dispatch one workload to the GPU, a delta hash that is bit-identical to the CPU path and falls back to it on any failure, and it sits on neither of those two critical paths. A slider here would advertise a lever that does not exist. #### The reference machine and the reference corpus Every timing in the model comes from one host and two corpora. Naming them is the point: a duration without its input shape is an illustration that looks like a specification. - Host: 8 physical and 16 logical cores, 30.9 GB RAM, a Samsung 980 PRO NVMe, Windows 11. - Large corpus: LibreOffice core, 25,684 source files, about 7 million lines, 674,780 commits, a 5.7 GB pack. Cold and complete it took 3 h 50 min, split into git history 12,759 s, context 1,009 s, AST 67 s, TLS 1.2 s, config 1.0 s and database 2.3 s. - Small corpus: the committed performance baseline of 900 files, 12,101,499 bytes across all 18 languages. Code engine wall-clock 11.052 s, peak resident set 110 MB. #### Where this model is thin Stated plainly, because a calculator that hides its weak spots is a claim with a slider attached. - Two measured project sizes fix the exponent exactly and say nothing about the shape between them. Anything outside 900 to 25,684 files is extrapolation. - The per-commit cost comes from a single repository with a single pack. A history with wide trees, or with many tiny commits, will not match it. - Only the reference NVMe was measured. SATA, hard disk and network figures are declared device-class values, and the hard-disk history estimate is a floor, since it assumes only one pack access per commit. - The core curve is fitted through one measured ratio. It reproduces that ratio exactly and is unverified everywhere else. - For RAM, the demand and the threshold are measured. The slope of the slowdown below the threshold is not. - The span itself is a declared assumption. The project performance gate treats a drop to half throughput on the same corpus and the same machine as still inside tolerance, so a narrower span would claim more stability than the gate assumes. #### Frequently asked questions Q: How long does a Korthex scan take? A: It depends on three things, and the calculator on this page shows all three: how much source there is, how deep the git history is, and what the machine is. For a 500,000 line codebase with a short history on a current sixteen-core workstation the model puts a first scan at roughly one and a half to three minutes. The same codebase with 50,000 commits of history is a quarter of an hour, because history is usually the dominant term. Q: Is a scan of 50,000 to 500,000 lines under two minutes? A: For the source analysis alone, comfortably: the model at korthex.io/scan-duration puts 500,000 lines at about half a minute on the reference machine, and 50,000 lines at a second or two. Whether the whole run stays under two minutes is decided by the git history, which is not part of that figure and is frequently larger than it. That is why the flat promise was replaced by the korthex.io/scan-duration calculator. Q: Does more RAM make the scan faster? A: Only up to the point where there is enough. RAM is a threshold, not a throttle: above what the working set needs, adding more changes nothing measurable. Below it the scan degrades, and far below it the run can fail outright rather than just take longer, which is what happened on the reference corpus at a 19.5 GB peak. Q: Does a GPU speed up a Korthex scan? A: No, and the calculator deliberately offers no GPU control. Git tree diffing and language parsing are branch-heavy work with unpredictable memory access, which is the workload class a GPU handles worst. Korthex does run one hash workload on the GPU, bit-identical to the CPU path and falling back to it, and it is not on the critical path of either dominant phase. Q: How much faster is a follow-up scan? A: It is not a fixed percentage, which is why the calculator asks how much changed. A re-run with nothing changed still pays a floor of roughly 17 % of the first scan. From there the cost rises with the share of files that changed, and with the number of new commits, up to the cost of a cold scan when everything changed. ### Who builds Korthex URL: https://korthex.io/about Korthex is being developed by Flowence Infrastructure, a company founded in 2025 and based in Germany. Currently, Korthex is being developed solely by its founder. This means he writes the scanner, curates the baseline rules, and maintains this website. #### Why this product exists? Every organisation knows roughly which libraries it depends on. Almost none can answer which cipher, which key length, and which certificate is actually in use, at which line of which file. That question became urgent the moment NIST published FIPS 203, 204 and 205, because a migration plan needs an inventory first, and the inventory did not exist. Korthex was built to answer it from the source rather than from the network: static analysis over 18 languages, binaries, databases, TLS material and git history, on the machine that holds the code. That constraint - nothing leaves the machine - is the reason the product is on-premise rather than SaaS, and it is why there is no cloud tier to sign up for. #### Who is responsible for what - Rule curation: which authority baseline a finding is graded against, and in which order. The priority chain is NIST, then BSI, IETF, OWASP, CISA, ANSSI, and last the Korthex-curated set. - The baseline registry: 11,664 rules across 25 headers, re-checked on a 24-hour cycle and shipped as signed updates. - The published ladder: 35 documented status rows, held against the engine's own enum by a build gate that fails on any drift. - This site: every page, both languages, and the build gates that keep its claims honest. #### How to check the claims rather than trust them Three pages carry the evidence rather than the assertion, and they are the ones worth reading before the marketing copy. - Scan duration: a cost model derived from named measurements, including the point where the model stops and says so. - Editorial standards: the build gates that refuse to ship a claim without its evidence, named individually. - Measurement methodology: how accuracy is defined, what is measured against, and what the measurement does not show. #### Contact Correction, question, or a claim on this site you can disprove: contact@flowencehq.com. Security reports have their own channel, described on the security page and in [/.well-known/security.txt](/.well-known/security.txt). The full provider identification, including postal address and the person responsible for editorial content under Section 18(2) MStV, is in the imprint. #### Frequently asked questions Q: Who develops Korthex? A: Hendrik Schneider, at Flowence Infrastructure - a sole proprietorship registered in Recklinghausen, Germany, founded in 2025. Korthex is one of its products. Q: Is Korthex an open-source project? A: No. Korthex is proprietary software with a free tier that carries the complete detection engine. The rule baselines it grades against are public standards - NIST, BSI, IETF, OWASP, CISA and ANSSI - and every finding names the rule it came from. Q: Where is Korthex developed? A: In Germany. That matters for two of its users in particular: BSI TR-02102 and IT-Grundschutz are the baseline the product was designed around first, and the on-premise architecture means no scan data crosses a border because none of it leaves the machine. ### How this site checks its own claims URL: https://korthex.io/editorial-standards Marketing pages age badly because nothing forces them to stay true. This site is built with the opposite arrangement: a set of build gates reads the published text, compares it against the thing it describes, and fails the build when the two disagree. This page names them, because a standard nobody can inspect is not a standard. #### The rule every number follows A figure on this site is one of three things, and the page says which: a measurement we took, with the input named; a value from a published standard, with the standard named; or a stated assumption. Nothing is a round number chosen because it reads well. Where a claim cannot be supported that way, it is not made. The scan-duration page is the clearest example - it publishes the two measurement points that fix its model and then says explicitly that they say nothing about the shape of the curve between them. #### The gates that enforce it Each of these runs on every build. A failure stops the deploy; none of them can be waved through. #### When something is wrong - Report it to contact@flowencehq.com. A claim on this site that you can disprove is the most useful mail we get. - Factual corrections are made at the source, so the change propagates to every surface that repeats the fact - page text, structured data, llms.txt and the documentation corpus. - A correction that changes the meaning of a published figure is noted in the development changelog with the date, rather than edited away silently. - Where the correction reveals a gap a gate should have caught, the gate is extended. That is how most of the list above came to exist. #### What this does not cover These gates check consistency and evidence, not judgement. They cannot tell you that a rule is the right rule, only that the site describes the rule the engine actually applies. Detection quality is a separate question with its own measurement, described on the methodology page. #### Frequently asked questions Q: How does Korthex handle corrections? A: Corrections are made at the source so every surface that repeats the fact changes together, and a correction that changes the meaning of a published figure is recorded in the changelog with its date rather than edited away. Q: Are the claims on the Korthex site verified? A: By build gates that run on every deploy. A duration claim without a pointer to its measurement, a documented rule that no longer matches the engine, or a CLI command that does not exist all fail the build rather than shipping. ### Reporting a vulnerability URL: https://korthex.io/security Korthex is a cryptography scanner, so a flaw in it is a flaw in something people use to judge their own security. Reports are welcome, including ones that show the scanner is wrong. This page is the policy referenced from [/.well-known/security.txt](/.well-known/security.txt). #### How to report - Email contact@flowencehq.com with 'security' in the subject line. Reports are read in German and English. - Include the affected component and version, what you observed, and the smallest reproduction you have. A scan artifact is useful; a scan artifact from someone else's codebase is not - do not send data you are not entitled to share. - The machine-readable contact record is at [/.well-known/security.txt](/.well-known/security.txt) per RFC 9116. - Please give us the chance to ship a fix before publishing. There is no bounty programme; there is an acknowledgement, and a named credit in the changelog if you want one. #### Published response targets These are the targets from the Korthex Service Level Agreement, section 4.4. The clock starts when the vulnerability is verified, not when the mail arrives. #### Scope - In scope: the Korthex desktop application, the command-line interface, the SDKs, the license portal, and this website. - In scope and specifically wanted: a case where the scanner reports a finding that is not real, or misses one that is. Detection correctness is a security property of this product, not a quality metric. - Out of scope: findings that require a compromised host, social engineering, volumetric denial of service, and reports generated by a scanner without a demonstrated impact. - Out of scope: the third-party standards Korthex grades against. A disagreement with BSI TR-02102 is a matter for the BSI. #### Regulatory reporting Where a vulnerability in Korthex is being actively exploited, or a severe incident affects the security of the product, the provider submits an early warning to the coordinating CSIRT and to ENISA within 24 hours of becoming aware, followed by a notification within 72 hours. Affected customers are informed without undue delay at the address held in their account. The full text is in the SLA. #### Frequently asked questions Q: How do I report a security vulnerability in Korthex? A: Email contact@flowencehq.com with 'security' in the subject, including the affected component, version and a minimal reproduction. The machine-readable contact record is at [https://korthex.io/.well-known/security.txt](https://korthex.io/.well-known/security.txt). Q: Does Korthex pay a bug bounty? A: No. There is no bounty programme. Valid reports receive an acknowledgement and, if you want one, a named credit in the changelog. Q: How quickly does Korthex patch a critical vulnerability? A: The published target is 72 hours for Enterprise and 7 days for Business at CVSS 9.0-10.0, measured from verification of the vulnerability. The full severity table is in section 4.4 of the SLA. ### How detection accuracy is measured URL: https://korthex.io/methodology A scanner that says it reduces false positives without publishing a number is making the same unfalsifiable claim as every other scanner. Korthex ships an Accuracy Engine that measures detection against a ground-truth corpus, and it is the same engine that gates its own releases. This page is the method. The figures it produces are at the bottom, including the ones that are not flattering. #### What is being measured Three ratios, computed from three counts. A true positive is a finding the scanner reported that the ground truth also holds. A false positive is one it reported that the ground truth does not. A false negative is one the ground truth holds that the scanner did not report. #### What ground truth is here A ground-truth file is a hand-verified inventory of the cryptography in a corpus: for each occurrence, the algorithm, the file, and the line. It is JSON, it is checked in, and it is the thing the scanner is graded against - which makes it the weakest link in the whole method, because a ground truth that is wrong grades a correct scanner as broken. That is why the corpus is named in every published figure. A precision number without a named corpus is not a measurement of a scanner, it is a measurement of a corpus nobody can inspect. #### The four modes - Scanner: the default. Scan output against the ground truth, one corpus, one run. - Migration: the same comparison across a migration - the before state in the expected slot, the after state in the actual one. It measures whether the plan worked, not whether the scan was right. - False positives: run against a corpus that is known to be clean. Every finding is by definition a false positive, so this mode isolates the rate without a ground truth having to enumerate the true ones. - Corpus: an aggregate across a whole corpus rather than a single scan, with a wider line window. #### The tolerances, and the one that is deliberately absent Source code moves. A refactor that shifts a call two lines down is not a detection regression, so matching allows a configurable line tolerance. Algorithm names are normalised as well: MD5Sum, md5 and MD-5 collapse to one canonical match, because a scanner is not wrong for spelling it differently than the ground-truth author did. One collapse is refused on purpose: two findings both labelled Unknown never match each other. It would be trivially easy to let them, and it would inflate every precision number on this page. An unidentified algorithm on both sides is two open questions, not one answer. #### What these numbers do not show - They do not generalise to your codebase. A ratio measured on a named corpus describes that corpus. A codebase with different languages, different libraries or unusual crypto wrappers will score differently, and possibly worse. - They do not measure severity. A missed hardcoded private key and a missed MD5 checksum count the same in recall, and they are not the same finding. - They do not measure the compliance mapping. Whether a finding is graded against the right BSI or NIST rule is a separate question, held by a different build gate. - A single run is a point, not a trend. The engine keeps a run history precisely because one measurement cannot tell you whether the scanner is improving. #### Why the engine gates the release? Cryptographic detection is full of edge cases, and a change to the AST analysis can fix five findings while breaking twelve. That failure is silent unless something measures it, so the accuracy run is a pass/fail step in the release pipeline by default: a run whose recall falls under 0.8 exits non-zero without any threshold being passed on the command line. Measuring without gating is possible, but it has to be asked for. The run history that supports this is deliberately narrow. Each record holds the timestamp, the mode, the line tolerance and the metrics - and never a finding, a file path or a source excerpt. That is what makes it safe to keep on a shared CI runner, and it is the same on-premise reasoning the rest of the product follows. #### Frequently asked questions Q: What is the false-positive rate of Korthex? A: It is measured per corpus rather than claimed as one number, using a corpus known to be clean, so that every finding in that run is by definition a false positive. The published figures and the corpus each one was measured on are at the bottom of this page. Q: How is scanner accuracy calculated? A: Precision is tp/(tp+fp), recall is tp/(tp+fn), and F1 is their harmonic mean, where a true positive is a finding that the hand-verified ground truth also holds at that file and line, within a configurable line tolerance. Q: Do these accuracy numbers apply to my codebase? A: No. A ratio measured against a named corpus describes that corpus. Different languages, libraries or crypto wrappers will produce different numbers, which is why the corpus is named next to every figure rather than left implicit. Q: Does Korthex publish measurements that got worse? A: Yes - that is the point of publishing them. A methodology page that can only show improvements is a brochure. Publication is a deliberate step for each measurement, but the criterion is that the run was valid, not that the result was good. ### Korthex Pricing and Licensing URL: https://korthex.io/license Korthex is licensed in four plans. Pricing for the three paid tiers is not final and no figure is published yet. Every plan runs entirely on your own infrastructure - source code, binaries, and scan results never leave the machine, on the free tier as much as on the enterprise one. What the plans differ in is throughput, seats, and the reporting built on top. #### Free - EUR 0, free forever For open-source projects and solo developers evaluating Korthex on a real repository. - 10 scans per month - 1,000 files per scan - 1 seat - Full detection engine - no reduced rule set #### Community - price to be announced The first paid tier, aimed at a single team maintaining one product. Pricing for this tier is not final and is not published yet. - 50 scans per month - 5,000 files per scan - 1 seat - Migration plan generation - CI/CD templates, 1,000 runs #### Business - price to be announced For an organisation scanning several products under a shared compliance obligation. Pricing for this tier is not final and is not published yet. - 250 scans per month - 10,000 files per scan - 5 seats - Migration plan generation - CI/CD templates, 2,500 runs - Compliance Report #### Enterprise - price to be announced No volume ceiling, for estates where the scan target is the whole codebase rather than one repository. Pricing for this tier is not final and is not published yet. - Unlimited scans - Unlimited files per scan - 10 seats - Migration plan generation - CI/CD templates, 25,000 runs - Priority support #### What every plan includes - 100% on-premise execution - no telemetry of scan content, no source upload - Source scanning across 18 languages, plus binaries, databases, TLS/PKI and git history - CBOM output in CycloneDX, SARIF, JSON, PDF and the native .kxr format - Compliance mapping to NIST FIPS 140-3/203/204/205, BSI TR-02102, PCI-DSS and ISO 27001 - Air-gapped operation - the scanner needs no network access at run time #### Frequently asked questions Q: What does Korthex cost? A: Four plans. Free is EUR 0 and free forever. Community, Business and Enterprise are paid tiers whose pricing is not final yet - no figure is published because none has been decided. Korthex is in open beta and access is currently free. Q: Is there a free version of Korthex? A: Yes. The Free plan is free forever and carries the complete detection engine - 10 scans per month, up to 1,000 files per scan, one seat. It is not a time-limited trial and the rule set is not reduced. Q: Does Korthex send my source code anywhere? A: No. Every plan runs 100% on-premise. Source code, binaries and scan results stay on the machine that runs the scan, and Korthex operates in an air-gapped environment without network access. Q: What is a seat in Korthex licensing? A: A seat is one named user who can run scans and open results. Free and Community include one seat, Business five, Enterprise ten. Q: What happens when I exceed my monthly scan quota? A: Scans beyond the plan quota are refused until the monthly counter resets; existing results stay accessible. The quota is per calendar month and counts completed scans. ## Comparisons Each comparison is objective and dated: claims reflect the competitors' public documentation, capabilities they genuinely offer are stated as such, a dedicated section explains where the competitor is the right tool, and trademarks are used for identification only. ### Korthex vs SandboxAQ AQtive Guard: Source vs Runtime URL: https://korthex.io/vs-sandboxaq Korthex reads the source of truth before deployment: static analysis across 18 languages with file:line evidence, weakness proven by emulation against NIST Known-Answer Tests, and a dependency-ordered migration plan, entirely on-premise and self-serve. SandboxAQ's AQtive Guard attacks the same problem, unmanaged cryptography, from the opposite vantage point: it discovers cryptography already running in the estate, network traffic, runtime library calls, filesystems, keys and certificates, at organizational scale. Axis by axis: KAT emulation proof vs policy-based identification against FIPS/PCI-DSS; a topologically-ordered migration plan with impact simulation vs AI-assisted prioritization; five CBOM export formats with a per-finding post-quantum bucket vs CBOM generation aligned with CNSA 2.0; self-serve CLI with a free tier vs enterprise sales-led engagement (30-day trial on request); on-premise / air-gapped by default vs an integrated enterprise platform; pre-deploy source truth vs running-estate discovery; file:line dataflow evidence vs asset-level owner mapping. The two vantage points are complementary; some organizations run both. ### Korthex vs Snyk: Crypto-Specialized vs General SAST URL: https://korthex.io/vs-snyk Snyk is a strong general-purpose SAST and dependency scanner - its DeepCode engine does real taint analysis for injection-class vulnerabilities, it flags hardcoded secrets and weak algorithms, and it generates SBOMs. Korthex does something different: it specializes entirely in cryptography, inventorying every primitive, scoring its weakness and quantum exposure, and generating the migration plan. Axis by axis on cryptography: cross-engine attack-paths vs per-scan-type findings; cryptographic value tracking across 16 import hops vs injection-focused taint analysis; taint-classified key provenance vs hardcoded-secret detection; CBOM-PQC export vs dependency SBOMs; a dependency-ordered migration plan with simulation vs automated dependency fix PRs; and offensive verification against NIST Known-Answer Tests, which no general SAST performs. Most teams run both: a SAST tool for code-logic vulnerabilities and Korthex for the cryptographic inventory. Comparison based on public vendor documentation as of 2026-07-10. ### Korthex vs SonarQube: Crypto Inventory vs Code Quality URL: https://korthex.io/vs-sonarqube SonarQube is a capable code-quality and SAST platform - bugs, code smells, coverage gates, taint analysis for injection rules in the commercial editions, and configuration rules that flag weak crypto parameters and TLS versions. Korthex is not a code-quality tool. It specializes in cryptography: a cross-engine inventory, post-quantum readiness scoring, a migration plan, and offensive verification. Axis by axis on cryptography: cross-engine attack-paths vs per-project issues; cryptographic value tracking across 16 import hops vs injection-focused taint analysis; key-provenance classification vs parameter-level configuration rules; CBOM-PQC export vs no cryptographic inventory; a dependency-ordered migration plan vs finding-level guidance; and offensive verification against NIST Known-Answer Tests. Most teams run both: SonarQube as the quality gate and Korthex for the cryptographic inventory. Comparison based on public vendor documentation as of 2026-07-10. ### Korthex vs Semgrep: Crypto Reachability vs Patterns URL: https://korthex.io/vs-semgrep Semgrep is a fast, hackable rule engine whose Pro engine adds genuine cross-file taint analysis, plus a secrets product that validates live credentials across hundreds of credential types. Korthex is not a rule engine you maintain - it specializes in cryptography out of the box: following values across import hops, correlating across engines, exporting a CBOM, planning the migration, and proving weakness by emulation. Axis by axis on cryptography: cross-engine attack-paths vs rule-based per-scan findings; cryptographic value tracking vs injection-focused cross-file taint analysis; key-provenance classification vs validated secrets detection; CBOM-PQC export vs no cryptographic inventory; a dependency-ordered migration plan vs finding-level guidance and autofix rules; and offensive verification against NIST Known-Answer Tests. Comparison based on public vendor documentation as of 2026-07-10. ## Documentation ### Getting Started (FUNDAMENTALS) URL: https://korthex.io/docs/getting-started Korthex is an automated cryptographic discovery and analysis platform. It scans your entire codebase - source files, binaries, certificates, dependencies, and configuration - to produce a complete Cryptographic Bill of Materials (CBOM) with severity-ranked findings and compliance mapping. Whether you need to prepare for post-quantum migration, satisfy NIST or BSI audit requirements, or simply understand where cryptography lives in your software, Korthex gives you a single, automated workflow to get there. Documentation Notice This documentation reflects the current production-ready state of Korthex. Features visible on the website that are not yet documented here are actively in development and will be added once they reach a stable release. Until the official launch on 12.08.2026 , the documentation is updated continuously as features are finalized. Last update: 08.07.2026 #### Overview Korthex is an integrated platform for understanding and improving the cryptography in your software. It scans, classifies, reports, and (in V2) migrates - entirely on-device, with your source code never leaving the machine. Scanning & analysis Source-code scanning across 18 languages: JavaScript, TypeScript, C#, Java, Python, Go, PHP, Ruby, Rust, Kotlin, Scala, C++, C, Swift, Dart, VB.NET, COBOL, and Zig. Binary scanning of compiled artifacts (.NET IL, JVM bytecode, native PE/ELF binaries) when source isn't available. Database scanning across 41 database types (relational, NoSQL, cloud, in-memory, and KMS). Configuration scanning for hardcoded secrets, weak settings, and TLS misconfigurations. Git-history scanning for previously committed secrets, removed crypto, and key rotations. Runtime observation via the Runtime Agent - what your binary actually calls at runtime, not just what the source says. Context-aware analysis via the Context Engine: dataflow, taint tracking, and cross-file clustering to dramatically reduce false positives. Neural Network assistance - on-device ML hints classify ambiguous patterns and identify custom crypto wrappers. Understanding what you have Inventory Engine - an authoritative crypto-asset inventory with CycloneDX CBOM and SPDX SBOM export. Dataflow Engine - a graph view of how keys, certificates, and crypto values flow across your code, configs, infrastructure, and runtime. Impact Engine - per-finding business-impact scoring with audience-tailored reports for CISO, CTO, CFO, and board. Baseline Registry - the central truth source: 11 500+ algorithm rules classifying every primitive as recommended, acceptable, deprecated, or disallowed. Governance & remediation Policy Engine - CI/CD gate with BLOCK / WARN / ALLOW verdicts. Configurable per organization via .kxp or its plain-JSON equivalent. Planner Engine - sequenced migration plans with engineer-hour estimates and deadline-driven prioritization. Auto Migration (V2) - context-aware automatic code rewrites with diff-review workflow and built-in rollback. V1 supports plan + simulate today. Exploit Engine - turns findings into demonstrable proof-of-concept evidence on source or binary targets (gated by license + Terms of Service). Accuracy Engine - measurement framework (precision / recall / F1) for regression-testing scan quality. Compliance, output & integration Compliance mapping - automatic NIST FIPS 203/204/205, BSI IT-Grundschutz, plus per-finding citations. Output formats - native encrypted .krx reports, CycloneDX CBOM, SPDX SBOM, SARIF 2.1.0. Plain JSON and PDF export is an Enterprise-tier feature. CI/CD-native - SARIF output drops directly into GitHub Code Scanning and Azure DevOps; JUnit XML for generic runners. IDE plugins for IntelliJ IDEA and Visual Studio Code with inline findings and real-time scanning. Web Dashboard for projects, trends, compliance, dataflow graphs, plan management. Self-hostable in Enterprise. Korthex Remote - Android mobile companion for live monitoring, remote scan triggering, and panic alerts. Mesh-Relay - cross-installation event coordination for fleet-scale deployments (Enterprise). Privacy posture Offline-first by design. Every engine runs locally. Source code, scan data, and findings never leave the machine unless you explicitly opt in to the Dashboard or Mesh-Relay. Air-gapped operation supported - full Enterprise installation with no network presence required. Telemetry is opt-in only and disabled by default; structural metadata only when enabled, never source content. ### Installation | Component | Requirement | | --- | --- | | OS | Windows 10+, macOS 12+, Linux (glibc 2.31+) | | RAM | 8 GB minimum, 16 GB recommended | | Disk | 500 MB for installation, plus free space for reports | | Scan cache | Written to /.korthex_cache/ and sized by the project, not by the installation: a semantic-IR entry per source file, plus one record per commit where a git history is scanned. On a large monorepo with deep history this reaches hundreds of megabytes. Safe to delete at any time. | | Runtime | JVM 17+ (bundled with installer) | ### Installation | Variable | Purpose | | --- | --- | | KORTHEX_HOME | Install directory (default: ~/.korthex, %USERPROFILE%\.korthex on Windows) | | KORTHEX_CDN | Release CDN base (default: https://cl.korthex.flowence.cc) | | KORTHEX_SERVER | Backend base used as manifest fallback (default: https://api.korthex.flowence.cc) | | KORTHEX_NO_MODIFY_PATH | Set to 1 to leave PATH untouched | #### Installation System Requirements Windows # Download and run the installer irm https://api.korthex.flowence.cc/api/version/install.ps1 | iex macOS / Linux curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash Container There is no published korthex/cli image. Install into a base image with the same script the Linux installer uses. docker run --rm -v "$(pwd):/workspace" -w /workspace ubuntu:22.04 bash -c ' apt-get update -qq && apt-get install -y -qq curl ca-certificates curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash export PATH="$HOME/.korthex/bin:$PATH" korthex scan . ' After installation, run korthex version to verify the CLI is on your PATH. What the installer verifies Both installers consume the same signed release channel as the desktop auto-updater. They fetch the signed release manifest, verify its detached Ed25519 signature against a public key pinned inside the script itself - the production key only, unless you deliberately opt in to the dev and test keys - and only then download the artifact, which is checked both against the SHA-256 recorded in the signature-verified manifest and against its own detached signature. Freshness and rollback, precisely. The manifest carries an expiry ( notValidAfter ) and a monotonic sequence , and both are read on every run - but they do not protect the same install equally. The sequence is trust-on-first-use : a first install on a clean machine has no stored high-water mark to compare against, so it records the sequence it is given rather than rejecting it. Rollback detection therefore begins with the second run against the same KORTHEX_HOME . On a first install the only bound on an older but still validly signed release is the expiry window - currently 90 days , so a release withdrawn less than 90 days ago can still be served to a fresh machine by whoever controls the channel. The installer is fail-closed : a missing signature, a signature that does not verify, a hash mismatch, or the absence of any usable verification tool aborts the install with a non-zero exit code and writes nothing to disk. There is no "continue anyway" path, so bytes substituted or tampered with in transit - by a compromised CDN, mirror, or proxy - are rejected before anything is written. What the script cannot do is vouch for what happens after it exits: its guarantee covers the bytes it installs, not every update your machine later accepts. Verification needs OpenSSL (3.x or 1.1.1) or Python 3 on macOS/Linux. Windows PowerShell needs nothing extra - the script carries its own verifier. Each is proven against a known-answer test before it is trusted, and the install aborts if none passes. #### Quick Start Get your first scan result in a few commands. How long the scan itself runs depends on the repository and the machine; the cost model behind it is published at korthex.io/scan-duration. # 1. Navigate to your project cd /path/to/your/project # 2. Run a scan korthex scan . # 3. View the report korthex reports --latest This scans all supported files in the current directory, produces a .kxr report, and opens the finding summary. By default, results are written to .korthex/reports/ . The first scan is a full analysis: there is no cache yet, so Korthex builds one in .korthex_cache/ while it works. Every later scan is incremental by default - it re-analyzes the files whose content changed plus everything importing them, and reuses the cached findings for the rest. The report is the same either way; only the time differs. ### Glossary (FUNDAMENTALS) URL: https://korthex.io/docs/glossary Common terms used throughout the documentation. Cross-referenced from every section so you can jump back here whenever you hit a piece of jargon. ### Cryptography Terms | Term | Definition | | --- | --- | | AEAD | Authenticated Encryption with Associated Data. A scheme that encrypts and authenticates in one operation (AES-GCM, ChaCha20-Poly1305, AES-CCM). | | AES | Advanced Encryption Standard. The dominant symmetric block cipher. Recommended at 256-bit keys; 128-bit acceptable. | | Block cipher mode | How a block cipher is applied to larger data. ECB (bad - patterns leak), CBC (needs MAC), CTR (needs unique nonce), GCM (AEAD, recommended). | | ChaCha20-Poly1305 | Modern AEAD stream cipher. Equivalent security to AES-GCM, faster in software, recommended. | | HKDF | HMAC-based Key Derivation Function. Standard way to derive multiple keys from one master secret. | | HMAC | Keyed message-authentication code. Used for integrity. HMAC-SHA-256 is the typical choice. | | IV / Nonce | Initialization Vector / Number-used-once. Random value paired with a key to make the same plaintext encrypt to different ciphertexts. Reuse breaks security. | | KDF | Key Derivation Function. Turns a secret (password, master key) into one or more usable cryptographic keys. | | KEM | Key Encapsulation Mechanism. The PQC-era way to do what RSA-OAEP did: encrypt a session key with a public key. | | MAC | Message Authentication Code. Proves a message wasn't altered (HMAC, GMAC, Poly1305). | | Padding Oracle | An attack class against CBC mode when padding errors are observable. | | PBKDF2 / scrypt / Argon2 / bcrypt | Password-hashing functions. Designed to be slow + memory-hard. Argon2id and bcrypt(>=12) are the current recommendation. | | PKCS#1 v1.5 / OAEP | Two RSA padding schemes. v1.5 is vulnerable to Bleichenbacher attacks; OAEP is the safe modern choice. | | RSA | Asymmetric algorithm. Quantum-vulnerable. Min 2048 bits today; migrate to ML-KEM (encryption) or ML-DSA (signatures). | | Salt | Random per-record value mixed into a hash to defeat rainbow-table attacks. | | SHA-2 / SHA-3 | Cryptographic hash functions. SHA-256 / SHA-384 / SHA-512 (SHA-2) and SHA3-256 / SHA3-512 (SHA-3) are all recommended. | | TLS | Transport Layer Security. TLS 1.2+ recommended; 1.0 and 1.1 are deprecated; SSL of any version is disallowed. | ### Post-Quantum Cryptography | Term | Definition | | --- | --- | | PQC | Post-Quantum Cryptography. Schemes designed to remain secure against attackers with large-scale quantum computers. | | Harvest Now, Decrypt Later (HNDL) | Threat model: an attacker captures encrypted traffic today and stores it until quantum capability arrives. Drives the urgency of migrating before 2030. | | ML-KEM (Kyber) | FIPS 203. Key encapsulation. The PQC replacement for RSA-OAEP and ECDH key exchange. | | ML-DSA (Dilithium) | FIPS 204. Digital signatures. The PQC replacement for RSA signatures and ECDSA. | | SLH-DSA (SPHINCS+) | FIPS 205. Stateless hash-based signatures. For long-lived signatures (firmware, root certs) where conservative assumptions matter. | | Hybrid cryptography | Combining a classical primitive with a PQC primitive so the system is secure if either holds. Standard transition pattern. | | Quantum-vulnerable | Schemes whose security collapses against Shor's algorithm: RSA, DH, ECDH, ECDSA. | | Quantum-resistant / Quantum-safe | Schemes for which no known quantum advantage exists (AES-256, ChaCha20, SHA-256, ML-KEM, ML-DSA, SLH-DSA). | | CNSA 2.0 | NSA's Commercial National Security Algorithm Suite 2.0. Specifies the PQC transition timeline for national-security systems. | | NIST PQC | The NIST post-quantum standardization project that produced ML-KEM, ML-DSA, and SLH-DSA. | ### Korthex Concepts | Term | Definition | | --- | --- | | Baseline Registry | Korthex's central truth source for algorithm classification. Every severity, ELS score, and compliance verdict traces back to a lookup here. | | Baseline status | Recommended / Acceptable / Deprecated / Disallowed / Not-crypto / Unknown. | | CBOM | Cryptographic Bill of Materials. The CycloneDX-format SBOM extended with crypto-asset semantics. | | SBOM | Software Bill of Materials. Standard formats: CycloneDX, SPDX. | | Finding | A single instance of weak / interesting cryptography Korthex detected. | | Cluster | A group of related findings sharing the same algorithm + usage pattern across files. | | Taint | Tracking how a cryptographic value (key, IV, salt) flows from its source through the program. | | Severity ladder | CRITICAL / HIGH / MEDIUM / LOW / INFO. Determined by Baseline Registry + Taint analysis. | | ELS | Exploit Likelihood Score. 0-10 scale produced by the Exploit Engine. Combines algorithm-strength + key-length + mode + source + context. | | Verdict | Policy Engine output: BLOCK / WARN / ALLOW / AUDIT. | | Profile | Policy preset: strict / balanced / legacy. | | Fingerprint | Stable per-finding hash that survives line-number drift from refactors. Used for cross-scan deduplication. | | Air-gapped | Operating mode where the Korthex installation has zero network connectivity. Enterprise feature. | | KRX_PLATFORM_* | Korthex's internal platform-detection macros: KRX_PLATFORM_WINDOWS / KRX_PLATFORM_LINUX / KRX_PLATFORM_MACOS. | ### File Formats | Extension | Quick read | | --- | --- | | .krx | The headline report. Encrypted scan output. Also stores migration plans. | | .kxi | Cryptographic inventory snapshot (CBOM source). | | .kxg | Dataflow graph (with sub-variants .kxg.code / .kxg.binary / .kxg.runtime / .kxg.config / .kxg.tls / .kxg.git). | | .kxnn | Neural-network model archive. | | .kxa | Exploit-engine attack-pattern database. | | .kxsim | Migration-simulation persistence. | | .kxfh | Scan-history finding-ID sets. | | .kxcb / .kxcsic / .kxcfh / .kxcf / .kxgdc | The scan cache family under /.korthex_cache/: context bundle, semantic-IR cache, file-hash snapshot, per-file findings cache, and the git commit delta store. | | .kxw | Workspace bundle (portable, passphrase-encrypted). | | .krxr | Runtime-agent encrypted report. | | .cjsn | Flowence JSON++ compressed columnar JSON (baseline tables, CVE caches). | | .kxp / .korthex_policy.json | Organizational policy file. .kxp is the encrypted canonical form; the .json variant is its human-editable equivalent. | | .korthexignore | User-editable path-ignore list (gitignore syntax). | #### File Formats See File Format Reference for the full catalog. Quick orientation: ### Architecture at a Glance (FUNDAMENTALS) URL: https://korthex.io/docs/architecture-glance Korthex is composed of 14 specialized engines that cooperate around a single shared truth source. This page is the bird's-eye view: how the engines connect, what flows between them, and when each runs. #### The Pipeline Every Korthex run starts at the Scanner and fans out to the analytical engines. The Baseline Registry sits underneath as the shared truth source - every other engine consults it. Input Source code · Binaries · Configuration · Runtime processes ↓ Stage 1 Scanner AST · Binary · Runtime · TLS · Git · Config ↓ Stage 2 Context Engine Dataflow · Taint analysis · Cross-file clustering · FP filtering ↓ Stage 3 - analytical fan-out Inventory CBOM · SBOM Impact Audience reports Dataflow Graph queries Policy CI gate · SARIF Planner Migration plan Neural Network On-device hints Runtime Agent Live observation Exploit PoC evidence ↓ Shared truth source - consulted by every stage above Baseline Registry 11 500+ algorithm rules · classification · min-key-bits · deadlines Side-band engines Accuracy Engine - precision/recall/F1 measurement against ground-truth corpora. Mesh-Relay - outbound event forwarding for fleet-scale Enterprise deployments. Auto Migration (V2) - consumes Planner output, executes context-aware code rewrites with diff-review. ### Engine Roles | Engine | Asks | Answers | Produces | | --- | --- | --- | --- | | Scanner | What crypto is used and where? | Per-file findings. | Findings JSON / .krx | | Context Engine | Which findings actually matter? | Reduced false positives, clusters, cross-file groupings. | Enriched findings | | Baseline Registry | Is this algorithm strong enough? | recommended / acceptable / deprecated / disallowed. | Lookup table | | Inventory | What cryptography do we have, in total? | Comprehensive crypto-asset list. | .kxi + CycloneDX + SPDX | | Impact | What's the business impact? | Per-audience risk reports. | JSON / PDF per audience | | Dataflow | How does this key flow through the system? | Graph of crypto relationships. | .kxg.* (6 variants) | | Policy | Does this scan pass our rules? | BLOCK / WARN / ALLOW verdicts. | SARIF / JUnit / JSON + exit code | | Planner | How do we fix it? | Sequenced migration plan with hours + deadlines. | .krx (plan) + PDF | | Neural Network | How confident is this detection? | On-device ML hints for ambiguous patterns. | Predictions consumed by other engines | | Runtime Agent | What does the code do at runtime? | Live observations from a running process. | .krxr | | Exploit | Is this finding actually exploitable? | Proof-of-concept evidence per finding. | SARIF / JSON | | Auto Migration (V2) | Can we just fix it? | Context-aware automatic rewrites. | Working-tree diff | | Accuracy | Is the scanner getting better? | Precision / recall / F1 measurement. | Measurement JSON | | Mesh-Relay | How do multiple installations coordinate? | Forwarded scan events. | Wire events (signed) | ### When Each Engine Runs | Phase | Engines active | | --- | --- | | Scan | Scanner -> Context Engine -> Neural Network Engine (hints) -> Baseline Registry (lookups throughout). | | Post-scan analytics | Inventory, Impact, Dataflow, Policy, Planner, Exploit. Each runs independently against the scan output. | | Migration | Planner produces the plan; (V1) Migrate simulate previews; (V2) Auto Migration executes; Accuracy measures success. | | Operations | Runtime Agent (on-demand against live processes). Mesh-Relay (continuous, when enabled). | | Maintenance | Accuracy Engine (regression testing). Baseline-Registry refresh (monthly update bundles). | #### Key Architectural Decisions Offline-first. Every engine runs locally. No source code or scan data leaves the machine unless you opt in to telemetry, the Dashboard, or Mesh-Relay. Single truth source. The Baseline Registry is the only place algorithm classification lives. Severity, ELS, compliance verdicts, and migration recommendations all derive from it - so they stay consistent. Stable file formats. Every Korthex artifact has a defined extension, format, and compatibility policy. See File Format Reference . CI-native. Every analytical engine that produces output produces SARIF as an option, so findings flow into the platform you already use. Fail-closed where it matters. Exploit Engine is gated by default; Mesh-Relay requires a TLS pin file or refuses to start; license issues stop the engine rather than continuing degraded. On-device ML. The Neural Network Engine never sends inputs over the network - only optional model-version checks with explicit consent. ### Baseline Registry (FUNDAMENTALS) URL: https://korthex.io/docs/baseline-registry The Baseline Registry is the central crypto-classification truth source. It holds the canonical rule for every algorithm Korthex knows about - currently roughly 11 500 rules across 14 categories - and tells every other engine: "is this algorithm safe to use, and if not, what should it be replaced with?" When a finding shows up flagged "high severity, replace with X by 2030", that verdict is consistent across the report, the dashboard, the SBOM, the migration plan, and the policy gate - because every engine reads the same table . ### The Classification Ladder | Status | What it means | | --- | --- | | Recommended | Safe to use today and through the PQC transition. Default choice for new code. | | Acceptable | Allowed but not preferred. Often acceptable above a key-size threshold and deprecated below it. | | Deprecated | Still functional but on the way out. Plan a migration before the published deadline. | | Disallowed | Broken or so weak that any use is a finding. Migration is urgent. | | Not-crypto | Classified explicitly so it never raises a finding (e.g. Base64, hex, PEM encoding). | | Unknown | Algorithm isn't in the registry. Treated as fail-safe: never marked approved, raises a low-severity "unknown algorithm" finding so it can be reviewed. | ### Where the Common Algorithms Sit | Algorithm | Status | Notes | | --- | --- | --- | | SHA-256 / SHA-384 / SHA-512 | Recommended | Workhorses. Use any. | | SHA3-256 / SHA3-512 | Recommended | Equivalent to SHA-2 in strength; structurally different (sponge construction). | | BLAKE2 / BLAKE3 | Recommended | Faster than SHA-2 in software; widely adopted. | | SHA-224 | Acceptable | Truncated SHA-256. Generally avoid for new designs. | | SHA-1 | Deprecated | Broken for collision resistance. OK only inside HMAC. Deadline 2025-12-31. | | MD5 / MD4 / MD2 / MD6 | Disallowed | Cryptographically broken. Any use is a finding. | ### Where the Common Algorithms Sit | Algorithm | Status | Notes | | --- | --- | --- | | AES-256-GCM / AES-256-GCM-SIV | Recommended | Default modern AEAD. | | ChaCha20-Poly1305 / XChaCha20-Poly1305 | Recommended | Fast in software; equivalent strength to AES-256-GCM. | | AES-128-GCM | Acceptable | Fine. 128-bit security is still well above brute-force. | | AES-CBC + HMAC | Acceptable | Encrypt-then-MAC pattern; requires careful implementation. | | AES-CBC without MAC | Deprecated | Vulnerable to padding-oracle attacks. | | AES-ECB | Disallowed | Reveals plaintext patterns. | | 3DES / DES / RC2 / RC4 / Blowfish | Disallowed | Broken or fatally weak. | ### Where the Common Algorithms Sit | Algorithm | Status | Notes | | --- | --- | --- | | Ed25519 / X25519 | Recommended | Modern elliptic-curve choices. Recommended until quantum threat materializes. | | ML-KEM (Kyber) / ML-DSA (Dilithium) / SLH-DSA (SPHINCS+) | Recommended | NIST PQC standards. Use for new designs. | | RSA-OAEP encryption (>= 2048) | Acceptable | OK for now; quantum-vulnerable; deadline 2030. | | ECDSA P-256 / P-384 | Acceptable | OK for now; quantum-vulnerable; deadline 2030. | | RSA-PSS signatures (>= 2048) | Acceptable | OK for now; deadline 2030. | | DH (classical, >= 2048) | Acceptable | SP 800-56A Rev.3 approves finite-field DH with approved groups of 2048 bits and up. Quantum-vulnerable, so plan the PQC migration; below 2048 bits it is Disallowed. | | RSA-PKCS#1 v1.5 encryption | Deprecated | Vulnerable to Bleichenbacher; migrate to OAEP. | | RSA < 2048 | Deprecated | Insufficient key size. Deadline 2025-12-31. | | DSA (any key size) | Disallowed | FIPS 186-5 withdrew DSA for signature generation. A larger key does not help; any use is a finding. | | RSA-1024 / DSA-1024 | Disallowed | Brute-force feasible. | ### Where the Common Algorithms Sit | Algorithm | Status | Notes | | --- | --- | --- | | Argon2id | Recommended | Modern memory-hard PHF. First choice for new designs. | | bcrypt (cost >= 12) | Recommended | Mature, widely supported. Increase cost over time. | | scrypt (N >= 32768) | Recommended | Memory-hard. Watch parameter selection. | | PBKDF2-HMAC-SHA-256 (>= 600 000 iterations) | Acceptable | OK with high iteration count; not memory-hard. | | bcrypt (cost 10-11) | Deprecated | Too cheap for modern hardware. Bump to >= 12. | | PBKDF2 with low iterations | Deprecated | Brute-forceable on modern GPUs. | | Single MD5 / SHA-* of a password | Disallowed | Not a password hash. Migrate immediately. | ### Where the Common Algorithms Sit | Protocol | Status | Notes | | --- | --- | --- | | TLS 1.3 | Recommended | Modern handshake; forward-secrecy by default. | | TLS 1.2 (modern cipher suites) | Acceptable | Avoid CBC suites; prefer GCM / ChaCha20-Poly1305. | | TLS 1.1 | Deprecated | Removed by IETF; deadline 2025-12-31. | | TLS 1.0 | Disallowed | Removed by IETF; treat any usage as a finding. | | SSL 3.0 / SSL 2.0 | Disallowed | Broken (POODLE, ...). | #### Where the Common Algorithms Sit Hashes Symmetric Ciphers Asymmetric / Signatures Password Hashing Transport / Protocols The full registry is browsable in the Dashboard under Catalog → Algorithms , which shows status, min-key-bits, recommended replacement, PQC note, and the upstream standard reference. There is no CLI equivalent. ### Minimum Key Sizes | Algorithm | minKeyBits | Below = | | --- | --- | --- | | RSA | 2048 | Deprecated; RSA-1024 and below: Disallowed. | | ECC / ECDSA | 256 | Below: Deprecated. | | AES (symmetric) | 128 | Below: Disallowed (no such standard variant in practice). | | DH (classical Diffie-Hellman) | 2048 | Below: Deprecated. | | SHA family (output bits) | 224 | Below: Deprecated. SHA-1 (160 bits): Deprecated; MD5 (128 bits): Disallowed. | #### Minimum Key Sizes The same algorithm name can be Acceptable above a threshold and Deprecated below it. The registry encodes minKeyBits (for asymmetric and symmetric) and minOutputBits (for hashes) so the verdict adapts to actual key sizes in the code. The Policy Engine lets you tighten these via minimums in your .korthex_policy.json - e.g. require RSA ≥ 3072 or AES ≥ 256. #### Algorithm Name Normalization The registry is case-insensitive and separator-insensitive. All of the following names resolve to the same rule: AES-256-GCM aes 256 gcm AES_256_GCM aes256gcm AES/256/GCM For in-house wrappers, register them in the policy file via algorithm-aliases so the registry maps your wrapper name to the underlying algorithm. See the Policy File Syntax section. ### Deadlines & Standards Tracking | Authority | What it dictates | | --- | --- | | NIST SP 800-131A | Per-algorithm deprecation timeline. The registry tracks each transition date. | | NIST FIPS 203 / 204 / 205 | PQC standards (ML-KEM / ML-DSA / SLH-DSA). Marked Recommended in the registry. | | BSI TR-02102-1 | Federal Office for Information Security (Germany) crypto recommendations. Tracked alongside NIST. | | NSA CNSA 2.0 | National Security Algorithms 2.0. PQC transition timeline for national-security systems. | | IETF RFC deprecations | TLS 1.0 / 1.1 EOL, SHA-1 in certificates, etc. | #### Deadlines & Standards Tracking Every Deprecated entry carries an upstream deadline from the standards bodies. Findings show this deadline so engineers know how much runway they have. The registry is updated as standards evolve. Refresh bundles are delivered monthly (or pulled automatically on online installations). In air-gapped mode, refresh bundles are applied through the Dashboard. The CLI has no import subcommand and no path that reads a .cjsn bundle. #### Inspecting the Registry Registry inspection is Dashboard-only today. There is no CLI command that lists, searches, or exports the algorithm registry - korthex baseline is a different thing entirely (see below). Browse the registry under Catalog → Algorithms , or read the status of a specific algorithm off a scan: every finding carries algorithm , status , baseline_id and replace_with . #### The finding baseline (korthex baseline) korthex baseline does not manage the algorithm registry. It manages the crypto-finding baseline - the record of which findings are already known, so CI can fail on new ones only. It writes .korthex_baseline.krx into the project root. # Create the baseline from the latest scan korthex baseline init # Rebuild it after intentional fixes korthex baseline refresh # Show NEW and RESOLVED findings against the current baseline korthex baseline diff # Exit 0 when the scan matches the baseline, exit 2 on drift korthex baseline verify korthex check --baseline consumes the same file for the NEW-finding gate (exit 20). ### CLI Reference (CLI & SCANNING) URL: https://korthex.io/docs/cli-reference The Korthex CLI is the primary interface for scanning, reporting, and managing cryptographic findings. All commands follow the pattern: korthex [subcommand] [options] Run korthex --help for the list of commands, or korthex --help for the detailed usage of any one of them. There is no help verb - help is an option, not a command. #### scan The core command. Scans a directory, repository, or file for cryptographic usage and vulnerabilities. korthex scan [options] Engine selection, language filters, exclude patterns, thread count and the delta scan are configuration , not flags: set engines , globalFilters , global.maxThreads , incremental and fullRescan in the scanner config and pass it with --config . In particular there is no --no-cache and no --full-rescan flag. Examples # Scan the current directory, JSON on stdout korthex scan . --json # Gate a build: fail on any critical, allow up to 5 high korthex scan . --gate --max-critical 0 --max-high 5 # Scan with a custom config and write a SARIF file korthex scan ./src --config ./korthex.scan.json --format sarif -o findings.sarif #### check Runs a scan and exits with a non-zero code if findings exceed a threshold. Designed for CI/CD gate checks. korthex check [options] --max-critical and --max-high belong to korthex scan , not to check . Passing them here is a usage error (exit 4), and a pipeline that does so never gates at all. Use --fail-on for the severity threshold. - name: Korthex Security Check run: korthex check . --fail-on high #### watch Watches a directory and tells you when it is worth re-scanning. It does not re-scan: after a batch of changes it prints a reminder to run korthex scan , and the scan stays your call. The watch covers the directory you name, not the tree beneath it. # Watch the active project korthex watch # Watch a specific directory and print every file event korthex watch --path /path/to/repo --verbose #### diff Compares two scan reports. Both are named by flag, not by position, and both are decrypted with the stored master key before they are compared. korthex diff --before before.krx --after after.krx The zero-argument form is not a diff. korthex diff without flags compares nothing: it prints the two most recent report entries under the heading "Diff of latest two reports". Pass both paths when you want an actual comparison. #### reports List, export, or delete scan reports. The command is reports , it is flag-driven, and it has no subcommands. # List every report in the report directory korthex reports # Show the most recent one korthex reports --latest # Decrypt a report to plain JSON (without an outfile: .json) korthex reports --export .korthex/reports/scan_20260406.krx report.json # Delete a report - refuses anything that is not .krx or .kxd korthex reports --delete old_report.krx #### decrypt Read a native encrypted report back into plain JSON. This is the low-level counterpart to reports --export : same result, but it takes an explicit key and can read just the header. # Decrypt to stdout korthex decrypt report.krx # Decrypt to a file korthex decrypt report.krx --output report.json # Header only - no key required korthex decrypt report.krx --header There is no export verb. Converting findings into a portable format happens at scan time - korthex scan . --format json , korthex check . --format sarif - or by decrypting the native report as shown above. #### config Create, validate, migrate or edit the project configuration file, korthex.json , in the current directory. These are flags, not subcommands. korthex config [--init] [--validate [--strict]] [--migrate] [--set ] [--json] # Create the default config korthex config --init # Validate it the way the engine will read it korthex config --validate --strict # Change one value korthex config --set maxFiles 50000 ### policy | Subcommand | Description | | --- | --- | | validate | Validate a .kxp policy file. | | apply | Apply a policy to the current project. | | check | Check a report against the active policy. | | show | Display the current active policy. | #### policy Manage organizational security policies. Policies define which algorithms, key sizes, and configurations are permitted. korthex policy ### migrate | Subcommand | Description | | --- | --- | | plan | Generate a migration plan from a scan report. | | execute | Execute a migration plan with automated code generation. | | simulate | Simulate migration without writing changes. | | impact | Estimate the impact of a migration on the codebase. | #### migrate Automated migration planning and code generation for transitioning to quantum-safe cryptography. Coming in V2 korthex migrate [options] The migrate command family is available in Korthex V2. In V1, use the scan and report commands to identify what needs to change. ### Scanning (CLI & SCANNING) URL: https://korthex.io/docs/scanning Korthex uses a multi-engine scanning architecture. Each engine specializes in a different aspect of cryptographic analysis, and results from all engines are merged into a unified finding set with cross-engine deduplication. ### Scan Engines | Engine | Config key | Analyzes | Detects | | --- | --- | --- | --- | | AST | codeAnalysis | Source code abstract syntax trees | Crypto API calls, algorithm strings, key sizes, mode parameters | | Binary | binary | .NET IL, JVM bytecode, native binaries | Compiled-in crypto usage, embedded keys, algorithm constants | | Runtime | runtime | Dynamic execution traces | Runtime crypto operations, certificate validation, TLS handshakes | | TLS | tlsCert | Network endpoints, certificate chains | Weak cipher suites, expiring certs, non-PQC TLS configurations | | Git History | gitHistory | Repository history, deleted files | Previously committed secrets, removed crypto code, key rotations | | Config | config | Configuration files, environment templates | Hardcoded secrets, weak algorithm settings, insecure defaults | | Database | database | 41 database types (relational, NoSQL, cloud, KMS) | Insecure connections, missing TLS, hardcoded credentials, weak auth, encryption-at-rest | #### Scan Engines Engine selection is a configuration block, not a flag. There is no --engines switch: put the toggles under engines.subEngines in a config file and pass it with --config . The config keys are the ones in the table above, so codeAnalysis and tlsCert are what an AST-plus-TLS run leaves enabled. At least one engine has to stay on, otherwise the scan is refused before a single file is read. See Configuration for the full block. ### Scan Modes | Mode | Description | Use Case | | --- | --- | --- | | Incremental (default) | Re-analyzes files whose content hash changed, plus everything that transitively imports them; the rest is served from the findings cache. Emits the same artifacts as a full scan. | Every scan, unless you opt out | | Full Scan | Analyzes the entire codebase. Requested with fullRescan: true, and entered automatically whenever no usable cache snapshot exists. | First scan, audit, compliance evidence | | Watch Mode | Continuous file-watching that re-runs the incremental path on change. | Real-time IDE feedback | | Targeted | Scans a single file or specific directory. | Investigating a specific finding | ### Language Support | Language | File Extensions | Key Libraries Detected | | --- | --- | --- | | JavaScript | .js, .mjs, .cjs | crypto, node:crypto, SubtleCrypto, CryptoJS, sjcl, forge | | TypeScript | .ts, .tsx | Same as JavaScript + type-aware analysis | | C# | .cs | System.Security.Cryptography, BouncyCastle, NSec | | Java | .java | javax.crypto, java.security, BouncyCastle, Tink | | Python | .py | cryptography, pycryptodome, hashlib, hmac, ssl | | Go | .go | crypto/*, x/crypto/*, tls | | PHP | .php | openssl_*, mcrypt_*, sodium_*, hash() | | Ruby | .rb | OpenSSL, Digest, RbNaCl | | Rust | .rs | ring, rust-crypto, openssl, sodiumoxide, aes-gcm | | Kotlin | .kt, .kts | javax.crypto, BouncyCastle, Tink | | Scala | .scala | javax.crypto, BouncyCastle, tsec | | C++ | .cpp, .cc, .cxx, .h, .hpp | OpenSSL, Botan, Crypto++, libsodium, wolfSSL | | C | .c, .h | OpenSSL, libsodium, wolfSSL, mbedTLS | | Swift | .swift | CryptoKit, CommonCrypto, Security.framework | | Dart | .dart | pointycastle, crypto, encrypt | | VB.NET | .vb | System.Security.Cryptography | | COBOL | .cbl, .cob | CALL 'CEERAN0', crypto service routines | | Zig | .zig | std.crypto | #### Language Support Korthex supports 18 programming languages with dedicated AST parsers and crypto-library awareness: ### Framework Support | Framework / Platform | Detection Scope | | --- | --- | | ASP.NET Core | Data protection APIs, authentication schemes, HTTPS configuration | | Spring Boot | Spring Security crypto, KeyStore configuration, OAuth2 tokens | | Express / Fastify | Session encryption, CORS, Helmet security headers, JWT | | Django | SECRET_KEY, password hashers, signing, CSRF tokens | | Rails | ActiveSupport::MessageEncryptor, has_secure_password, credentials | | Next.js | API route crypto, middleware tokens, environment secrets | | .NET Framework | Legacy System.Security, machine keys, web.config encryption | | Android (Kotlin/Java) | Android Keystore, BiometricPrompt, EncryptedSharedPreferences | | iOS (Swift) | Keychain Services, Secure Enclave, App Transport Security | | AWS SDK | KMS calls, S3 encryption, SSE configuration | | Azure SDK | Key Vault, Blob encryption, Managed Identity tokens | | gRPC | TLS channel credentials, call credentials | #### Framework Support Beyond language-level detection, Korthex understands framework-specific crypto patterns: ### Database Scanning (CLI & SCANNING) URL: https://korthex.io/docs/database-scanning Korthex detects and analyzes 41 database types across 5 categories: relational, NoSQL, cloud, in-memory/cache, and key management systems (KMS). Findings include insecure connections, missing TLS/SSL, hardcoded credentials, weak authentication, missing encryption-at-rest, and key management policy violations. ### Supported Databases | Category | Databases | Detection Methods | | --- | --- | --- | | Relational | PostgreSQL, MySQL, MariaDB, MSSQL, Oracle, SQLite, CockroachDB, DB2, SAP HANA, Informix, Teradata | Static analysis + wire protocol probing | | NoSQL | MongoDB, Redis, Cassandra, Elasticsearch, Neo4j, ClickHouse, CouchDB, DynamoDB (API), Couchbase, InfluxDB, TimescaleDB | Static analysis + wire protocol probing | | Cloud | AWS RDS/Aurora, Azure SQL, GCP Cloud SQL, DynamoDB, Cosmos DB, Firestore, Cloud Spanner, Azure Table Storage, GCP Bigtable | Static analysis (config/IAM) | | In-Memory | Memcached, Hazelcast, Apache Ignite, Valkey | Static analysis + protocol probing | | KMS | AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault, CyberArk, Thales CipherTrust | Static analysis (config/policy) | #### Discovery Korthex discovers database usage from multiple sources: dependency manifests (package.json, build.gradle, requirements.txt), Docker Compose files, Kubernetes manifests, ORM configurations, environment variables, and connection strings in configuration files. Database scanning is a static analysis feature by default. Enable enableLiveProbe in your configuration to test running database instances via native wire protocol probing (requires network access to the database). ### Security Checks | Check | What it Detects | | --- | --- | | SSL/TLS | Unencrypted connections, sslmode=disable, missing TLS configuration | | Credentials | Hardcoded passwords in connection strings, config files, environment templates | | Authentication | Weak auth methods, default credentials, missing auth configuration | | Encryption-at-Rest | Missing TDE, unencrypted storage, absent key management | | PII Exposure | Sensitive data fields without column-level encryption | | Key Management | Missing key rotation, expired keys, weak key policies (KMS) | | Backup Encryption | Unencrypted backup configurations | ### Context Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/context-engine The Context Engine runs as a second pass after the initial scan. It builds a project-wide semantic index and applies dataflow, taint, and cross-file analysis to enrich findings with contextual evidence and reduce false positives. #### Dataflow Analysis The dataflow engine tracks how cryptographic values move through your codebase. It resolves variable assignments, function returns, and import chains to determine the actual algorithm, key, or configuration used at each call site. For example, if a key is defined in one module, exported, imported in another, and passed through several variables before reaching a cipher call, the dataflow engine traces the full path and reports the original definition site. Dataflow analysis resolves across up to 16 import hops and tracks variable assignments through re-exports and barrel files. ### Taint Analysis | Source Kind | Description | Example | | --- | --- | --- | | HARDCODED_KEY | Literal key material in source code | const key = "abc123..." | | ENV_VARIABLE | Value from environment or config | process.env.SECRET_KEY | | SECURE_RANDOM | Cryptographically secure RNG | crypto.randomBytes(32) | | KMS_DERIVED | Key from a key management service | kms.decrypt(encryptedKey) | | USER_INPUT | Value from untrusted user input | req.body.token | | TEST_LITERAL | Known test/dummy value | "test-key-do-not-use" | ### Taint Analysis | Verdict | Action | | --- | --- | | HIGH_PRIORITY | Finding severity increased by one level. | | TRUE_POSITIVE | No change. Finding stands as detected. | | LIKELY_FALSE_POSITIVE | Finding severity decreased by one level. Marked for review. | | DEFINITELY_TEST_CODE | Finding suppressed by default. | #### Taint Analysis Taint analysis determines whether a cryptographic finding is a genuine vulnerability or a false positive. It examines the origin and propagation path of values used in crypto operations. Source Classification Verdict Ladder #### Cross-File Analysis The cross-file cluster builder identifies cryptographic usage patterns that span multiple files. When the same algorithm and usage type appear across files connected by import edges, Korthex groups them into a cluster. This is particularly useful for detecting systemic issues - for example, an AES-128-ECB encryption pattern shared across 12 service modules via a common utility. Cross-file clusters appear in reports with a crossFile: true flag and list all participating files and the import bridges connecting them. #### False-Positive Filtering Korthex automatically identifies and suppresses common false-positive patterns: Test fixtures - Keys in test files, mock configurations, fixture data. Dummy/placeholder keys - Known test vectors like "0000...0000" or "test-key" . Documentation examples - Crypto code inside comments, README snippets, or doc blocks. Dead code - Unreachable crypto operations behind always-false conditions. Standard test vectors - NIST test vectors, RFC examples, and known algorithm validation data. Suppressed findings are not deleted - they stay in the native report, so a later re-read still has them. There is no CLI flag that prints them back out, and the plain-JSON export carries no suppression marker either: what korthex scan . --format json writes is the post-suppression view. ### Dataflow Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/dataflow-engine The Dataflow Engine turns the flat list of findings into a directed graph: nodes are cryptographic assets (keys, certs, algorithms, call sites, services), edges are the relationships between them (generates, reads, encrypts-with, transmits-to, rotates-from, deprecated-by, ...). You can then ask the graph questions a per-file scan can't answer. #### Questions It Answers Where does this key go? - every service that reads it, every line that derives a new key from it. What depends on this certificate? - every endpoint, every config file, every code path that pins it. Which services still touch SHA-1 today? - live map across the project. Was this key ever transmitted unencrypted? - reachability query through the transmission edges. When was algorithm X introduced and when was it last rotated? - via the git-timeline view. ### Edge Types | Edge | Meaning | | --- | --- | | GENERATES | Code site that creates a new key, IV, or nonce. | | READS | Code site that consumes a previously-generated value. | | IMPORTS | Cross-file or cross-module import path. | | ENCRYPTS_WITH | Plaintext value encrypted using a specific key reference. | | DECRYPTS_WITH | Inverse of ENCRYPTS_WITH. | | SIGNS_WITH | Signature operation using a specific key. | | VERIFIES_WITH | Signature verification. | | TRANSMITS_OVER | Value sent over a network connection / channel. | | STORES_IN | Value persisted to a config, database, or KMS. | | DERIVES_FROM | KDF / HKDF / PBKDF derivation. | | ROTATES_FROM | Replaces or supersedes an earlier value. | | DESTROYS | Explicit zeroization / wipe. | | ...and 12 more | Covering TLS handshake states, runtime hooks, attribute relationships. | #### Edge Types The graph supports 24 edge types covering source, runtime, configuration, and infrastructure relationships: #### Anomaly Queries Built-in queries surface patterns a per-file scan cannot detect because they span multiple nodes: Key reused after destroy - a value zeroed in one path but referenced again later. Private key transmitted unencrypted - reachability from a key-gen node to a TRANSMITS_OVER edge on a plaintext channel. Nonce reused - the same nonce edge appearing across multiple ENCRYPTS_WITH operations. Key generated but never destroyed - GENERATES node without a downstream DESTROYS. Cert pinned in code but not in config - inconsistency between the IaC and the application layer. ### Files & Output | File | Purpose | | --- | --- | | .kxg.code | Static source-code dataflow graph. | | .kxg.binary | Compiled-binary dataflow graph. | | .kxg.runtime | Runtime traces from a Runtime-Agent session. | | .kxg.config | Configuration-file dataflow (Terraform, YAML, web.config, ...). | | .kxg.tls | TLS-endpoint relationships (cert chains, cipher suites). | | .kxg.git | Git-history dataflow: when algorithms were introduced, rotated, replaced. | #### Files & Output CLI - four subcommands, and every one of them names its input by flag rather than by position: # Build from the latest report of a project korthex dataflow build --path /path/to/repo # Path query: how does this credential reach the database? korthex dataflow query --graph graph.kxg --from "secret:db-password" --to "service:billing-svc" # Anomalies in an existing graph korthex dataflow anomalies --graph graph.kxg # Export to DOT for Graphviz / external visualization korthex dataflow view graph.kxg --format dot > graph.dot Two shapes are worth knowing before you script against this. query is a path query and nothing else: it needs --graph , --from and --to together, and refuses the call if any of the three is missing. There is no one-ended form - "every service that reads this key" is not a query you can ask the CLI today. And view writes to standard output; it has no --output , so redirect it as above. ### Inventory Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/inventory-engine The Inventory Engine builds an authoritative inventory of every cryptographic asset in your project - every algorithm use, every certificate, every TLS endpoint, every key in code or config - and writes it as an encrypted .kxi snapshot alongside the scan report. This is the engine that answers "what cryptography are we actually using, in which files, at what strength?" The inventory is a Dashboard surface, not a CLI verb . The CLI's job is to produce the snapshot - korthex scan . writes it - and the Dashboard's job is to read it. Both clients carry the same Inventory screen with four views: Desktop app: Inventory in the sidebar. Web Dashboard: Inventory (the separate CBOM page shows the same asset list in bill-of-materials shape). | View | What it shows | | --- | --- | | Files | Per-file rollup: which algorithms and keys appear in which file. | | Census | One row per distinct algorithm: family, strength, occurrence count, NIST status, PQC flag. Filter by family, search by name. | | PQC Readiness | The PQC-safe share of the inventory, plus the ready list and the at-risk list. | | Snapshot Diff | Compare the loaded snapshot against an earlier one. | ### What It Inventories | Category | Examples captured | | --- | --- | | Algorithms | Every distinct algorithm + mode + key-length combination, with usage counts. | | Certificates | X.509 certs in code, config, and TLS endpoints. Validity, signing chain, key type. | | TLS endpoints | Hostnames, ports, cipher suites, protocol versions, cert pinning state. | | Top crypto files | Files containing the highest density of crypto operations (audit hotspots). | | Binary findings | Algorithms discovered in shipped artifacts (.dll, .so, .jar, .wasm). | | Git history | Algorithms introduced or removed across commits. | | Runtime processes | Live algorithm choice from a Runtime-Agent session. | #### PQC Readiness Score The PQC Readiness view scores the snapshot: what share of the inventoried algorithms is already post-quantum safe. It shows the percentage as a bar, then two lists - the algorithms that are already PQC-safe, and the quantum-vulnerable ones still in use. Two things are worth knowing before you quote the number: It is a ratio over distinct algorithms, not over call sites. Ten RSA call sites and one RSA algorithm count once. When you need the call-site weight, read the occurrence column in the Census view. Hashes are excluded from the at-risk list - they still count in the denominator, but a hash function is not a quantum-migration item the way a key-exchange or signature primitive is. An empty inventory has no ratio, and Korthex says so rather than reporting 0%. "Not measured" and "measured, and it is zero" are different answers and are rendered differently. ### CBOM / SBOM Export | Format | Standard | Status | | --- | --- | --- | | CycloneDX 1.5 JSON | OWASP Crypto-BOM profile | Emitted by the engine. Not yet reachable from the CLI or the Dashboard - the CLI surface is being built. | | SPDX 2.3 JSON | SPDX 2.3 with package extensions | Emitted by the engine. Not yet reachable from a client. | | Korthex JSON / CSV | Native per-usage rows | What Export CBOM writes today. One row per usage: algorithm, type, file, line, language, deprecated, PQC-safe, NIST status, severity, key size, mode. | #### CBOM / SBOM Export The Inventory engine emits the snapshot in two standard bill-of-materials formats. What a client hands you today is a third thing - be precise about which one you need. Today: open the Inventory screen and use Export CBOM . Name the target .json for the JSON rows or .csv for the spreadsheet form; the export is permission-gated on findings.read . Planned: the CycloneDX and SPDX emitters get a CLI surface. The commands below are the interface they will carry - they are not available yet, and the CLI will reject them until they are. # Planned - not yet available. Use Export CBOM in the Dashboard today. korthex inventory export latest --format cyclonedx --output cbom.cdx.json korthex inventory export latest --format spdx --output sbom.spdx.json ### Snapshot Diffs | Section | Meaning | | --- | --- | | Added | Algorithms present now that the earlier snapshot did not have. | | Removed | Algorithms the earlier snapshot had and this one does not. | | Unchanged | How many algorithms carried over untouched (a count, not a list). | | Newly deprecated | Algorithms that were fine before and are flagged deprecated now. | | Newly PQC-safe | Algorithms that crossed over to a post-quantum primitive. | #### Snapshot Diffs Inventory snapshots compare cleanly across scans. Open the Inventory screen, pick Snapshot Diff , and choose the earlier .kxi . The comparison is per algorithm and reports five things: .kxi snapshots are encrypted. The Desktop app decrypts them with the workspace master key, so it diffs a snapshot straight from disk - without a master key loaded, the Diff action tells you so instead of failing quietly. The Web Dashboard currently needs an already-decrypted snapshot and rejects an encrypted payload with an inline error. ### Impact Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/impact-engine The Impact Engine takes a flat list of findings ("MD5 detected at auth.py:42") and translates it into business language ("this finding affects the customer-payment service and represents approximately 250k of remediation effort"). It scores blast radius, estimates engineer-hours, walks dependency cascades, and renders the result for the right audience. #### Inputs The engine needs three things to produce a useful business-impact report: The scan findings (a .krx report). A business-context file describing your services, dependencies, and what each is worth (revenue-bearing, customer-facing, compliance-critical, internal-only). A local CVE / KEV / EPSS cache (bundled with Korthex; refreshed periodically - see the Air-Gapped section). { "services": [ { "name": "payments-svc", "files": ["services/payments/**"], "valueAtRisk": "high", "compliance": ["PCI-DSS"], "dependsOn": ["auth-svc", "billing-svc"] }, { "name": "auth-svc", "files": ["services/auth/**"], "valueAtRisk": "critical", "compliance": ["SOC2", "HIPAA"] } ] } #### What It Produces Per-finding risk scores - CVSS-style composite: severity x confidence x CVE multiplier x business multiplier. Engineer-hour estimates - with seniority-adjusted breakdowns. Critical-path analysis - if service X breaks, what else fails downstream? Attack-surface score - aggregated metric for trend reporting. Compliance impact - mapped to PCI-DSS, HIPAA, GDPR, SOC2. Trend persistence - direction-of-travel between scans (improving / degrading / flat). ### Audience-Tailored Reports | Audience | Framing | | --- | --- | | CISO | Security posture, threat landscape, compliance gap analysis. | | CTO | Technology debt, migration roadmap, engineering capacity. | | CFO | Financial: remediation cost, breach-cost exposure, vendor-cost optimization. | | BOARD | Executive summary: 1 page, leading indicators, asks. | | DEFAULT (engineering) | Full technical report: findings + remediation steps + code locations. | #### Audience-Tailored Reports The same data renders five different ways depending on who's reading. Each variant is a separate render with appropriate detail level, terminology, and chart selection - not a stripped-down view of the technical report. # Generate the CISO-flavored report korthex impact report latest --audience CISO --output ciso-report.json # Generate the executive board summary as PDF korthex impact report latest --audience BOARD --format pdf --output board-2026-05.pdf ### Policy Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/policy-engine The Policy Engine decides which findings should block a CI/CD pipeline, which should warn , and which to ignore - based on a federated baseline plus your organization's overrides. It outputs proper CI exit codes and standard-format reports. ### Verdicts | Verdict | Meaning | CI behavior | | --- | --- | --- | | BLOCK | This finding violates a hard rule. | CI fails (exit 1). | | WARN | Finding noted, but not blocking. | CI passes with annotation. | | ALLOW | Finding falls within the policy. | CI passes silently. | | AUDIT | Finding noted for periodic review. | CI passes; appears in audit summary. | #### Verdicts Each verdict carries a citation to the rule or standard that produced it (e.g. "NIST SP 800-131A § 8.2") so reviewers can verify the decision. ### Built-in Profiles | Profile | Use case | | --- | --- | | strict | Anything below recommended status raises BLOCK. For greenfield projects + regulated industries. | | balanced | Default. Deprecated raises BLOCK; acceptable raises WARN; exemptions allowed. | | legacy | Only disallowed primitives BLOCK; deprecated WARN; for brownfield migrations. | #### Built-in Profiles Profiles are a property of the policy file, not a CLI setting. There is no command to switch or print the active profile - the CLI exposes exactly two policy subcommands, enforce and evaluate . Select a profile by editing the policy file and passing it with --policy . ### Scan Modes | Mode | Effect | | --- | --- | | full | Evaluate every finding in the report against policy. | | changed | Only findings touched by the current diff (best for PR gates). | | baseline | Only findings new since the saved baseline (best for incremental migration). | #### Scan Modes # Evaluate a report against the policy, machine-readable korthex policy evaluate --report report.krx --format sarif # Enforce it: exit 1 when the policy is violated korthex policy enforce --report report.krx --fail-on-violation policy enforce takes a report via --report , not a directory, and it has no mode selector: --mode , --base-ref and --baseline do not exist on it. The three scopes above are properties of the policy evaluation, not flags you pass here. To gate a PR on changed files only, use korthex check . --since-ref origin/main ; to gate on new findings only, use korthex check . --baseline . Policy commands require an Enterprise license. Exit codes: 0 clean, 1 violations, 31 report unreadable, 32 no policy loaded, 41 policy file unusable. --threshold is declared but not honoured - set ci_fail_on in the policy file instead. ### CI Output Formats | Format | Integration | | --- | --- | | SARIF | GitHub Code Scanning, Azure DevOps, GitLab. Findings show up inline on the PR diff. | | JUnit XML | Generic CI runners. Each violation becomes a failed test case. | | JSON | Custom integrations and bot workflows. | | TEXT | Human-readable summary for terminals + Slack notifications. | #### CI Output Formats Policy enforcement emits in formats CI platforms consume natively: ### Planner Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/planner-engine The Planner takes a scan report and produces a concrete migration plan: for every weak algorithm, which file/line to change, what to replace it with, in what order, by when, and how long it will take. The plan is rendered as PDF for stakeholders and as a structured .krx file for the Auto Migration engine to execute (V2). ### Plan Items by Domain | Item type | Captures | | --- | --- | | Code | File + line + algorithm to replace, with the recommended replacement. | | Config | Config-file key paths and new values (web.config, application.properties, ...). | | TLS | Certificate rotation, endpoint reconfiguration, cipher-suite changes. | | Git | Historical-commit remediation (with explicit destructive-action confirmation). | | Hybrid | Multi-domain coordinated changes (e.g., config + code + git revert as one unit). | #### Plan Items by Domain A plan is a topologically-ordered list of items, each scoped to a specific remediation domain: #### Per-Item Information Every item carries the same set of properties so plans are easy to consume programmatically: Severity - inherited from the source finding. Replacement - recommended algorithm + key length + mode. Deadline - calibrated to NIST PQC 2030 + per-algorithm deprecation dates. Engineer-hours - estimated effort with confidence interval. Dependencies - ordered edges to other plan items (do foundational changes first). Verification steps - tests to write or run after the migration. #### Using the Planner Plan creation, preview and execution are separate top-level commands. There is no migrate plan subcommand: migrate is itself the executor and is flag-based. # Generate a plan from the latest scan korthex plan create # List the stored plans and read one back korthex plan list korthex plan view # Preview the changes without writing them korthex migrate --dry-run # Execute the plan, optionally narrowed by severity korthex migrate --plan --severity CRITICAL,HIGH # Execute a single finding, then watch or stop the run korthex migrate --single finding-123 korthex migrate --status korthex migrate --cancel korthex deploy --plan is the second route to rolling a plan out, with korthex deploy status for progress. korthex migrate works against the latest report and gives you the dry-run, severity filter and single-finding paths; deploy takes the plan id and nothing else. Not available from the CLI today: rendering a plan to PDF, a review gate before execution, and accepting or reverting an applied migration. --cancel stops a running migration; it does not roll back one that already completed. #### ML Re-prioritization (Optional) By default, the plan is ordered by deadline + severity + dependency edges. With the Neural Network Engine enabled, items can be re-prioritized based on predicted impact: two items with the same deadline get re-ordered so the one most likely to produce a measurable security improvement comes first. There is no CLI flag for this today. The planner applies its ordering when the Neural Network Engine is enabled; it is not selectable per run, and --reprioritize-with-nn does not exist. Re-prioritization is a hint, not a hard reorder - dependency edges are still respected. If item B depends on item A, item B never appears before item A in the output regardless of ML scores. ### Runtime Agent (ANALYSIS ENGINES) URL: https://korthex.io/docs/runtime-agent The Runtime Agent watches a running process and observes the cryptography it actually uses - not what the source code says , but what the binary calls at runtime. Catches dynamic algorithm choice (config-driven), third-party library decisions (chosen at link time), unzeroed key buffers, deprecated library versions, and live TLS handshake characteristics. ### Modes | Mode | Mechanism | Use case | | --- | --- | --- | | Passive | No injection. Observes OS-level signals only: Windows ETW for CNG/Schannel events, loaded-module enumeration, TCP connection table. | Production / shared environments. Works on any process the calling user owns. | | Active | Injects an instrumentation agent for per-call detail. | Pre-production / staging. Highest fidelity. | | Hybrid | Both at once. | Audit-level visibility when you control the target binary. | #### Modes Auto-attach to child processes always runs in passive mode (to avoid disrupting short-lived children). Top-level mode is your choice; descendant processes downgrade automatically. ### What It Captures | Stream | Examples | | --- | --- | | Findings | MD5 / MD4 / RC4 / DES / RC2 hard-flagged on first use. Unzeroed key buffers. Deprecated library versions detected. | | API call log | Every BCrypt / Schannel call observed during the session. | | Memory snapshots | Periodic key-material checks; flags secrets persisting longer than expected. | | Network connections | TLS-port vs plaintext-port classification. | | TLS deep inspection | Every ~10 seconds, opens its own handshake to verify cipher suite / cert chain on each established connection. | #### Using the Agent The Runtime Agent is driven from the Desktop app : open Runtime , pick the target from the process list, and attach. The screen handles the elevation pre-flight, streams the live event view while the session runs, and writes the session out when you detach. Attaching starts a privileged operation, so the screen is gated on the findings.read permission. What you configure before attaching is which streams to record - crypto API calls, network connections, loaded-module enumeration, memory analysis, and key-material tracking. The first three are on by default; memory analysis and key-material tracking are off until you turn them on. The CLI cannot drive a session yet. The runtime verb exists and declares --pid and --path , but it stops after the license check and reports that the engine integration is still pending. It does not attach, does not record, and does not write a session file - treat it as reserved surface, not as a scriptable entry point. # Declared today - refuses with "integration pending", writes nothing korthex runtime --pid 14782 korthex runtime --path ./my-service #### Output Sessions are stored as .krxr (encrypted runtime reports). The session contains both the event stream and a periodic posture snapshot so the file is independently readable without needing access to the original target. The Runtime Agent integrates with Dataflow Engine: a recorded session produces a .kxg.runtime file that can be merged into the static-analysis dataflow graph to show "what's documented to happen" alongside "what actually happened". ### Neural Network Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/neural-network-engine The Neural Network Engine is the on-device neural-network layer that runs as a deterministic fallback after rule-based detectors have done what they can. It answers four specific questions: "is this block doing crypto, and if so what kind?" , "what algorithm is this unknown function call?" , "are these two usages part of the same operation?" , and "which plan items should be tackled first?" The Neural Network Engine runs entirely on-device. No source code, no findings, no scan data ever leaves your machine. Network features (model-update checks) are gated behind explicit user consent and transmit only the current model version string. ### Models | Model | Job | | --- | --- | | Block Classifier | Classifies a code block into one of: PASSWORD_HASHING, INTEGRITY, TRANSPORT, DATA_AT_REST, AUTHENTICATION, KEY_EXCHANGE, RANDOM, CUSTOM_IMPL. | | Algorithm Resolver | Resolves an unknown function call to one of ~150 canonical algorithm classes. | | Relation Predictor | Predicts whether two nearby crypto usages are part of the same logical operation (e.g. "generate key + encrypt with it"). | | Plan Prioritizer | Scalar priority score for re-ordering plan items by predicted impact. | #### When It Runs The Neural Network Engine is consulted only after rule-based detectors complete - it never overrides a high-confidence rule-based finding. Predictions below the per-model confidence threshold are discarded silently to avoid noise. Scanner consults the Block Classifier + Algorithm Resolver during analysis when a call site can't be resolved through static rules alone. Context Engine consults the Relation Predictor to merge findings that belong to the same logical operation. Planner consults the Plan Prioritizer to re-order plan items within each severity bucket. This is not selectable per run - there is no --reprioritize-with-nn switch - and it applies whenever the engine is present with a trained model; when either is missing the planner keeps its rule-based ordering. Dependency edges are resolved first either way, so a re-order never moves an item ahead of something it depends on. ### Files | File | Purpose | | --- | --- | | .kxnn | Encrypted, signed weight file. One per model. | | .kxnn.sig | Detached cryptographic signature. Verified on load; load is refused on mismatch. | #### Files Architecture fingerprint. Each .kxnn carries an architecture fingerprint covering vocabulary and topology. Loading is refused if the fingerprint doesn't match the engine's expected configuration - this protects against model substitution attacks. ### Accuracy Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/accuracy-engine The Accuracy Engine measures how well the scanner is finding what it should be finding. It compares actual scan output against ground-truth corpora and emits standard precision / recall / F1 metrics so users (and Korthex itself) can answer "is the scanner getting better or worse over time?" ### Measurement Modes | Mode | Inputs | Output | | --- | --- | --- | | scanner | The default. --expected is the ground-truth JSON, --actual the scan report JSON. | True positives / false positives / false negatives + precision/recall/F1 + the actual misses[] and false-alarms[] for review. | | migration | The before-snapshot goes in --expected , the after-snapshot in --actual . | Findings resolved, remaining, newly introduced + success rate. | | fp | A known-clean corpus in --clean-manifest , plus --actual . Refuses to run without the manifest. | False-positive rate plus the individual false alarms. | | corpus | Same two inputs as scanner , aggregated across many files. | Micro + macro precision/recall/F1 + per-file breakdown. | #### Measurement Modes One command, four modes, selected with --mode . There is no measure subcommand and the command takes no positional arguments at all: every input arrives through a named option. The mode names below are the values --mode accepts, not the internal engine class names. Inputs are JSON, not .kxr . Both files are read as text and parsed, so hand an encrypted report to --actual and the run fails on the read. Produce the input with korthex scan . --format json --output scan.json . And note the direction of the names: --actual is what gets read, --output is where the result gets written. They are not two spellings of the same thing. ### Tolerance Knobs | Mode | Default tolerance | | --- | --- | | scanner | 2 lines (absorbs whitespace / statement-formatting drift). | | migration | 5 lines (absorbs refactor drift). | #### Tolerance Knobs Source code shifts: whitespace changes, refactors, statement reformatting. Accuracy measurement absorbs these via configurable line tolerance so a perfect detection isn't flagged as a regression just because the target moved two lines. Override it with --line-tolerance . Zero is not "no tolerance": it means "use the mode default", which is why the defaults above are reachable without passing the option at all. Algorithm-name normalization is built in: MD5Sum , md5 , MD-5 all collapse to the same canonical match. Two "Unknown" labels never collapse into a match - accuracy stays honest. #### Using the Engine # Scanner accuracy against a ground-truth file (the default mode) korthex accuracy \ --expected .korthex_ground_truth.json \ --actual scan.json # Migration success rate: before goes in --expected, after in --actual korthex accuracy --mode migration \ --expected before.json --actual after.json # False-positive rate against a known-clean corpus korthex accuracy --mode fp \ --clean-manifest tests/clean-manifest.json --actual scan.json # Aggregate across an entire corpus, with a wider line window korthex accuracy --mode corpus \ --expected .korthex_ground_truth.json --actual scan.json --line-tolerance 5 # Human-readable instead of JSON, written to a file korthex accuracy --expected gt.json --actual scan.json --format table --output accuracy.txt ### CI Gates and Exit Codes | Mode | What is compared | Threshold option and default | | --- | --- | --- | | scanner | Recall, precision and F1, all three at once. One below its floor fails the run. | recall --min-recall (0.8), precision --min-precision (0.0), F1 --min-f1 (0.0) | | corpus | The same three, taken from the micro-averaged figures. | same as scanner | | migration | Success rate against a single floor. | --min-recall (0.8), reused as the migration floor | | fp | False-positive rate against a ceiling. Smaller is better here, so the comparison is inverted. | --min-precision reused as the maximum allowed rate; 0.1 when it is left unset | ### CI Gates and Exit Codes | Exit code | Meaning | | --- | --- | | 0 | Measured, and every threshold in play was met. | | 2 | The run failed: an input was missing or unreadable, or the result could not be parsed. | | 3 | The current license tier does not include the Accuracy Engine. | | 10 | Measured successfully, and a threshold was missed. This is the gate firing, not an error. | #### CI Gates and Exit Codes This command gates by default, whether or not you ask it to. If you drop it into a pipeline expecting a measurement tool, it is a pass/fail step: a scanner or corpus run whose recall falls below 0.8 exits 10 even though no threshold was passed on the command line. Set --min-recall 0 to measure without gating. Two of those reuses are worth reading twice. --min-recall is the migration success floor, and --min-precision is the false-positive ceiling, where a lower number is stricter. The names describe the scanner mode they were built for, not the mode you may be running. #### Run History Every run appends a record to disk unless you pass --no-history . One JSON file per run, named for its UTC timestamp and mode, under %APPDATA%/korthex/accuracy-history/ on Windows and ~/.config/korthex/accuracy-history/ elsewhere. Point it somewhere else with --config-root . The record is a fixed whitelist: timestamp, mode, line tolerance and the metrics for that mode. Findings, file paths and source excerpts are never written, so the history is safe to keep on a shared runner. Nothing prunes it automatically, and a write that fails warns on stderr rather than failing the measurement. #### Why This Engine Exists Cryptographic scanning is full of edge cases. Without measurement, releases can silently regress: a small change to the AST analyzer might fix five findings but break twelve others. The Accuracy Engine is how Korthex itself ensures every release improves rather than degrades detection - and is the engine you reach for when a customer says "you missed something" to prove the regression or confirm the original detection. ### Exploit Engine (ANALYSIS ENGINES) URL: https://korthex.io/docs/exploit-engine The Exploit Engine takes Scanner's cryptographic findings one step further: instead of stopping at "this code uses a weak primitive", it asks the harder follow-up question - "can this weakness actually be exploited in this specific code?" - and produces evidence either way. It works on both source code and compiled binaries : you point it at a project that the Scanner has already analyzed (or directly at an executable, library, or container artifact), and it walks the same finding set with deeper, exploitation-focused analyzers. Status - V1 scope decision pending. The Exploit Engine is currently in a Beta / preview state. Whether it ships as part of Korthex V1 or arrives in V2 is still under discussion. Treat it as a forward-looking feature: the interfaces and outputs are described here so you can plan around it, but availability, edition placement, and feature completeness will be finalized closer to launch. #### What It's For The Scanner answers "where is cryptography used and which uses look weak?" . The Exploit Engine answers the next question on the chain: "of those weak uses, which are realistically attackable in this codebase, and what would an attack look like?" Filter noise from real risk. A finding may be theoretically weak (e.g. AES-ECB) but only invoked in dead code, behind a build flag, or with values that an attacker cannot influence. The Exploit Engine separates these from vulnerabilities that an adversary can actually reach. Demonstrate impact. For findings that are exploitable, the engine produces a minimal, deterministic proof-of-concept description showing the attack steps and the kind of damage (key recovery, authentication bypass, data leak, denial of service). Prioritize remediation. Each target gets an Exploit Likelihood Score so engineering teams know which findings to fix this sprint and which can wait for the migration cycle. Audit your binaries. Works on shipped artifacts (PE / ELF executables and libraries) even when source is unavailable - useful for third-party vendor assessments and supply-chain reviews. ### How It Works | Stage | Input | Output | What Happens | | --- | --- | --- | --- | | Recon | Scanner findings | Attack-surface map | Crypto usages are turned into typed targets, classified against the algorithm baseline, and scored by exploit likelihood. | | Analysis | Attack-surface map + binary | Exploit findings | Each target is examined by specialized analyzers (see below). Binaries are loaded into a CPU emulator so attacks can be evaluated without running them on your machine. | | Attack | Exploit findings | Proof-of-concept set | For confirmed weaknesses, the engine synthesizes the minimal sequence of steps that demonstrate the issue, then validates the PoC by replaying it in emulation. | | Report | Proof-of-concept set | JSON / SARIF document | Final report shaped for human review and CI/CD ingestion. Sensitive payload bytes are scrubbed by an output redactor before emission. | #### How It Works The engine runs a four-stage pipeline. Each stage produces a structured artifact that you can consume independently or chain into the next stage. Each stage can be re-run independently: useful for partial replay (re-rendering a report from a saved PoC set without re-running analysis) or for feeding curated attack surfaces from an upstream tool. ### Analyzer Categories | Category | Looks For | Status | | --- | --- | --- | | ECB Mode Detector | Block ciphers (AES, DES, Camellia, ...) used in ECB mode. Verifies the call path actually reaches the cipher. | Preview-ready | | Hardcoded Secrets | Literal keys, IVs, salts, or HMAC secrets baked into compiled output. Combines entropy heuristics with data-segment scanning. | Preview-ready | | Weak RNG Analyzer | Non-cryptographic random sources (e.g. rand/srand, time-based seeds) feeding into key, IV, or nonce material. | Preview-ready | | Padding Oracle Analyzer | CBC-mode constructions where padding errors are observable to an attacker. | Roadmap | | Key / Nonce Reuse Detector | Same key/nonce pair used across multiple encryptions of attacker-influenced data. | Roadmap | | Timing Side-Channel Analyzer | Comparison or table-lookup patterns whose runtime leaks secret-dependent information. | Roadmap | | TLS Configuration Analyzer | Server / client TLS setups that allow downgrade, weak suites, or insecure renegotiation. | Roadmap | | Reverse-Engineering Risk | Binaries whose key-material handling is easy to recover via static analysis. | Roadmap | | Deprecated Algorithm Mapper | Use of primitives officially deprecated by NIST / BSI baselines, with migration targets. | Roadmap | #### Analyzer Categories Analyzers are the individual detectors that look for a specific class of cryptographic weakness. The roadmap covers the following categories, with the first three available in the current preview and the remainder rolling out as the engine matures: ### Exploit Likelihood Score (ELS) | Factor | Captures | | --- | --- | | Algorithm strength | Where this primitive sits on the baseline ladder (recommended → acceptable → deprecated → disallowed). | | Key length | Effective key bits vs. the minimum demanded by the baseline. | | Mode of operation | Mode-level weaknesses (ECB, CBC without MAC, IV reuse with CTR, ...). | | Key / IV source | Whether secret material is hardcoded, RNG-derived, configuration-bound, or properly random. | | Context | How exposed the call site is (network-facing endpoint vs. private utility, attacker-controllable inputs). | #### Exploit Likelihood Score (ELS) Every target on the attack surface is graded on a 0 - 10 scale that combines five independent factors: The ELS lets you sort the attack-surface map by impact and triage findings at a glance - the highest-scoring targets are the ones an attacker is most likely to chase first. #### Output & CI/CD Exploit reports are emitted as JSON or SARIF 2.1.0 . SARIF output drops directly into GitHub Code Scanning, Azure DevOps, and any other SARIF-aware platform - the same pipeline you use for Scanner findings. # Run Exploit on the latest Scanner report and emit SARIF korthex exploit run latest --format sarif --output exploit.sarif Every finding is labeled by how it was established. A finding confirmed by replaying it in emulation is marked as verified and carries a CVSS v3.1 score; a finding raised by static or heuristic analysis that was not reproduced carries an explicit UNPROVEN marker. The report stays honest about the difference between a demonstrated weakness and a candidate that still needs review. The output redactor enforces a strict prohibited-fields policy: source code, executable bytes, and shellcode never appear in emitted reports, even if upstream data carried them. This makes Exploit output safe to attach to tickets, share with auditors, or upload to managed scanning platforms. #### Ownership Enforcement Offensive analysis is only legitimate against code you own or are explicitly authorized to test. Korthex does not leave that to policy alone: before the Exploit Engine analyzes anything, it verifies that the target is yours to test, and declines any target that is not. That verification happens before analysis begins, and a valid license by itself does not satisfy it. Ownership is a separate precondition. An Enterprise license lets you enable the engine; it does not authorize any particular target. Each target is checked on its own before the engine will touch it. Refusal is clean and explicit. A target that does not clear the check is declined with a clear message, never a crash and never a silent skip, and the decision is recorded. To keep the guard effective, Korthex does not publish how ownership is verified, nor the exact conditions under which a target or the runtime environment is accepted or declined. A valid license alone will not let you point the Exploit Engine at someone else's binary or a scraped repository, and activation itself can be declined in environments Korthex does not support for offensive use. #### Activation & Safety Ownership enforcement governs what you may analyze; the controls here govern how the engine runs. The Exploit Engine performs offensive analysis, so it is gated by default even though it works entirely in emulation. Activating it requires an explicit, license-tier-appropriate opt-in plus acknowledgement of the Terms of Service for offensive use. The CLI and Dashboard surface the toggle clearly, and the engine refuses every call until consent has been recorded. Sandboxed by design. Binaries are loaded into a CPU emulator; they are never executed natively on your machine. Proof-of-concept execution runs in an isolated sandbox with no network access. Auto-disarm. The offensive feature gate closes itself again after a period of inactivity and at session end, so the engine is never left armed longer than it is actively in use. Cooperative cancel. Long-running analyses can be cancelled at any phase boundary; resource budgets (time, memory) are configurable and enforced. Telemetry and federated learning are off by default. Both are opt-in. When telemetry is enabled, only non-sensitive structural events leave the machine; prohibited fields are stripped at the sink. The Exploit Engine is intended for assessing systems you own or have explicit authorization to analyze. Ownership enforcement blocks unowned targets technically, but it does not replace your legal responsibility: authorized use is governed by the Korthex Terms of Service. ### Output & Reports (OUTPUT & MIGRATION) URL: https://korthex.io/docs/output-reports 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 | Format | Free | Community | Business | Enterprise | | --- | --- | --- | --- | --- | | .krx (native encrypted report) | Yes | Yes | Yes | Yes | | .kxi (encrypted inventory) | no | Yes | Yes | Yes | | .kxg.* (encrypted dataflow graph) | no | no | Yes | Yes | | .kxsim (encrypted simulation state) | no | no | Yes | Yes | | SARIF 2.1.0 | no | Yes | Yes | Yes | | CycloneDX CBOM (industry standard) | no | Yes | Yes | Yes | | SPDX SBOM (industry standard) | no | no | Yes | Yes | | JUnit XML (CI consumption) | no | Yes | Yes | Yes | | Plain JSON export | no | no | no | Yes (Enterprise only) | | Plain PDF export | no | no | no | Yes (Enterprise only) | | Custom output templates | no | no | no | Yes (Enterprise only) | #### 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. #### .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) | Field | Meaning | | --- | --- | | id | Per-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. | | severity | Lower-case: critical, high, medium, low. by_severity counts these four; there is no info bucket and no suppressed count. | | category | Formatter 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. | | status | Baseline Registry verdict for the algorithm. Defaults to disallowed when the engine reports none. | | baseline_id | Registry entry the verdict came from. Emitted only when the engine supplied one. | | code_snippet | Code context at the finding site. Sanitized: never includes secret material verbatim. | | backed_by | Comma-separated standards the verdict rests on, as a single string - not an array. | | replace_with | Recommended replacements. fix_available is simply whether this array is non-empty. | | key_usage | KeyUsageProfile block. Emitted only when the engine attached one, so treat it as optional. | | compliance | Per-framework pass/fail/not_applicable tallies, derived from the findings' backed_by values when the report carries no compliance block of its own. | #### 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. ### Auxiliary Formats | Purpose | Extension | Description | | --- | --- | --- | | Dataflow Graph | .kxg (+ sub-variants) | Serialized dataflow graph: code, binary, runtime, config, tls, git. | | Crypto Inventory | .kxi | Encrypted inventory of all cryptographic assets discovered. | | Migration Plan | .krx | Sequenced 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 | .kxfh | Tracks finding-IDs across scans so you see deltas (new / resolved / regressed). | | Simulation State | .kxsim | Migration-simulation persistence: re-loadable, incremental. | | Workspace Bundle | .kxw | Cross-user portable export: passphrase-encrypted archive. | | Runtime Report | .krxr | Encrypted output from the Runtime Agent. | #### 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. ### File Format Reference (OUTPUT & MIGRATION) URL: https://korthex.io/docs/file-format-reference Korthex uses ~30 custom file formats across its engines. This section is the authoritative catalog: every extension, what it stores, whether it's encrypted, whether it's user-editable, and the recommended tooling for inspecting it. User-edit policy. Every Korthex-generated .json file can be user-edited, but this is not recommended unless you know what you are doing - the engines validate strictly and a malformed file will be rejected on next load. Encrypted formats ( .kxi , .kxg , etc.) cannot be hand-edited at all: any modification invalidates the integrity check and the file is refused on load. ### Encrypted Core Formats | Extension | Purpose | Engine | User-editable | | --- | --- | --- | --- | | .krx | Scan report. Also serves as the canonical container for migration plans. | Scanner / Planner | No | | .kxi | Cryptographic-inventory snapshot. Backs CycloneDX / SPDX exports. | Inventory | No | | .kxg | Dataflow graph (with sub-variants below). Magic 'KXGRAPH\0' when plaintext. | Dataflow | No | | .kxnn | Neural Network model weights + vocabulary + signature. | Neural Network | No | | .kxnn.sig | Detached signature over .kxnn. Refuses to load on mismatch. | Neural Network | No | | .kxa | Exploit-Engine attack-pattern database. Korthex-internal key. | Exploit | No | | .kxt | Encrypted HTML report template. | Report | No | | .kxjs | Encrypted JS bundle for report templates. | Report | No | | .kxcss | Encrypted CSS for report templates. | Report | No | | .kxv | Viewer-bundle: report + assets in a single sealed container. | Report | No | | .kxp | Encrypted, canonical policy file. The .korthex_policy.json variant is its human-editable plain-JSON equivalent. | Policy | No | | .kxm | Mesh / migration container. | Mesh-Relay | No | | .kxw | Workspace bundle. Passphrase-encrypted; portable across machines. | Dashboard | No | | .krxr | Runtime-Agent encrypted report (V3). | Runtime Agent | No | #### Encrypted Core Formats All encrypted with authenticated cryptography. Sealed with a key derived from your license + machine binding so a file is only readable on the installation that produced it (or on an installation explicitly authorized to consume it, e.g. via a .kxw workspace bundle). ### .kxg Sub-variants | Extension | Domain | Captures | | --- | --- | --- | | .kxg.code | Source code analysis | How cryptographic values move through the code: variable assignments, function returns, import chains. | | .kxg.binary | Compiled-binary analysis | Crypto usage discovered via AST / bytecode / IL inspection. | | .kxg.runtime | Runtime traces | Algorithms actually invoked when the program executes (from the Runtime Agent). | | .kxg.config | Configuration-file dataflow | Where keys, certs, and crypto settings flow between config files and code. | | .kxg.tls | TLS endpoint dataflow | Cert chains, cipher suites, endpoint relationships. | | .kxg.git | Git-history dataflow | When algorithms were introduced, rotated, or removed across the repo's history. | #### .kxg Sub-variants The Dataflow Engine emits one file per analysis domain. All share the .kxg container but represent different slices of the crypto graph. The Dashboard renders all six variants in a single graph view. The CLI emits them individually so you can pick the slice you need for headless processing. ### Working Artifacts & Caches | Extension | Purpose | Engine | Encrypted | | --- | --- | --- | --- | | .kxcb | Context bundle: the binary projection of the project index, restored instead of re-derived. | Context | No (binary) | | .kxcsic | Semantic-IR cache, one entry per file content hash. Skips the tree-sitter parse and IR walk for unchanged bytes. | Scanner | No (binary) | | .kxcfh | File-hash snapshot. The content-hash set the delta scan compares against. | Scanner | No (binary) | | .kxcf | Per-file findings cache. Supplies the results for files the delta scan does not re-analyze. | Scanner | No (binary) | | .kxgdc | Git commit delta store: per-commit scan results keyed by commit OID. | Git History | No (binary) | | .kxfh | Scan history: finding-ID sets for delta tracking. Plain JSON. | Scanner | No | | .kxsim | Migration-simulation persistence. Re-loadable; tracks incremental simulation state. | Migration Sim | Yes | | .kxcve | Bundled NVD / CPE / KEV / EPSS cache. | Impact / Scanner | No (binary blob) | #### Working Artifacts & Caches The scan caches live in /.korthex_cache/ , next to the code they describe - not under .korthex/ and not in your user profile. They accelerate subsequent scans; all of them are safe to delete, and Korthex rebuilds whatever is missing on the next run. These caches are not redacted. Cache entries store symbol names, file paths and finding payloads of the scanned project in the clear, because they are a verbatim projection of your own source tree. Secret values are never written in the clear - the redaction rule that governs reports governs the caches too. If you scan third-party code under contract, treat .korthex_cache/ as being as sensitive as the checkout itself and delete it with the checkout. ### Updater Artifacts | Extension | Purpose | Cleanup | | --- | --- | --- | | .kxsv | Signed version manifest (versions.bin.kxsv). Lists current vs available builds. | Survives updates. | | .kxbak | Backup of the previous version. Used by korthex-updater rollback. | Retained until the next successful update. | | .kxtmp | Transient download / unpack staging file. | Deleted on update success. | | .kxold | Old-version remnant scheduled for deletion at next launch. | Deleted on next startup. | #### Updater Artifacts The Korthex updater creates several short-lived files during an in-place update. These are cleaned up automatically on a successful run; you'll only see them after a failed update. # If an update fails mid-way, recover with: korthex-updater rollback ### Data Templates & Drop-ins | Suggested filename | Schema | Used by | | --- | --- | --- | | .kxgraph.json | Dataflow graph payload (kxg-code.schema.json) | dataflow_code_analysis_template.html | | .kxreport.json | Impact audience-tailored report (krx-impact-audience.schema.json) | impact_audience_template.html | | .kxcompliance.json | Compliance impact payload (krx-impact-compliance.schema.json) | impact_compliance_template.html | | .kxmp.code | Code migration plan (contracts/code.schema.md) | migration_code_template.html | | .kxmp.binary | Binary migration plan (contracts/binary.schema.md) | migration_binary_template.html | | .kxmp.cert | Certificate migration plan - cert-as-object (contracts/cert.schema.md) | migration_cert_template.html | | .kxmp.config | Config migration plan (contracts/config.schema.md) | migration_config_template.html | | .kxmp.git | Git history migration plan (contracts/git.schema.md) | migration_git_template.html | | .kxmp.tls | TLS protocol-layer migration plan (contracts/tls.schema.md) | migration_tls_template.html | ### Data Templates & Drop-ins | Extension | Purpose | | --- | --- | | .kxt | Encrypted HTML template (static-key encrypted at build time). | | .kxjs | Encrypted JavaScript bundle for templates. | | .kxcss | Encrypted CSS for templates. | #### Data Templates & Drop-ins Korthex's report templates can ingest JSON payloads via drag-and-drop in the Dashboard. The suggested filename on save uses a Korthex-prefixed extension that's still plain JSON underneath - humans get a recognizable name, machines see standard JSON. Korthex also ships encrypted data-template formats used by the report-templating system internally: ### User-Editable Files | File | Purpose | Edit guidance | | --- | --- | --- | | .korthexignore | Path-ignore rules (gitignore syntax). | Safe to edit. Korthex automatically respects .gitignore too. | | .korthex_policy.json | Organizational policy: allowed algorithms, key sizes, deprecation deadlines, exemptions, algorithm aliases. | Edit-heavy by design. JSON Schema published; the file is checked where it is used - korthex check --policy fails hard rather than falling back. | | .korthex_ground_truth.json | Ground-truth dataset for the Accuracy Engine. | Editable for advanced users running their own measurement campaigns. | | .korthex_gui.cfg | Desktop UI privacy / GUI prefs. | Editable. Restart Korthex Desktop after editing. | | mock-findings.json | Fixture for testing IDE plugin integration without running a real scan. | Developer-only file. Safe to delete. | | .korthex/config.json | Per-project configuration (engines on/off, output paths, severity filters). | Safe to edit. CLI: korthex config set . | #### User-Editable Files These files are explicitly designed to be edited by hand. They live at the project root or in your home directory. Korthex re-reads them on every run so changes take effect immediately. The general rule: any .json file Korthex writes can be hand-edited, but doing so without understanding the schema causes the engine to reject the file on next load. There is no separate validation command: the file is checked where it is used, so run korthex check --policy after major changes — it fails hard on a bad file rather than quietly falling back. ### Korthex Airgapped File Formats | File format | Explanation | Used by | | --- | --- | --- | | .kxedition | Allows Korthex to detect an airgapped installation | Korthex Installation Detection | | .kxps | Represents the current safety status of your machine. Generated by Korthex-Preflight.exe | Korthex License Server | | .kxreq | Generated by the Korthex airgapped installation wizard when exporting the installation hash | Korthex License Server | | .krxlic | Contains the installation key for your specific installation. Automatically generated by the Korthex License Server using the .kxreq and .kxps files | Korthex License System | #### Korthex Airgapped File Formats When running Korthex in airgapped mode, several file types are generated to ensure a clean and secure installation without any network connection. All you need is your airgapped machine and a second device with the Customer Dashboard open - file transfer between the two (e.g. via USB drive) is all it takes to complete the setup. ### Flowence Shared Formats | Extension | Purpose | Encrypted | | --- | --- | --- | | .cjsn | Flowence JSON++ columnar-compressed JSON. Stores the algorithm-baseline tables (hash.cjsn, symmetric.cjsn, asymmetric.cjsn, protocols.cjsn, jurisdiction-specific.cjsn) and CVE/KEV/EPSS caches. | No (compression only) | #### Flowence Shared Formats Korthex uses Flowence Infrastructure's shared compressed-JSON format for large reference tables (CVE / KEV / EPSS, baseline algorithm tables). The .cjsn format is the Flowence JSON++ SDK's output. See the SDKs section for details on the broader Flowence file-tool ecosystem. ### Cheatsheet: Which Tool Reads What | I have a | Read it on the CLI with | Read it in an app in | | --- | --- | --- | | .krx report | korthex decrypt | Desktop → Reports. The screen lists the .krx files already in the workspace folder and decrypts the one you pick; neither app takes a file upload. | | .kxi inventory | No CLI reader. | Inventory, in both apps - Files / Census / PQC Readiness / Snapshot Diff. The Web Dashboard also accepts a .kxi upload. | | .kxg dataflow graph | korthex dataflow view | Desktop → Dataflow. The Web Dashboard route is disabled today. | | .kxsim simulation | korthex sim inspect | Desktop → Migration → Simulation (and Diff). The Plans tab does not read .kxsim, and the Web plans page is driven by the API rather than by the file. | | .kxfh history file | No reader needed - it is a plain JSON array. Any JSON tool opens it. | Nothing reads this file directly. The Trends view is fed by the API, not by scan_history.kxfh. | | .kxw workspace bundle | No CLI reader. | Desktop → workspace switcher → Import workspace. It is in the switcher, not under Settings, and the Web Dashboard has no workspace import. | | .krxr runtime report | No CLI reader. | Nothing reads it yet. The Runtime screens export runtime-report.json / .html; the .krxr container is written by the engine and has no client-side viewer. | #### Cheatsheet: Which Tool Reads What Three of the seven have no CLI verb at all. .kxi and .kxw are app-only; .krxr has no viewer on either side yet. If a pipeline needs one of them, read the file directly - there is no command waiting to be discovered. ### Auto Migration (OUTPUT & MIGRATION) URL: https://korthex.io/docs/auto-migration Auto Migration closes the loop between finding a cryptographic weakness and fixing it. Instead of producing a migration plan for a human to execute by hand, the engine generates the actual code changes - context-aware, across files, and fully automatic - and presents them as a reviewable diff before anything lands in your repository. Status - planned for Korthex V2. Korthex V1 already supports migration planning and simulation (see the korthex plan create and korthex migrate --dry-run commands). The fully automatic, context-aware execution path described below is on the V2 roadmap. The exact V2 release timeline will be announced separately. ### V1 vs. V2 at a Glance | Capability | Korthex V1 | Korthex V2 (planned) | | --- | --- | --- | | Generate migration plan from findings | Yes | Yes | | Estimate impact (files, modules, blast radius) | Yes | Yes | | Simulate migration (preview changes without writing) | Yes | Yes | | Context-aware code rewrites (cross-file, dataflow-aware) | No | Yes | | Apply changes automatically | No | Yes | | Generate verification tests for changed call sites | No | Yes | | One-click rollback to pre-migration baseline | No | Yes | #### V1 vs. V2 at a Glance The migration story is staged: V1 helps you understand and rehearse a migration; V2 actually performs it. #### Today: Plan & Simulate (V1) V1 ships the read-only half of the migration workflow. You can plan, estimate, and dry-run any migration the Scanner identifies - nothing on disk changes until you act on the output yourself. # 1. Run a scan korthex scan . # 2. Generate a migration plan from the latest report korthex plan create # 3. Read the plan back korthex plan list korthex plan view # 4. Preview the changes without writing anything korthex migrate --dry-run The stored plan captures the planned migration in a portable encrypted format you can review, share, or feed into V2's auto-apply pipeline once it ships. Blast-radius estimation lives under its own command rather than under the planner: korthex impact cost , korthex impact roadmap , korthex impact audience , korthex impact compliance and korthex impact executive-summary . There is no migrate impact . #### Coming in V2: Context-Aware Auto-Migrate V2 takes the same .krx plan and executes it. The execution is context-aware : it doesn't blindly find-and-replace, it understands the surrounding code - the algorithm's call graph, the way keys and IVs flow through your modules, the testing patterns you use, and the language-specific idioms of every file it touches. What "context-aware" means Dataflow follows the value. If a deprecated primitive is wrapped inside three layers of utility functions across four files, the migration rewrites all the call sites consistently - not just the one the Scanner flagged. API shape is preserved. When a replacement algorithm has a different parameter list or return shape, the engine adapts call sites so the surrounding code keeps compiling. Language- and framework-idiomatic output. Java migrations follow Java conventions, Go migrations follow Go conventions; framework-specific helpers (Spring Security, Django, ASP.NET Data Protection, ...) are used where applicable. Tests are migrated and generated. Existing tests that exercise the replaced primitive are updated; new verification tests are added where coverage gaps are detected. Imports, dependencies, and config files are reconciled in lockstep with the code changes - nothing is left dangling. The intended workflow The V2 command surface is not designed yet, so no syntax is shown here - an example you could copy would be one you could not run. The intended sequence is: create the plan exactly as in V1, have V2 perform the rewrites against a working copy, then review the generated diff, run your test suite, and accept or revert. Of that sequence only plan creation and the dry-run exist today; execution against a working copy, the review gate, and accept/revert do not. Nothing lands silently. Even with full auto-migration, the default workflow is diff → review → accept . The engine prepares the work; you approve before it touches your main branch. Headless modes for trusted automation pipelines are planned but always opt-in. #### Safety Model An auto-migration tool is only as good as the safety net around it. The V2 design is built on three guarantees: Always reviewable. Every change shows up as a normal diff against your working tree. No hidden writes, no out-of-band edits. Always reversible. The pre-migration baseline is captured in the .krx plan file. A single command rolls every change back. Always tested. The engine compiles the result and runs your test suite before reporting success. If anything fails, the migration is left staged for human inspection rather than committed. Auto Migration will respect the same policy engine ( .kxp files) that governs Scanner: organizational restrictions on permitted algorithms, key sizes, and configurations are honored automatically during code generation. ### Configuration (CONFIGURATION) URL: https://korthex.io/docs/configuration Korthex is configured through a combination of project-level config files, CLI flags, and environment variables. The project configuration file is korthex.json in the project root; scan caches are written to .korthex_cache/ beside it. #### Project Configuration Run korthex config --init to write the default project configuration to korthex.json in the current directory: { "maxFiles": 100000, "timeoutSeconds": 300, "engines": "", "languages": "", "outputFormat": "krx", "excludeDirs": "node_modules,.git,build,dist,target,bin,obj", "excludeExtensions": ".exe,.dll,.so,.dylib,.bin,.zip,.tar,.gz" } Empty engines and languages mean "all". Validate an edited file with korthex config --validate --strict , which runs the engine validator rather than a plain JSON syntax check. There is no cache block in this file. The scan cache is not configurable from here: it always lives in /.korthex_cache/ and is steered at scan time by the incremental and fullRescan keys of the scanner configuration. #### .korthexignore The .korthexignore file uses gitignore syntax to exclude files and directories from scanning. # Dependencies node_modules/ vendor/ .venv/ # Build outputs dist/ build/ out/ target/ # Test fixtures with intentional weak crypto test/fixtures/legacy-certs/ test/vectors/ # Generated code *.generated.cs *.g.dart Korthex automatically respects .gitignore rules. Use .korthexignore for additional exclusions specific to scanning. ### Engine Toggles | Engine | Config Key | Default | | --- | --- | --- | | AST Analysis | engines.ast | enabled | | Binary Analysis | engines.binary | enabled | | Runtime Analysis | engines.runtime | enabled | | TLS Analysis | engines.tls | enabled | | Git History | engines.gitHistory | enabled | | Config Analysis | engines.config | enabled | #### Engine Toggles Each scan engine can be individually enabled or disabled: # Disable runtime and git-history engines korthex config set engines.runtime false korthex config set engines.gitHistory false ### Detection Toggles | Toggle | Description | Default | | --- | --- | --- | | detection.weakHashes | MD5, SHA-1 usage detection | enabled | | detection.weakCiphers | DES, 3DES, RC4, Blowfish | enabled | | detection.smallKeys | RSA < 2048, ECC < 256 | enabled | | detection.ecbMode | ECB mode block cipher usage | enabled | | detection.hardcodedKeys | Literal keys in source | enabled | | detection.expiredCerts | Certificate expiration checks | enabled | | detection.weakTls | TLS 1.0/1.1, weak cipher suites | enabled | | detection.pqcReadiness | Post-quantum readiness assessment | enabled | | detection.insecureRandom | Math.random(), rand() for crypto | enabled | | detection.nullIv | Null/zero initialization vectors | enabled | | detection.pkcs1v15 | PKCS#1 v1.5 padding (Bleichenbacher) | enabled | | detection.staticSalt | Hardcoded or missing salt in hashing | enabled | #### Detection Toggles Fine-tune what Korthex detects: ### Environment Variables | Variable | Description | | --- | --- | | KORTHEX_ENGINE_DIR | Directory the CLI loads the engine libraries from, instead of the one it derives from its own install location. | | KORTHEX_CI_TOKEN | The CI token korthex ci verifies against the backend. Only consulted when it is set. | #### Environment Variables The environment is not a configuration surface here. Two variables are read on the CLI path, and that is the whole list: Nine other variables were documented here and none of them exists. If a pipeline of yours sets KORTHEX_HOME , KORTHEX_LICENSE , KORTHEX_LICENSE_FILE , KORTHEX_LOG_LEVEL , KORTHEX_LOG_LEVEL_ , KORTHEX_LOG_FILE , KORTHEX_NO_TELEMETRY , KORTHEX_PARALLEL or KORTHEX_TIER_OVERRIDE , it has never had an effect. Nothing in the product reads any of them. Verbosity and thread count are configuration keys ( global.logLevel , global.maxThreads ); telemetry is the --no-telemetry flag; licensing goes through the license command. ### Policy File Syntax | File | Use for | | --- | --- | | .kxp | Encrypted, canonical form. Loads fastest; tamper-resistant; the form Korthex emits when you export a policy. Recommended for production and CI. | | .korthex_policy.json | Plain-JSON form. Human-readable, editable in any text editor or IDE, version-controllable in plain diffs. Recommended for authoring and review. | ### Policy File Syntax | Profile | Posture | | --- | --- | | strict | Anything below recommended is a finding. No legacy carve-outs. | | balanced | Acceptable is fine; deprecated is a finding; legacy carve-outs allowed via exemptions. | | legacy | Only disallowed primitives raise findings. For migrating brownfield codebases. | ### Policy File Syntax | Action | Effect | | --- | --- | | severity: | Re-grade matching findings to a specific severity. | | action: ignore | Suppress matching findings entirely. | | action: promote | Bump matching findings up one severity level. | | action: demote | Drop matching findings down one severity level. | #### Policy File Syntax The policy file is the single place where your organization's algorithm rules, key-size thresholds, deprecation deadlines, and finding-level exemptions live. Korthex supports two interchangeable forms of the same schema: The two are equivalent and either form is accepted by every command that takes a --policy argument. There is no converter command - translate by hand. The .json form is intentionally editable by hand. There is no standalone validator command; the file is checked when a command loads it, and a malformed or unusable policy exits 41 (not 3 - that is the license code). A single missing brace breaks every dependent engine, so exercise a changed policy with korthex policy evaluate --report before you rely on it in CI. Complete example { "schemaVersion": 2, "profile": "balanced", "scanMode": "full", "minimums": { "rsaBits": 2048, "ecBits": 256, "aesBits": 128, "hashBits": 224, "kdfIterations": 600000 }, "deadlines": { "MD5": "2024-12-31", "SHA-1": "2025-12-31", "3DES": "2025-12-31", "RSA": { "below": 2048, "by": "2025-12-31" }, "PQC-migration": "2030-12-31" }, "overrides": [ { "rule": "ECB_MODE_DETECTED", "match": { "file": "tests/fixtures/**" }, "severity": "info", "reason": "Known test fixtures for negative-path tests." }, { "rule": "*", "match": { "file": "vendor/**" }, "action": "ignore", "reason": "Vendor code we do not own." } ], "exemptions": [ { "id": "TKT-9412", "findingFingerprint": "sha256:9c5a3f1b...", "expires": "2026-12-31", "approver": "security-team@acme.com", "reason": "Legacy auth path; scheduled for replacement in Q4." } ], "algorithm-aliases": [ { "wrapper": "com.acme.crypto.SecureHash.compute", "wrapped": "SHA-256", "language": "java" }, { "wrapper-regex": "^acme_legacy_hash_v\\d+$", "wrapped": "MD5", "language": "c" } ], "ciEnforcement": { "mode": "warn-then-block", "failOn": "high", "maxCritical": 0, "maxHigh": 5 } } Profile values Override actions Exemption rules Exemptions must carry an expires date. There is no permanent exemption mechanism by design. The findingFingerprint is a policy-file key. Note that the JSON report emits no fingerprint field, so it cannot be copied out of a report - see Sample Finding JSON . Expired exemptions automatically promote the underlying finding back to its original severity. There is no command that lists active exemptions; read them out of the policy file. Validate & apply # Exercise the policy against a report (this is also the schema check) korthex policy evaluate --report report.krx # Enforce it: exit 1 on violation, 41 if the policy file is unusable korthex policy enforce --report report.krx --fail-on-violation ### Performance Tuning | Scenario | Recommendation | | --- | --- | | First scan on a fresh checkout | Nothing to do. There is no snapshot yet, so the run is a full analysis and reports delta_scan_fallback: no-cache while it primes the cache. | | CI on an ephemeral runner | Nothing to do. Without a preserved .korthex_cache/ every run is cold, and the cache write is what makes the next run cheap if you ever do preserve it. | | CI on a persistent runner | Preserve /.korthex_cache/ between builds. That directory is the whole cache; nothing else needs restoring. | | Local development | Leave the default on. Changed files and their importers are re-analyzed; everything else is reused. | | Forcing a clean run | Set fullRescan: true, which ignores the snapshot and wins over incremental. There is no cache subcommand - to discard the cache instead, delete the .korthex_cache/ directory. | | A cache you do not trust | You do not have to guess. A snapshot that is missing, stale, out of scope or corrupt is never trusted partially: the scan silently degrades to a full analysis and names the reason in delta_scan_fallback. | ### Performance Tuning | Key | Default | When to set | | --- | --- | --- | | global.maxThreads | 0 (one worker per core) | Runners that share a machine, or a run you want to keep off the other cores. Bounds how many analyzers hold memory at once. | | global.timeoutSeconds | 0 (no limit) | A whole-scan wall-clock budget. Accepted range is 0 to 86400. | | codeAnalysis.ast.maxFileSizeBytes | 4194304 (4 MiB) | Files above this are not parsed into a syntax tree. They are still scanned by pattern detection, so raising it buys depth and costs memory, and lowering it does the reverse. | | codeAnalysis.ast.parseTimeoutMs | 2000 | Per-file parse budget. A generated file that blows past it is abandoned rather than allowed to stall the pass. | | codeAnalysis.ast.queryTimeoutMs | 1000 | Per-file budget for running the detection queries over an already-parsed tree. | #### Performance Tuning The two knobs that matter on large repositories are thread count and the delta scan. Both are configuration keys, not CLI flags. Parallelism Thread count is set by global.maxThreads in the scanner configuration. The default, 0 , means "one worker per logical CPU". Lower it on CI runners whose memory budget is smaller than their core count suggests. { "scanPaths": ["."], "global": { "maxThreads": 4 } } Cache Strategy The delta scan is on by default ( incremental: true ). It compares a content hash per file - not a timestamp - re-analyzes the files whose bytes changed plus the transitive hull of everything importing them, and serves the rest from the findings cache. The merged result runs through the same whole-set pipeline as a full scan, so a delta run and a full run of the same tree emit identical artifacts. Engine Toggles for Large Repos Engine selection is a configuration block, not a flag. Disable the engines a given run does not need and pass the file with --config . The canonical shape nests the toggles under subEngines : { "scanPaths": ["."], "engines": { "subEngines": { "gitHistory": false, "binary": false } } } The keys are codeAnalysis , tlsCert , config , gitHistory , runtime , binary , database and exfil . The older flat form, with the toggles directly under engines and no subEngines level, is still read, but each key that arrives that way logs a deprecation warning naming the nested path. Switching every engine off is rejected: the parser requires at least one enabled engine and fails the scan at config validation, before any file is read. Narrowing the walk itself is usually the bigger lever: put shared vendor and build directories into globalFilters.paths.exclude so every engine skips them at once, rather than excluding them per engine. Budgets and Limits These are configuration keys as well. None of them has a command-line switch. There is no memory-ceiling setting, and adding one would not be the lever it sounds like. The scanner regulates its own memory at phase boundaries and gives memory back instead of aborting, precisely because an earlier threshold guard killed healthy runs. To hold peak memory down, narrow the walk and lower global.maxThreads . Profiling a Slow Scan Timing lives in the log, not in the report and not in a flag. Raise global.logLevel and the phases that measure themselves print their durations. Accepted levels are OFF , ERROR , WARN , INFO , DEBUG and TRACE , matched case-insensitively; the default is already INFO , which is the level the timing lines are written at. { "scanPaths": ["."], "global": { "logLevel": "INFO", "maxThreads": 4 } } Be precise about what this gets you, because it is less than a profiler. Six call sites report a duration: the five Context passes (reference resolution, context analysis, neural resolution, taint map, cross-file clusters) and the post-processing enrichment phase. Everything else runs unmeasured. There is no --profile flag, no per-file timing breakdown and no machine-readable timing artifact of any kind: the report carries findings, not durations. If you need per-file numbers today, the honest answer is that Korthex does not produce them. If a single file dominates scan time, it is almost always either auto-generated code, a vendored dependency, or a giant bundle. Adding it to .korthexignore is usually the right answer. ### Error Codes & Troubleshooting (CONFIGURATION) URL: https://korthex.io/docs/error-codes A consolidated reference for the error codes the CLI and engine surface, plus the most common causes and the fix path for each. When in doubt: set global.logLevel to DEBUG in the config file and re-run; the log will reference the same codes and point to the failing component. ### CLI Exit Codes | Exit code | Meaning | When you see it | | --- | --- | --- | | 0 | Clean | Completed, and no threshold in play was crossed. | | 1 | Findings present | The run produced findings. Expected, not an error. Note that this number is deliberately avoided by korthex check, because it already carries more than one meaning. | | 2 | Generic failure | The catch-all for a failure with no more specific class. | | 3 | License required | The operation needs a tier the active license does not grant. | | 4 | Usage error | Unknown flag, missing required option, invalid value. | | 5 | Cancelled | User-initiated cancel, or the native timeout/cancel class. | | 10 | Quality gate failed | A gate fired on a measured value: accuracy below its threshold, coverage below target. The measurement itself succeeded. | | 20 | Baseline mismatch | A baseline or contract comparison did not match. | | 30 | Policy violation | A rule the operator wrote said no. | | 31 | Policy input unreadable | The policy engine could not read the report it was asked to judge. Distinct from 30 on purpose: "I never looked at your report" is not "I looked and found violations". | | 32 | Policy not loaded | Evaluate or enforce was reached with no policy loaded at all. | | 33 | Check threshold exceeded | At least one finding at or above the --fail-on severity. Distinct from 30: 30 is a written rule, 33 is the ceiling passed on the command line. | | 34 | CI token rejected | The backend definitively refused KORTHEX_CI_TOKEN . A backend that could not be reached is not this code: that outcome is disclosed and the run continues on its local verdict. | | 35 | Check scan timeout | The scan exceeded the policy-declared wall clock. Distinct from 5, which a user-initiated abort also produces. | | 40 | Configuration invalid | The scan or CI configuration was missing, malformed or rejected. | | 41 | Policy source invalid | A policy file was found but is not a usable policy: empty, unparsable, not a JSON object, or oversized. It never governed anything, and it never falls through to the next tier. | | 50 | Decryption failed | The report could not be decrypted or failed its integrity check. | | 60 | Infrastructure error | An outage on the service side. | | 61 | Backend unavailable | The backend could not be reached. | #### CLI Exit Codes Every Korthex CLI command returns a stable exit code so that scripts and CI gates can react reliably. The numbers are banded, and the bands are the part worth branching on when a specific code is not: 0-9 core outcomes, 10-19 quality gates, 20-29 baseline and contract, 30-39 policy, 40-49 configuration, 50-59 integrity, 60-69 infrastructure. Bands are sparse on purpose so a new class never reuses an old number. ### Common Issues | Symptom | Likely cause | Resolution | | --- | --- | --- | | "License missing" on first run | Activation step not completed. | Run korthex license activate KX-XXXX-XXXX-XXXX-XXXX or set KORTHEX_LICENSE. | | "License server unreachable" | Offline machine without offline-activation token. | Use the challenge/redeem flow under License Management → Offline Activation. | | Scan finishes with 0 findings on a real codebase | Path matched .korthexignore or .gitignore aggressively; or all detection toggles off. | korthex config show; check the ignore rules and detection.* toggles. | | Scan is unexpectedly slow on a repo that was fast yesterday | The cache was invalidated, so the run fell back to a full analysis. A Korthex upgrade does this by design: the engine binary is part of the cache fingerprint, so the first scan after an update is cold. | Expected once per upgrade - the next scan is incremental again. To confirm the reason rather than guess it, read delta_scan_fallback in the report: it names why the snapshot was not used. | | High false-positive count | Context Engine disabled, or test fixtures not excluded. | Re-enable context (default); add test/ paths to .korthexignore. | | "Cannot parse .kxr" | Wrong tool version reading a newer report. | Update Korthex on the reading side. .kxr forward-compatibility is best-effort but not guaranteed across major versions. | | "Schema mismatch" | Input file from a newer Korthex than the current binary. | Update Korthex, or re-emit the file from a version-compatible source. There is no exit code reserved for this class; it surfaces as a generic failure. | | IDE plugin shows no findings | CLI path misconfigured or CLI not on PATH. | Settings → Tools → Korthex → set the CLI Path explicitly; restart IDE. | | Korthex Remote: "License mismatch" | Phone paired with a desktop on a different license seat. | Revoke from desktop; re-pair with the correct desktop. Mobile auto-routes back to login. | | Mesh-Relay: "SPKI pin file not found" (fail-closed) | Pin file missing or path misconfigured in relay_config.json. | Either provide the pin file or remove Mesh-Relay configuration entirely. | | Exploit Engine: "GATED" | Feature gate is closed (default state). | Open the gate via the Dashboard toggle or the host SDK; acknowledge ToS. | | Build: "out of memory" on large monorepo | Too many analyzers holding memory at once. | Lower global.maxThreads in the config file. Neither parallelism nor engine selection has a command-line switch; to run the light engines first, turn the heavy ones off under engines.subEngines and re-run with them back on. | ### Logs & Diagnostics | Value | What it does | | --- | --- | | OFF | Suppresses every log call. | | ERROR | Failures only. The quietest useful setting for CI. | | WARN | Adds recoverable engine-internal notices. | | INFO | The default. Adds phase transitions and the durations that the Context passes and the enrichment phase report. | | DEBUG | Verbose diagnostic detail. This is the level to attach to a bug report. | | TRACE | Accepted, but it is an alias: the logger maps it onto DEBUG and there is no finer level behind it. | ### Logs & Diagnostics | Platform | Root | | --- | --- | | Windows | %APPDATA%/Korthex/ | | macOS | ~/Library/Application Support/Korthex/ | | Linux | $XDG_CONFIG_HOME/Korthex/ | | Linux, no XDG_CONFIG_HOME | ~/.config/Korthex/ | #### Logs & Diagnostics Log Levels The level is a configuration key, global.logLevel , read from the file you pass to --config . There is no --log-level switch. The value is matched case-insensitively and the default is INFO . { "scanPaths": ["."], "global": { "logLevel": "DEBUG" } } No environment variable sets the log level. KORTHEX_LOG_LEVEL and per-engine variants of it do not exist anywhere in the product, and neither does a --log-file switch. What is true is the fact those invented variables were reaching for: every engine carries its own logger instance, so a level set for one does not propagate to the others. Today only the scanner reads global.logLevel and applies it to its own logger. Log Locations Every component writes under one per-user root, and each engine gets its own subdirectory below it with a session-stamped file name: /logs/engines// . Crash Reports On a crash, Korthex emits a minidump ( .dmp ) plus a JSON sidecar to the configured crash directory (default: alongside the log directory under crashes/ ). The minidump excludes source-code memory pages via the built-in redactor; the JSON sidecar contains environment metadata only. When opening a support ticket, attach: the crash sidecar JSON, the last log file from the same session, and the command line that triggered the issue. Do not attach minidumps over public channels - they may contain residual heap data; ship them through the support portal upload only. ### Where to Get Help | Channel | Best for | Response time | | --- | --- | --- | | Documentation search (this site) | Quick reference, syntax, formats. | Instant | | Community Discord / Slack | Usage questions, sanity checks, recipes. | Hours (community-driven) | | Email support (Community+) | Account-specific issues, bug reports. | Business day | | Chat support (Business+) | Faster triage, demo questions. | Same business day | | Dedicated CSM (Enterprise) | Roadmap input, escalations, deployment review. | SLA-bound | ### IDE Plugins (INTEGRATIONS) URL: https://korthex.io/docs/ide-plugins Korthex integrates directly into your development environment with plugins for IntelliJ IDEA and Visual Studio Code, providing real-time cryptographic analysis as you write code. ### IntelliJ IDEA | Setting | Description | | --- | --- | | CLI Path | Path to the korthex binary (auto-detected if on PATH). | | Scan on Save | Enable/disable automatic scanning when files are saved. | | Severity Filter | Minimum severity level to display in the editor. | | Engines | Select which scan engines to use for IDE scanning. | | Context Engine | Enable/disable context-aware analysis for IDE scans. | #### IntelliJ IDEA Installation Install from the JetBrains Marketplace: search for "Korthex" in Settings → Plugins → Marketplace . Features 60+ inspection rules covering weak algorithms, insecure modes, small keys, hardcoded secrets, and more. Inline annotations - findings appear directly in the editor gutter with severity indicators. Quick-fix actions - one-click replacements for common issues (e.g., SHA-1 to SHA-256). 3 tool windows - Findings overview, Crypto Inventory browser, and Scan History. Real-time scanning - re-analyzes files on save with incremental indexing. Runtime analysis - attach to a running JVM to detect runtime crypto operations. Settings Configure the plugin in Settings → Tools → Korthex : Supported IDEs IntelliJ IDEA, WebStorm, PyCharm, GoLand, Rider, CLion, Android Studio, and all other JetBrains IDEs based on IntelliJ Platform 2024.1+. #### VS Code Installation Install from the VS Code Marketplace: search for "Korthex" in the Extensions panel or run: code --install-extension korthex.korthex-vscode Features Inline diagnostics for cryptographic findings. Problems panel integration with severity-based filtering. Command palette actions: Scan File, Scan Workspace, Show Report. Status bar indicator showing scan state and finding count. ### CI/CD Integration (INTEGRATIONS) URL: https://korthex.io/docs/ci-cd Korthex is designed to run in automated pipelines. The check command provides exit codes suitable for gate checks, and output formats like SARIF integrate directly with code scanning platforms. #### GitHub Actions name: Korthex Crypto Scan on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # Signature-verified install: the script pins the Ed25519 release key and # aborts (non-zero, nothing written) if the manifest or artifact does not # verify against it. - name: Install Korthex run: curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash - name: Run Scan run: korthex check . --fail-on high --format sarif --output results.sarif - name: Upload SARIF if: always() uses: github/codeql-action/upload-sarif@v3 with: sarif_file: results.sarif #### GitLab CI korthex-scan: image: ubuntu:22.04 stage: test script: # ubuntu:22.04 is a minimal image: curl and CA certificates are not preinstalled. - apt-get update -qq && apt-get install -y -qq curl ca-certificates - curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash - export PATH="$HOME/.korthex/bin:$PATH" # --format gitlab-cq is what the Code Quality widget parses. --format json # emits the check SUMMARY, which GitLab accepts and then renders as nothing. - korthex check . --fail-on high --format gitlab-cq --output gl-korthex-report.json artifacts: when: always reports: codequality: gl-korthex-report.json paths: - gl-korthex-report.json #### Azure DevOps - task: Bash@3 displayName: 'Korthex Crypto Scan' inputs: targetType: 'inline' script: | curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash korthex check . --fail-on high --format sarif --output $(Build.ArtifactStagingDirectory)/korthex.sarif - task: PublishBuildArtifacts@1 inputs: PathtoPublish: '$(Build.ArtifactStagingDirectory)/korthex.sarif' ArtifactName: 'KorthexResults' #### Jenkins pipeline { agent any stages { stage('Korthex Scan') { steps { // Without this the agent has no korthex on PATH. sh 'curl -fsSL https://api.korthex.flowence.cc/api/version/install.sh | bash' sh 'export PATH="$HOME/.korthex/bin:$PATH" && korthex check . --fail-on high --format sarif --output korthex.sarif' } post { always { archiveArtifacts artifacts: 'korthex.sarif' } } } } } ### Dashboard (INTEGRATIONS) URL: https://korthex.io/docs/dashboard The Korthex Dashboard provides a web-based interface for managing projects, viewing findings, tracking trends, and generating compliance reports. Available with Community, Business, and Enterprise plans. #### Projects Each repository or codebase is represented as a project. The project view shows: Latest scan results with finding counts by severity. Trend charts showing finding counts over time. Language and framework breakdown. Compliance status across NIST and BSI frameworks. Scan history with comparison between runs. #### Findings The findings view provides: Filterable list of all findings across projects. Detailed finding view with source code context, taint evidence, and remediation guidance. Bulk actions: suppress, assign, change severity, add notes. Cross-file cluster visualization showing related findings. #### Reports & Export Generate and download reports from the dashboard: Executive summary PDF for stakeholder communication. Full technical report with all finding details. Compliance audit report mapped to NIST/BSI requirements. CBOM export in CycloneDX format. Trend reports showing progress over configurable time windows. ### Korthex Remote (INTEGRATIONS) URL: https://korthex.io/docs/korthex-remote Korthex Remote is the mobile companion app for Korthex Desktop. It lets you stay on top of your cryptographic posture from your phone - review findings, trigger remote scans, monitor active operations, and receive critical alerts wherever you are. The desktop and your phone communicate through an end-to-end encrypted channel relayed by a zero-knowledge server : the relay only routes opaque, signed envelopes between paired endpoints and never sees the contents of your data. Pairing is persistent and revocable from either side. Korthex Remote is currently available for Android (8.0 / API 26 and above) . An iOS version is on the long-term roadmap but not yet scheduled. ### Installation | Component | Requirement | | --- | --- | | OS | Android 8.0 (API 26) or newer | | Storage | ~30 MB for installation | | Network | Wi-Fi or mobile data - same network as the desktop is NOT required | | Camera | Required for QR-code pairing | | Korthex Desktop | Installed and signed in with a valid Korthex license on at least one machine | #### Installation System Requirements Getting the App Korthex Remote will be distributed through the Google Play Store on launch. During the beta period, an APK is available on request from your Korthex account portal. Korthex Remote is a free companion app. A paid Korthex Desktop license is required to pair and use it. #### Pairing Your Phone Pairing connects your phone to a specific Korthex Desktop installation. The first pair takes about a minute. Once paired, the phone and desktop reconnect automatically whenever both come online - no QR rescan needed. Step 1 - Sign in on Mobile On first launch, the mobile app asks for your Korthex account email and a 4-digit PIN . The PIN is generated automatically by Korthex Desktop and rotates every 30 seconds. Open Korthex Desktop on your computer. Navigate to Settings → Pairing . The current PIN is displayed in a large monospaced card with a 30-second countdown. Type the email and PIN into the mobile app before the countdown runs out. The PIN never travels to a third party - it is verified by the Korthex backend against your active license. Wrong PIN attempts are rate-limited. Step 2 - Scan the QR Code After login, the mobile app opens its camera scanner. On Korthex Desktop, click "Generate Pairing Code" in the Pairing tab - a QR code appears with a 90-second validity window. Hold your phone up and scan it. Step 3 - Verify the Code (SAS) Once the phone scans the QR, both devices independently derive the same 6-digit verification code (Short Authentication String) from the cryptographic key exchange. Compare the digits on both screens - they must match exactly. This step protects against a sophisticated attack where someone intercepts the pairing in transit. If the numbers differ, abort the pairing and try again. After the codes are confirmed identical, tap Confirm on the desktop. Step 4 - Done The phone is now paired. It appears in Settings → Pairing → Linked Devices on the desktop, and the mobile app lands on the dashboard. The pairing is persistent: the next time both come online they reconnect silently. The pairing code (QR) expires after 90 seconds. If you miss the window, just generate a new one. ### Mobile Dashboard | Tile | Shows | | --- | --- | | Critical | Number of open critical findings. | | High | Number of open high-severity findings. | | Resolved (24h) | Findings closed or remediated in the last 24 hours. | #### Mobile Dashboard The dashboard is the home screen of Korthex Remote. It summarizes the security posture of the connected desktop at a glance. Posture Card A traffic-light header ( Healthy , Watch , Degraded , Critical ) summarizing the overall security state of the desktop, plus three tiles showing live counts: Tap any tile to jump straight into the findings list filtered by that severity. Quick Actions A 2×2 grid of one-tap shortcuts: Open Inbox , View Findings , Trigger Scan , and Manage Connection . The Inbox tile also displays an unread-count badge. Recent Alerts Inline preview of the three most recent events from the inbox - newest first - for at-a-glance situational awareness without leaving the dashboard. Connection Strip A persistent header bar shows the active desktop instance name, platform tag (e.g. "Windows Server 2022", "macOS 14"), and live connection state ( Online , Reconnecting , Offline ) with measured latency. ### Inbox & Findings Browser | Event Type | Description | | --- | --- | | Panic | Server-broadcast alerts requiring immediate acknowledgement. | | Finding | A new cryptographic finding was detected during a scan. | | Scan | Scan started, progressed, completed, or failed. | | System | Connection events, certificate expirations, pairing requests, session changes. | #### Inbox & Findings Browser Inbox The inbox is the chronological event feed pushed from your desktop. Filter by event type, severity, or unread-only with the filter chips at the top of the screen. Findings Browser The findings tab opens directly onto the open-findings list with severity tabs (Critical / High / Medium / Low / Info) at the top. Each row shows the title, affected asset, rule, and a relative timestamp. Finding Detail Tapping a finding opens the detail view with a colored severity stripe and the following sections: Identity - asset path, rule, CVSS score. Timeline - first seen, last seen, current status (Open / Acknowledged / Muted / Resolved). Description - what was detected and why it matters. Evidence - supporting context from the analysis (without leaking your source code itself). Remediation - recommended fix steps. ### Triggering Remote Scans | Profile | Best For | Typical Duration | | --- | --- | --- | | Quick | Fast sanity check on staged or recently changed files. | Seconds to a minute | | Standard | Full project scan with the default engine set. | Minutes | | Deep | Maximum-depth scan with every engine and full context analysis enabled. | Tens of minutes on large repos | #### Triggering Remote Scans You can start a scan on your paired desktop directly from your phone. The desktop executes the scan locally - your source never leaves the machine - and pushes progress and results back to the mobile inbox in real time. Scan Profiles The active-scan banner appears at the top of the Scans tab while a scan is running, with a live progress indicator. Tap to cancel. Triggering a scan is a sensitive action: on production builds it is gated by a biometric prompt (fingerprint / face) before the request is sent. Scan History The lower part of the Scans tab lists past scans with their profile, duration, file count, and finding totals. Tap a past scan to open its summary. #### Multiple Desktops One phone can be paired with any number of Korthex Desktops under the same license. This is useful when you run Korthex on a work machine, a personal laptop, and a build server. Switching Active Desktop The top app bar shows the currently active desktop's name and platform. Tap the Switch button (or the row in Settings → Active Instance ) to open a bottom sheet listing all paired desktops with their online state. Pick one to make it the active focus of the dashboard, inbox, and findings tabs. Pairing Additional Desktops From Settings → Pair New Desktop , the camera scanner opens and the standard QR + SAS flow runs again - no re-login required. Re-pairing the same physical desktop replaces the existing pair record rather than stacking duplicates. When all desktop pairs are revoked, the mobile app returns to the login screen. Your account email stays remembered; only the 4-digit PIN is asked again. ### Notifications & Panic Alerts | Channel | Used For | Importance | | --- | --- | --- | | Panic | Server-broadcast emergencies. Bypasses Do-Not-Disturb. Plays an alarm sound. | High | | Findings · Critical | Critical-severity findings discovered during a scan. | High | | Findings · High | High-severity findings rolled up at end of scan. | Default | | Scans | Scan running / completed / failed status. Silent. | Low | | System | Connection drops, certificate expirations, pairing requests, session events. | Default | | Connection (background) | Persistent collapsed indicator while the background service runs. | Minimum | #### Notifications & Panic Alerts Korthex Remote uses six dedicated Android notification channels so you can tune the experience per category (sound, vibration, badge, Do-Not-Disturb behavior) from your system notification settings. Panic Alerts Panic events take over the screen immediately, even on a locked device: Lock-screen takeover - the alert wakes the screen and paints over the lock screen. Survives Silent / DND - the alarm sound plays through the alarm stream, which Android exempts from per-app mute and Do-Not-Disturb. Force vibration - paired waveform pattern alongside the audio. Hold-to-Confirm - acknowledgement requires a deliberate 1.6-second hold to prevent accidental dismissal. A conic progress ring around the button shows progress; releasing early cancels. Reduce-motion fallback - when system animations are disabled, a standard confirm dialog appears instead. #### Security Model Korthex Remote is engineered around a simple principle: the relay server should be unable to read or impersonate either side, even if it is fully compromised. End-to-End Encryption Every payload exchanged between desktop and phone is encrypted with a session key derived during pairing through an ECDH key exchange. The relay only sees opaque signed envelopes - it can route them but cannot read or alter them. Pairing Verification (SAS) The 6-digit code shown during step 3 of pairing is derived from the shared cryptographic material. A man-in-the-middle would force the codes on both screens to differ - which is why visual confirmation by the human user is the final and indispensable step. Long-Term Identities After successful pairing, both sides hold long-lived signing identities used to reconnect silently in the future without re-scanning a QR code. On Android these identities live in Android Keystore (hardware-backed where available) via encrypted shared preferences. On desktop they are stored in the OS secure store (DPAPI on Windows, Keychain on macOS, libsecret on Linux). Revocation You can revoke a paired phone at any moment from Settings → Pairing → Linked Devices on the desktop. Once revoked, the phone loses all access immediately and silently - even if it is offline at the time of revocation, the next reconnect attempt is rejected. Revocations are server-side authoritative and cannot be circumvented by a stolen phone. License Binding A pairing is bound to a specific Korthex license. If the license is reassigned or deactivated, all phones paired under it lose access on the next reconnect attempt and fall back to the login screen. In short: the relay sees only metadata it needs for routing. Your source code, your findings, and your scan output never travel through any server outside of your own Korthex Desktop instance. ### Settings | Section | Controls | | --- | --- | | Account | Profile information, license status, sign out. | | Active Instance | Switch which paired desktop the dashboard is currently focused on. | | Pair New Desktop | Opens the camera scanner to add another desktop to your account. | | Manage Connection | Connection status, transport details, latency diagnostic, danger-zone actions (disconnect, force reconnect). | | Onboarding | Replay the welcome tour. | | Theme | Light / Dark / System default. | | About | App version, build info, open-source licenses. | #### Settings The Settings tab gives you direct access to account, connection, notification, and pairing controls. Connection Diagnostics Manage Connection provides a built-in connection test that measures round-trip latency, identifies the active transport (WebSocket, Server-Sent Events, or long-polling fallback), and reports the reason for the most recent offline state. Useful when debugging captive Wi-Fi portals, corporate proxies, or VPN interference. ### Mesh-Relay (INTEGRATIONS) URL: https://korthex.io/docs/mesh-relay Mesh-Relay is the optional outbound channel that lets multiple Korthex installations coordinate through a central server when peer-to-peer mesh networking isn't an option (restricted networks, hub-and-spoke deployments, NAT-locked environments). Mesh-Relay is an Enterprise-tier feature and is disabled by default. Activating it requires explicit configuration plus a valid relay-server URL and bearer token issued by your Korthex administrator. #### What It Does Each Korthex installation that opts in becomes a node . Nodes report scan events, finding observations, and migration progress to the relay server. The relay forwards them to other authorized nodes belonging to the same organization - useful for fleet visibility, cross-team coordination, and pushing scan triggers to remote build agents. Event forwarding - scan started / finding observed / scan complete events propagate to peers. Fleet visibility - a single Korthex Dashboard can show the status of all paired nodes. Cross-installation diffs - compare scans run on developer machines vs. the CI pipeline vs. a security scan box. ### Security Model | Control | Behavior | | --- | --- | | TLS pinning | Required. Connection fails closed if no SPKI pin file is provided. | | Per-event signing | Each event is signed with a per-installation key. Replay window enforced; replays are dropped and counted. | | Auth | Bearer token issued per node. Rotated on the relay-admin side without redeploying clients. | | No code or findings on the wire | Only structured metadata events. No source code, no scan-finding payloads. | | Local audit stream | Every send/receive logged locally; failures (signature reject, replay reject) surfaced as metrics. | #### Security Model Mesh-Relay is engineered fail-closed: missing or invalid configuration means the relay client refuses to start. The relay server can route events between nodes but cannot read the contents - payloads are signed per-event and any tampering invalidates them. ### Files & Configuration | File | Purpose | User-editable | | --- | --- | --- | | node_identity.json | Per-installation node ID + signing key seed. Generated on first activation. | No | | relay_config.json | Relay server URL, bearer token, SPKI pin reference, queue limits. | Yes (with care) | #### Files & Configuration Two small JSON files live under %APPDATA%/korthex/mesh/ (Windows) or ~/.korthex/mesh/ (macOS / Linux): The relay_config.json file is plain JSON and can be hand-edited for quick configuration changes. Restart Korthex after any edit. The node identity file must not be edited or copied to another machine - it would break the cryptographic association between this installation and the relay. ### License Management (DEPLOYMENT) URL: https://korthex.io/docs/license-management Every Korthex installation needs a license to unlock the features beyond the Free tier. This section covers license format, activation flows (online and air-gapped), seat management, and how the license interacts with each subsystem. #### License Key Format A Korthex license key is a single string in the format: KX-XXXX-XXXX-XXXX-XXXX The KX- prefix is fixed. The four 4-character groups encode a license ID, tier indicator, validity window, and integrity check. The key is bound to your organization but not (by itself) to a specific machine - activation creates the machine binding. You will receive the key by email after purchase. Never publish license keys publicly; treat them as you would any credential. #### Online Activation The default activation path uses the licensing server. From the CLI: # Activate this installation korthex license activate KX-XXXX-XXXX-XXXX-XXXX # Verify the active license + tier korthex license status # Deactivate (frees the seat for another machine) korthex license deactivate From the Desktop UI, the same flow runs under Settings → License → Activate . Activation contacts the licensing server once, records a machine binding, and caches an offline grace token good for up to 30 days of disconnected operation. #### Offline / Air-Gapped Activation For air-gapped environments, Korthex supports a challenge / response activation flow that needs no inbound or outbound network on the target machine. # 1. On the target machine, generate an activation request korthex license challenge --output request.kxc.json # 2. Transfer request.kxc.json to a machine with internet # (USB stick, secure file transfer, ...) # 3. On the connected machine, exchange the challenge for a token korthex license redeem KX-XXXX-XXXX-XXXX-XXXX --request request.kxc.json --output token.kxc.json # 4. Transfer token.kxc.json back to the target machine # 5. Apply the token korthex license install token.kxc.json The challenge file contains an obfuscated machine fingerprint and a one-time nonce. The redeemed token is bound to that machine and that nonce - it cannot be replayed against another installation. #### Seats & Transfers Each license carries a seat count. A seat is consumed on activation and released on explicit deactivation. Self-service deactivation: korthex license deactivate on the source machine releases the seat instantly. Lost machine: contact support with the license ID and the date of loss. A seat can be administratively reclaimed after a verification window. Replacement machine: activate the new machine; if seats are exhausted, an existing seat must be deactivated first. Floating seats (Enterprise): seats check out and check in dynamically; idle for 24 hours and the seat returns to the pool. ### License Environment Variables | Variable | Purpose | | --- | --- | | KORTHEX_LICENSE | License key. Set in environment for headless CI activation. | | KORTHEX_LICENSE_FILE | Path to a license-token file (post-activation) for fully offline runs. | | KORTHEX_LICENSE_SERVER | Override the licensing server URL (Enterprise self-hosted licensing only). | | KORTHEX_TIER_OVERRIDE | Force-restrict to a lower tier for testing (cannot expand above the licensed tier). | #### License Environment Variables Setting KORTHEX_LICENSE in environment skips the interactive activation prompt and is the recommended path for headless CI builds. Combine with KORTHEX_LICENSE_FILE for fully offline CI. ### What Each Tier Unlocks | Capability | Free | Community | Business | Enterprise | | --- | --- | --- | --- | --- | | Scanner engines (AST + Config) | Yes | Yes | Yes | Yes | | Scanner engines (Binary, Runtime, TLS, Git) | no | no | Yes | Yes | | Context Engine | no | no | Yes | Yes | | Inventory Engine + CycloneDX / SPDX export | no | Limited | Yes | Yes | | Impact Engine + audience reports | no | no | Yes | Yes | | Policy Engine (evaluate + enforce) | View only | View only | Evaluate | Evaluate + Enforce | | Planner Engine (generate plans) | no | no | Yes | Yes | | Auto Migration execution (V2) | no | no | Yes | Yes | | Exploit Engine | no | no | Yes (gated) | Yes (gated) | | Dashboard (web UI) | no | Yes | Yes | Yes + SSO | | Korthex Remote (mobile companion) | Yes | Yes | Yes | Yes | | Mesh-Relay | no | no | no | Yes | | Air-gapped operation | no | no | no | Yes | | Custom rule packs | no | no | no | Yes | #### What Each Tier Unlocks The pricing table summarizes capability differences; this is a more granular view for license management: ### Air-Gapped & Self-Hosted (DEPLOYMENT) URL: https://korthex.io/docs/air-gapped Korthex is offline-first by design - every scan engine runs entirely locally and your source code never leaves the machine. For environments where even network presence is restricted (classified networks, regulated industries, isolated build farms), Korthex supports a fully air-gapped installation profile and a self-hosted Dashboard. Air-gapped operation and the self-hosted Dashboard are Enterprise-tier features . The same binary distribution is used; the difference is in how it is licensed, configured, and updated. ### Air-Gapped Installation | Platform | Native installer | Archive | | --- | --- | --- | | Windows | .msi | .zip / .tar.gz + .tar.gz.sig | | Linux | .deb | .zip / .tar.gz + .tar.gz.sig | | macOS | .pkg | .zip / .tar.gz + .tar.gz.sig | #### Air-Gapped Installation Air-gapped installation packages bundle every dependency the engine needs at runtime - there is no installer phase that reaches out to the internet. Activation happens through a file-based exchange with the Customer Dashboard on a second, networked device. 1. Install Korthex Choose the native installer for your platform, or use the generic archive if you prefer manual deployment. No korthex-verify tool ships today. The native installers verify the release themselves - detached Ed25519 signature, then SHA-256, fail-closed - so on an air-gapped host prefer the native installer. If you deploy the archive manually, verify its detached signature with your own tooling before extracting; there is no Korthex-supplied command for it yet. 2. Run Preflight Run korthex-preflight.exe on the airgapped machine to generate the safety status file korthex-posture.json . From here, switch to a second device with network access and the Customer Dashboard open to complete activation. 3–6. Exchange license files Upload korthex-posture.json to the Customer Dashboard In the airgapped Korthex UI, export the installation request → produces .krxreq Upload the .krxreq file to the Customer Dashboard Download the generated .krxlic file from the Customer Dashboard 7. Activate Transfer .krxlic back to the airgapped machine and import it - drag & drop into the Korthex UI, or select the file manually. Done. Korthex is now licensed and ready to run fully offline. The bundled artifacts include the runtime (JVM 21), all scan engines, the baseline registry, the CVE / KEV / EPSS cache, and the on-device Neural Network model weights. No download is performed at scan time. ### Custom Rules & Extensibility (DEPLOYMENT) URL: https://korthex.io/docs/custom-rules Korthex ships with thousands of rules out of the box, but every organization has legacy patterns, in-house wrappers, and specific algorithms it wants to flag or whitelist. This section describes the extension surfaces available today and the plugin architecture coming with V2. ### What You Can Customize Today (V1) | Surface | Edits via | Use case | | --- | --- | --- | | Detection toggles | korthex config set detection. | Turn entire detector classes on / off. | | Path ignores | .korthexignore (gitignore syntax) | Exclude vendored code, generated files, test fixtures. | | Policy file | .kxp / .korthex_policy.json | Override severity, whitelist algorithms, add deprecation deadlines, define exemptions. | | Algorithm aliases | policy file algorithm-aliases section | Tell Korthex that your internal MyEncrypt() wrapper maps to AES-256-GCM. | | Severity overrides | policy file overrides section | Promote / demote specific findings by rule ID or by file path. | | Exemptions | policy file exemptions section | Time-bounded waivers for known-and-accepted findings. | #### What You Can Customize Today (V1) V1 ships three extension surfaces that cover the most common needs: These surfaces together cover ~80% of customization requests we see in practice. Anything beyond them is the domain of the V2 custom-rule format. #### Algorithm Aliases The single most common customization: making Korthex understand your in-house crypto wrappers. Without this, your custom secureHash() reads as an unknown function and is conservatively flagged. { "version": 2, "algorithm-aliases": [ { "wrapper": "com.acme.crypto.SecureHash.compute", "wrapped": "SHA-256", "language": "java" }, { "wrapper": "acme_encrypt", "wrapped": "AES-256-GCM", "language": "go" }, { "wrapper-regex": "^acme_legacy_hash_v\\d+$", "wrapped": "MD5", "language": "c" } ] } The Scanner now classifies calls to SecureHash.compute exactly as it would classify a direct MessageDigest.getInstance("SHA-256") call - same severity, same baseline lookup, same compliance mapping. #### Custom Rule Packs (V2) V2 introduces a first-class custom rule pack format. A rule pack is a signed, versioned bundle of detection rules that Korthex loads alongside the built-in registry. Same rule shape as built-ins. Algorithm name, baseline status, min-key-bits, replacement, CWE mappings. Pattern-based detectors. Match by import path, function signature, regex over arguments, or via the AST query language used by the built-in detectors. Per-language scoping. A rule pack can apply only to Java code, only to TypeScript, etc. Signed distribution. Rule packs are signed; unsigned packs can be sideloaded with an explicit override flag. Status - planned for Korthex V2. The V1 extension surfaces above will continue to work in V2 unchanged. Rule packs add capability rather than replacing existing extension points. #### Third-Party Library Coverage When Korthex scans an unfamiliar library, the Context Engine and (when enabled) the Neural Network Engine cooperate to classify call sites as crypto / not-crypto and to guess at the underlying algorithm. The guess is conservative by default - if confidence is low, the finding is emitted at a low severity with a "unknown wrapper" note rather than dropped silently. To improve coverage of a specific library, the recommended path is to publish a policy-file algorithm-aliases mapping (above) - this is far simpler than writing a custom rule, propagates to all callers consistently, and is forward- compatible with the V2 rule-pack format. ### PQC Migration Playbook (DEPLOYMENT) URL: https://korthex.io/docs/pqc-playbook Quantum computers powerful enough to break today's public-key cryptography do not exist yet - but the data we encrypt today will still be sensitive when they arrive. Korthex was built to make the transition to post-quantum cryptography (PQC) a tractable, auditable engineering project rather than a panic. This section explains the landscape and walks through concrete migration recipes. ### Why Migrate Now | Quantum-vulnerable | PQC replacement | Standard | | --- | --- | --- | | RSA-OAEP encryption / key exchange | ML-KEM (Kyber) | FIPS 203 | | RSA-PSS / RSA-PKCS#1 signatures | ML-DSA (Dilithium) | FIPS 204 | | ECDSA signatures | ML-DSA (Dilithium) | FIPS 204 | | ECDH key exchange | ML-KEM (Kyber) | FIPS 203 | | Hash-based signatures (long-lived) | SLH-DSA (SPHINCS+) | FIPS 205 | | Symmetric crypto (AES-256, ChaCha20) | No change needed | Already quantum-resistant | | Cryptographic hashes (SHA-256, SHA-3) | No change needed | Already quantum-resistant | #### Why Migrate Now The dominant motivation is the Harvest Now, Decrypt Later threat model. Adversaries with resources can capture encrypted traffic today, store it indefinitely, and decrypt it once a sufficiently capable quantum computer is available. Anything you encrypt with RSA, classical ECDH, or ECDSA today is at risk if it is intercepted and your data needs to remain confidential past roughly 2030 - 2035. The migration target is the NIST-standardized PQC suite published in 2024 - 2025: ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+). These are significantly larger than their classical counterparts in key and signature size, which means migration is not a drop-in replacement - protocols, on- the-wire formats, and storage all need attention. ### The Migration Window | Authority | Deadline | What it applies to | | --- | --- | --- | | NIST SP 800-131A | 2030 | RSA, DH, ECC for new systems; existing systems by 2035. | | BSI TR-02102-1 | 2030 | Quantum-vulnerable asymmetric crypto in classified systems. | | NSA CNSA 2.0 | 2030 / 2033 | Software / firmware vendor compliance for national-security systems. | | CNSA 2.0 (web browsers, OS) | 2025 / 2027 | Browsers and operating systems must support PQC. | #### The Migration Window Major standards bodies have published end-of-life targets for quantum-vulnerable algorithms. Korthex's Baseline Registry tracks all of these and surfaces the applicable deadline in every finding. "2030" sounds far away but isn't. A real-world migration of an established product touches build systems, key-management infrastructure, on- disk formats, network protocols, third-party integrations, and the test suite. Teams that started in 2024 routinely report 18 - 30 month migration timelines for non-trivial systems. #### Hybrid Cryptography During the transition, most teams adopt a hybrid approach: the new PQC primitive is combined with a classical primitive (e.g. ML-KEM + X25519) so the system is secure as long as at least one of the two remains unbroken. This protects against both the quantum threat (classical primitive breaks) and any unforeseen weakness in the new PQC primitive (classical primitive holds the line). Korthex recognizes the standardized hybrid constructions (e.g. Kyber + X25519 for TLS, Dilithium + Ed25519 for signatures) and treats them as fully PQC-ready. A finding tagged "hybrid" is not raised as a PQC-migration item. #### Recipe: RSA Encryption / KEM → ML-KEM The most common migration. Wherever you use RSA-OAEP to encrypt a session key or to wrap a symmetric secret, you can swap in ML-KEM. This applies to TLS session establishment, JWE-style payload encryption, and most "encrypt with public key, decrypt with private key" workflows. Steps Scan and locate. korthex scan . flags every RSA-OAEP call site. Inventory. Open the Inventory screen in the Dashboard and search the Census view for RSA . You get every RSA variant in use with its occurrence count, NIST status and PQC flag; the Files view maps each variant to the files it lives in. Plan. korthex plan create produces a sequenced migration plan; korthex impact cost adds the engineer-hour estimate. Replace key-pair generation. Generate ML-KEM key pairs alongside the existing RSA pair. The two coexist during the migration. Update the wire format. Add a versioning field if your protocol doesn't have one. New deployments speak hybrid (RSA + ML-KEM); old deployments speak RSA only. Migrate consumers. Update consuming services one at a time to read the hybrid format. Sunset RSA. Once all consumers handle hybrid, generate new keys as ML-KEM only and rotate. Use korthex dataflow query --from "key-gen:RSA" --to "encrypt" to map every consumer that depends on a particular RSA key before you start. #### Recipe: ECDSA / RSA Signatures → ML-DSA Signature migration is generally easier than encryption migration because signatures are verifier-side: as long as the verifier supports the new scheme, new signers can adopt it without breaking old verifiers (provided you don't remove the old scheme until all verifiers are updated). Identify all signers and verifiers. Filter the Census view to the Signature family and note every ECDSA and RSA entry, then use the Files view to resolve each to its call sites. The inventory records the algorithm, not the intent - it does not separate signing from encryption use of the same key type, so confirm the direction in the Dataflow graph before you migrate a call site. Upgrade verifiers first. Roll out ML-DSA verification support across all consuming services. Until this is complete, no signer can switch. Switch new signing operations to hybrid. A hybrid signature pair (Ed25519 + ML-DSA) is the lowest-risk path. Re-sign long-lived artifacts. If you sign documents or release artifacts that need to remain verifiable for years, re-sign them under ML-DSA before retiring the legacy chain. Decommission the legacy scheme only after all verifiers and all in-flight signed artifacts have been transitioned. #### Recipe: Long-Lived Signatures → SLH-DSA For signatures whose validity needs to extend many decades (firmware, root certificates, archival), SLH-DSA (SPHINCS+) is the most conservative choice. It is a hash-based scheme that relies only on the security of its underlying hash function - no novel mathematical assumptions. Significantly larger signatures than ML-DSA (KB-scale, not bytes). Slower signing operations - not suited to high-throughput paths. Excellent fit for boot-chain signatures, archive signatures, or any document that needs to be verifiable far into the future. Korthex flags long-lived signature use sites in the Planner output with a "long-lived" tag, recommending SLH-DSA over ML-DSA for those specific items. ### How Korthex Helps End-to-End | Phase | Korthex tool | What you get | | --- | --- | --- | | Discover | Scanner + Database Scanning | Complete map of every quantum-vulnerable primitive in your stack. | | Understand | Dataflow + Inventory | Graph of which services depend on which keys; CycloneDX / SPDX exports for stakeholders. | | Prioritize | Impact Engine | Business-weighted prioritization. CISO / CTO / CFO / BOARD audience reports for steering. | | Govern | Policy Engine | Set a hard "no new RSA" rule. PRs introducing quantum-vulnerable crypto fail the CI gate from day one. | | Plan | Planner | Sequenced, deadline-aware, dependency-ordered migration plan with engineer-hour estimates and PDF export. | | Execute (V1) | korthex migrate --dry-run | Preview every code change before any file is touched. Note the shape: the preview is a flag on migrate, not a subcommand - and korthex simulate is a different tool entirely, for modelling a single algorithm. | | Execute (V2) | Auto Migration | Context-aware automatic rewrites; diff-review workflow; built-in rollback. | | Verify | Accuracy Engine | Measure before/after to confirm findings closed without regressions. | ### Compliance (TRUST & COMPLIANCE) URL: https://korthex.io/docs/compliance Korthex automatically maps findings to recognized compliance frameworks, helping organizations demonstrate adherence to cryptographic security standards. ### NIST FIPS 203/204/205 | Standard | Algorithm | Korthex Check | | --- | --- | --- | | FIPS 203 | ML-KEM (Kyber) | Identifies key encapsulation mechanisms that need PQC upgrade. | | FIPS 204 | ML-DSA (Dilithium) | Flags digital signature schemes vulnerable to quantum attack. | | FIPS 205 | SLH-DSA (SPHINCS+) | Detects hash-based signature opportunities. | #### NIST FIPS 203/204/205 FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) define the first NIST-standardized post-quantum cryptographic algorithms. Korthex evaluates your codebase against these standards: Each finding includes a compliance.nist field indicating which FIPS standards apply and the current compliance status. ### BSI IT-Grundschutz | BSI Module | Description | | --- | --- | | CON.1 | Crypto concept - algorithm selection and key management. | | APP.3.6 | DNS security and DNSSEC cryptographic configuration. | | NET.3.3 | VPN - IPsec and TLS tunnel cryptographic requirements. | | OPS.1.2.4 | Patch and change management for crypto libraries. | #### BSI IT-Grundschutz For organizations operating under German/EU regulatory requirements, Korthex maps findings to BSI IT-Grundschutz controls: Findings include a compliance.bsi field with the relevant Grundschutz module references and requirement IDs. ### Severity Model | Severity | Description | Examples | | --- | --- | --- | | CRITICAL | Immediate security risk. Exploitable without quantum computers. | Hardcoded private keys, MD5 for passwords, DES in production | | HIGH | Significant weakness. Vulnerable to near-term attacks or quantum. | RSA-2048 for long-term secrets, SHA-1 certificates, ECB mode | | MEDIUM | Suboptimal cryptography that should be upgraded. | AES-128 (vs 256), PKCS#1 v1.5 padding, 2048-bit DH | | LOW | Minor improvement opportunity. | Non-PQC algorithms in non-sensitive contexts | | INFO | Informational finding for inventory purposes. | Detected crypto usage with no identified weakness | #### Severity Model Korthex uses a five-level severity model: Severity levels are automatically adjusted by the Context Engine. Taint analysis may promote or demote findings based on evidence about key sources and code context. ### Privacy & Telemetry (TRUST & COMPLIANCE) URL: https://korthex.io/docs/privacy-telemetry Korthex is offline-first by design. Your source code never leaves the machine. All outputs are encrypted at rest with authenticated cryptography. Telemetry is opt-in only and disabled by default. ### Data Handling | Data | Stored? | Encrypted? | Leaves Machine? | | --- | --- | --- | --- | | Source code | Never | no | Never | | Finding metadata | Yes | Yes (.kxr) | Only via mesh (user-initiated) | | Code snippets (1-2 lines per finding) | Yes | Yes (.kxr) | Never | | Master encryption key | Yes | OS-protected (DPAPI/Keychain) | Never | | Scan configuration | Yes | No (JSON) | Never | | Telemetry events | Temporarily queued | No | Only if opt-in enabled | #### Data Handling Korthex supports fully air-gapped deployment (Enterprise tier). Every feature works without any internet connectivity. ### Telemetry (Opt-In) | Collected (bucketed / categorical) | Never Collected | | --- | --- | | Scan duration and project size (file count) | Source code or file contents | | Language distribution | File names or directory paths | | Detection-rule categories triggered per scan (anonymous counts) | Exact algorithm strings from your code | | Per-engine timing and throughput (coarse buckets) | Exact millisecond, MB, or CPU values | | Trial funnel: started / expired / converted (days-to-conversion bucket) | Scan findings or vulnerability details | | Feature usage (screens visited, CLI commands) | IP addresses | | Error codes (module + exception-type bucket) | Email, license keys, or PII | | Session ID (random UUID); install token (weekly-rotating) | Stack traces or exception messages | #### Telemetry (Opt-In) When you explicitly enable telemetry, Korthex collects anonymous, bucketed usage data to improve the product. The consent dialog appears on first launch. You can change your preference anytime in Settings > General > Analytics. Consent has three levels: full analytics, stability-only (crashes, unhandled errors, failed license checks and UI-freeze events only), and off. Every event type carries an internal purpose and classification tag so purpose limitation stays auditable. Data retention: raw events 90 days (then hard-dropped by partition), daily aggregates 36 months, anonymised monthly aggregates unlimited. CLI users can disable telemetry per-scan with --no-telemetry . Set the environment variable KORTHEX_NO_TELEMETRY=1 to disable globally. ### Screen Protection | Setting | Options | | --- | --- | | Privacy Mode | Default (hidden on focus loss), Strict (enhanced protection), Disabled | | Stream Exception | Allow one app (Teams / Discord / Slack) to see Korthex during screen sharing | #### Screen Protection Korthex automatically excludes its window from screen captures and screen sharing. This prevents sensitive findings from being visible in recordings, screenshots, or screen-share sessions (Teams, Discord, Slack, Zoom, OBS, and 40+ other tools). ### Pricing (TRUST & COMPLIANCE) URL: https://korthex.io/docs/pricing All plans include the full 18-language scanner. The Free tier is ideal for evaluating Korthex on a single project. Community adds CI/CD and dashboard access. Business and Enterprise plans unlock the full engine suite, context-aware analysis, migration planning, and compliance reporting. | | Free | Community | Business | Enterprise | | --- | --- | --- | --- | --- | | Price | Free | from €***/mo | from €***/mo | from €***/mo | | Scans / month | 10 | 50 | 250 | Unlimited | | Files / scan | 1,000 | 5,000 | 10,000 | 100,000 | | Seats | 1 | 1 | 5 | Unlimited | | Languages | 3 | All 18 | All 18 | All 18 | | Scan Engines | Scanner + Config only | Scanner + Config | All engines | All engines | | Context Engine | no | no | Full | Full | | Dashboard | no | Full | Full | Full + SSO | | CI/CD Templates | no | 1,000 runs | 2,500 runs | 10,000 runs | | Migration Planning | no | no | Full | Full | | Compliance Report | no | no | Full | Full | | Policy Engine | no | no | no | Full + custom | | Mesh Networking | no | no | no | Full | | Executive Summary | no | no | no | Full | | Output Formats | .krx (native) | .krx + CycloneDX + SARIF | .krx + CycloneDX + SPDX + SARIF + JUnit | All formats incl. plain JSON / PDF / custom | | Support | Community | Email | Email + Chat | Dedicated + SLA | | Self-hosted | no | no | no | Available | ### SDKs Overview (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdks-overview Korthex and Flowence Infrastructure publish three software development kits. They give developers programmatic access to the same engines that power the CLI, Dashboard, and Mobile companion, so you can embed Korthex into your own tools, pipelines, and platforms. This page is the landing point; each SDK has its own dedicated section in the navigation tree. ### SDK Family at a Glance | SDK | Purpose | Status | | --- | --- | --- | | Korthex SDK | Programmatic access to Scanner, Context, Inventory, Policy, Planner, Dataflow, Runtime Agent, and Exploit engines. | In active development | | Flowence Cryptography SDK | Modern cryptographic primitives (AEAD, KEX, hashing, KDF, post-quantum) with safe-by-default APIs. | Planned | | Flowence JSON++ SDK | Linkable library for SQL-like queries over plain or encrypted JSON, plus a bit-mapped compressed .cjsn format. | Planned | #### Roadmap & Cadence The Korthex SDK is the first kit reaching documentation depth; the Flowence SDKs are next in line. Public-preview releases will be announced through the Korthex changelog and your account portal. Until each SDK reaches preview, treat the documented surfaces as intended rather than guaranteed. The Korthex SDK section below has its own nested navigation - expand Korthex SDK in the sidebar to drill into installation, modules, examples, and the API reference. ### Korthex SDK (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex The Korthex SDK gives you a typed, idiomatic client to every Korthex engine. Build your own CI runners, security dashboards, programmatic scan triggers, and internal developer platforms on top of the same surface the Korthex CLI and Dashboard consume. Status: In active development. The surfaces documented here are the planned shape; specific methods, types, and release timelines will land piecewise as each module reaches preview. Subscribe to the changelog for breaking notices. #### What the SDK Solves Embed scanning into a custom CI workflow without shelling out to the binary. Trigger remote scans from your developer portal and react to results in real time. Stream findings into your own data lake, GRC platform, or SIEM. Render custom dashboards with first-class typed data from any engine. Automate migration plans generate, preview, and (V2) execute migrations from your own tooling. ### Supported Languages | Language | Package | Status | | --- | --- | --- | | TypeScript / Node.js | @korthex/sdk | Reference implementation | | Python | korthex-sdk (pip) | In development | | Java / Kotlin | com.korthex:korthex-sdk | In development | | .NET (C#) | Korthex.Sdk (NuGet) | Planned | | Go | github.com/korthex/sdk-go | Planned | | Rust | korthex (crates.io) | Planned | #### Supported Languages All language SDKs target the same wire protocol and feature surface. Idioms differ per language (e.g. async/await in TypeScript vs. context-manager in Python), but the conceptual model and naming are identical. #### Where to Start New to the SDK? Walk the nested navigation in this order: Installation → Authentication → Quick Start → pick the Modules branch for whichever engine you need. Returning users typically jump to API Reference or the relevant module page directly. ### Installation (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-installation Install the Korthex SDK in your project using your language's standard package manager. Each install pulls in the typed core client; per-engine modules are included by default in the reference implementation and may live in optional sub-packages in other languages. #### Install the Package Pick your language, your choice is remembered across every code sample on this page. #### Verify the Install version() is unauthenticated and returns immediately a successful response confirms the SDK is correctly wired before you configure credentials. ### Authentication (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-authentication The SDK uses your Korthex license to authenticate, with optional API tokens for granular, scope-limited access. The authentication model mirrors the CLI: same credentials, same tier-gating, same audit trail. #### License-Based Auth The same KORTHEX_LICENSE environment variable used by the CLI is picked up automatically when no license option is passed. For fully offline runs, point KORTHEX_LICENSE_FILE at a license token (see License Management). #### API Tokens For programmatic access from CI/CD, create scoped API tokens in the Dashboard ( Settings → API Tokens ) and pass them at client construction. Tokens carry their own scopes and can be rotated without touching the license. ### Scopes | Scope | Allows | | --- | --- | | scan:read | Read scan reports and inventories | | scan:run | Trigger new scans | | policy:read | Read policy + verdicts | | policy:write | Update policy file | | plan:read | Read migration plans | | plan:execute | (V2) Execute auto-migration | | exploit:run | Invoke Exploit engine (ToS gate required) | | admin:* | Full administrative access (Enterprise) | ### Quick Start (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-quickstart End-to-end in less than thirty lines: install, configure, scan, read the result. The same example is shown in every supported language, pick a tab. #### Where Next Open the Core Concepts branch to understand the client lifecycle, configuration loading order, and error model. Pick a Module page for the engine you want to use (Scanner, Reports, Inventory, ...). Browse Examples & Recipes for ready-to-run patterns (CI/CD gates, custom dashboards, webhook handlers). ### Core Concepts (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts Five concepts run through every SDK module. Understanding them once means every subsequent module feels familiar. Expand the Core Concepts branch in the sidebar for the deep-dive pages. ### The Five Concepts | Concept | Why it matters | | --- | --- | | Client | How instances are created, configured, and torn down. Connection lifecycle. | | Configuration | Where settings come from (env, file, options object) and how they merge. | | Errors & Retries | Typed error hierarchy + retry semantics for transient failures. | | Async Operations | Long-running operations (scans, migrations) use a poll/stream pattern. | | Pagination | Large result sets (findings, inventories) stream via cursor pagination. | ### Client (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts-client The KorthexClient is the entry point. One instance per process is typical; the client manages connection pooling, retries, and credential refresh internally. #### Lifecycle The client is safe to keep open for the lifetime of your process. Call client.close() during graceful shutdown to flush in-flight metrics and release pooled connections. ### Configuration (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts-configuration Configuration is resolved in a deterministic order. You always know which value wins. #### Precedence Explicit constructor options (highest priority) KORTHEX_* environment variables .korthex/config.json in the working directory User config at ~/.korthex/config.json Built-in defaults (lowest priority) ### Errors & Retries (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts-errors Every SDK error inherits from KorthexError . Subclasses encode the category so you can branch on type rather than parsing strings. ### Error Hierarchy | Class | When it's thrown | | --- | --- | | AuthError | License invalid / expired / wrong tier | | RateLimitError | Quota exceeded (carries retry-after metadata) | | ValidationError | Bad request parameters | | NotFoundError | Resource doesn't exist | | GatedError | Feature requires an explicit opt-in (e.g. Exploit ToS) | | TransientError | Network / 5xx / retried automatically; bubbles up after retry budget | | KorthexError | Catch-all base class | ### Async Operations (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts-async Long-running operations (scans, migration plans, exploit analyses) return an operation handle immediately. You can poll, stream, or await completion. ### Pagination (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-concepts-pagination Endpoints that return large result sets (findings, inventory entries, audit events) paginate with an opaque cursor. ### Modules (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-modules The Korthex SDK exposes 9 engines through 162 C functions mirrored 1:1 in every supported binding. Every function listed below is actually exported by korthex.dll - there are no stubs on this page. Switch the language tab on any code block to see the idiomatic call for that binding. Functions that return JSON do so as a heap-allocated UTF-8 string. High-level bindings (Node, Python, Kotlin, C#, Ruby, PHP, Rust, Go) call krx_free_string internally - no manual memory management for the consumer. The C / WASM examples spell the free out explicitly. ### Module Reference | Module | Surface | Functions | Tier | | --- | --- | --- | --- | | Core | Init / shutdown / license / version / errors / memory | 22 | CORE | | Scanner | Crypto-find pipeline + in-memory analyzers + catalog + ShadowEval + export/suppress | 36 | CORE | | Policy | NIST / BSI baseline + user overlay + evaluate / enforce | 17 | Enterprise · COMPLIANCE | | Interface | Ticket-tracker bridge (GitHub / GitLab / Jira / Linear / Azure DevOps / YouTrack) | 19 | Pro+ · MESSAGING | | Impact | Business-impact analysis + auto-discovered context + LearningDb | 21 | Enterprise · NN | | Exploit | Recon / Analyze / Attack / Report pipeline (ToS-gated) | 12 | Enterprise · NN + Feature Gate | | Accuracy | Measure scanner / migration / false-positive / corpus accuracy | 4 | Enterprise · NN | | Benchmark | Algorithm benchmark runner (single / repeat / pair / introspection) | 18 | Enterprise · NN | | CVE | Local CVE / CPE / KEV / EPSS lookup + matching + auto-update | 9 | Pro+ · CVE_DATABASE | ### Scanner (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-modules-scanner The source-of-truth crypto-find pipeline. STATELESS at the DLL level - scannerInit reads (or scaffolds) the SDK config at %APPDATA%/korthex/sdk/scanner.config.json (or $KORTHEX_SCANNER_CONFIG_PATH ) and calls InitializeSDK once per session. ### Policy (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-modules-policy Loads the federated NIST SP 800-131A baseline (99 rules, embedded in the DLL) plus an optional user overlay at %APPDATA%/korthex/sdk/policy.json . Switch live to BSI TR-02102 with policySetStandard("bsi-tr-02102") . ### Exploit (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-modules-exploit Recon → Analyze → Attack → Report pipeline. Two-gate model: the license tier (Enterprise + NN) AND the engine-internal Feature Gate must both be open. The gate is closed by default - call exploitSetFeatureGate(1, "") to accept the offensive-use ToS before any pipeline call will succeed. The Exploit engine produces working proof-of-concept exploits. Only use it in authorised engagements and on systems you own or have explicit consent to test. ### Examples & Recipes (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-examples End-to-end patterns you can copy into your own codebase. Each recipe is small, focused, and uses the production-ready APIs. #### Available Recipes CI/CD Integration : a complete PR-gate script for GitHub Actions, GitLab CI, and Azure DevOps. Custom Dashboards : render findings + trends in your own UI. Webhook Handlers : receive Korthex events and route them to your incident pipeline. ### Recipe: CI/CD Integration (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-examples-ci Block a pull request when scan-introduced findings exceed your policy threshold. ### Recipe: Custom Dashboards (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-examples-dashboards Build a custom finding-explorer or trend dashboard that pulls live data from your Korthex installation. ### Recipe: Webhook Handlers (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-examples-webhooks Receive structured events from Korthex (scan completed, panic alert, license change) and route them into your incident pipeline. ### API Reference (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-api Auto-generated reference for every class, method, and type in the SDK. This page will host (or link out to) the per-version generated docs once the SDK reaches public preview. #### Generated Reference The generated API reference will live here once the SDK reaches public preview. Each module page in the navigation tree already documents the conceptual surface; this section will host the typed-out signatures, parameter tables, and return shapes for every method. ### Advanced Topics (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-advanced Power-user features that aren't part of the everyday surface but matter once you push the SDK into production-scale workflows. #### Streaming Large Result Sets Every list endpoint exposes an async iterator. Memory stays bounded regardless of result-set size; the SDK handles cursor pagination and back-pressure internally. #### Response Caching The SDK ships an opt-in response cache for idempotent reads (reports, inventories, baseline lookups). Configure with new KorthexClient( { cache: { ttl: 300, max: 1000 } } ) . #### Self-Hosted & Air-Gapped Backends Point the SDK at a self-hosted Dashboard or an air-gapped Korthex installation with the endpoint option. Mutual TLS pinning is configurable for air-gapped deployments where the SDK can't reach the public CA chain. #### Telemetry & Observability Plug your own logger or OpenTelemetry tracer with new KorthexClient( { logger, tracer } ) . Off by default; no client-side data leaves your process unless you wire it. ### Changelog (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-korthex-changelog Version history for the Korthex SDK. Backwards-incompatible changes follow semantic-versioning major bumps and are pre-announced in the Korthex changelog at least one minor cycle ahead of the breaking release. #### Pre-Release The SDK is in active development; no stable releases yet. Once preview ships, this section will hold per-version entries with added / changed / deprecated / removed buckets. ### Flowence Cryptography SDK (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-flowence-cryptography A general-purpose cryptography toolkit by Flowence Infrastructure (the company behind Korthex), designed to make modern primitives - authenticated encryption, key agreement, hashing, key derivation, and the new post-quantum standards - easy to use correctly and hard to misuse. The same engineering principles that drive Korthex's detection rules drive the API surface. Status: Planned - early prototyping. No public release date yet. Full documentation will land here once the SDK reaches its first public preview. ### Flowence JSON++ SDK (DEVELOPER TOOLS) URL: https://korthex.io/docs/sdk-flowence-jsonpp Flowence JSON++ is a library shipped as a linkable DLL that lets you work with standard .json files using a SQL-like query syntax, so you can select , filter , and project data directly out of large JSON documents instead of walking the tree by hand. Reads, writes, and queries behave identically whether the underlying file is plaintext or encrypted. JSON++ pairs naturally with the Flowence Cryptography SDK : any .json file can be transparently encrypted and read back in place, queries and serialization stay the same on both sides of the encryption boundary. For very large datasets, JSON++ adds an optional bit-mapped compressed format ( .cjsn ) . Bit-mapped indices let the engine locate records in big JSON datasets dramatically faster and with a smaller on-disk footprint than the original .json . The .cjsn format supports the same plaintext-or-encrypted toggle as ordinary .json . Status: Planned / early prototyping. No public release date yet. ## Development Changelog (pre-release build notes) URL: https://korthex.io/changelog ### 2026-07-29 - New Area inside Korthex - Introduced the Korthex Resource Manager, which intelligently distributes workloads across available CPU, GPU and integrated GPU resources (Vulkan, CUDA and OpenCL), NPU and TPU hardware. - Korthex can now offload suitable compute-intensive processes to the GPU, improving scan throughput and reducing unnecessary CPU load. - Recent open-source performance work improved scan-time efficiency, resource allocation and overall hardware utilization across the analysis pipeline. - Current benchmark: a cold end-to-end scan of approximately 25,000 files and 7,000,000 lines of code completes in around 16 minutes, detecting and requalifying roughly 5,000 findings. - Warm end-to-end scans complete in approximately 3 minutes and produce bit-identical results. Cold scans additionally build the contextual analysis layer, which currently accounts for most of the processing time. - The release target is to reduce cold-start end-to-end scan time to below 8 minutes. - Over the last 9 days, Korthex scanned approximately 3,512,500,000 lines of code and 625,000 commits, branches and deleted blobs, generating around 44,000 findings. - Korthex Mobile is functionally complete at the platform level: communication, handshakes and device pairing are operational. ### 2026-07-10 - Documentation split into per-chapter pages - Every documentation chapter now has its own address under /docs, so CLI, engine, SDK and compliance topics are individually linkable and indexable. - Added a documentation index that groups all chapters, and previous/next navigation between them. - Comparison and compliance pages received an objective, dated legal note explaining why the comparisons are permitted. - Every page now ships its own social preview card, and the full site content is published as one markdown file at /llms-full.txt for AI crawlers. ### 2026-07-08 - Authority and jurisdiction coverage - Compliance grading now spans the recognized authorities (NIST, BSI, ANSSI, CISA, IETF, OWASP) with per-finding framework tags. - Jurisdiction overlays added for EU CRA readiness, EU payments, Germany, France, the United Kingdom, Australia and Canada. - Baseline updates are delivered as signed patches on a 24-hour cycle; the OWASP channel tracks ASVS live. ### 2026-07-05 - Cross-engine correlation and offensive verification - Findings from code, configuration, TLS/PKI, databases and git history merge into a single reachability-scored chain. - Extracted cryptography is graded by emulation against NIST Known-Answer Tests, with a side-channel timing verdict, so weakness is proven rather than pattern-matched. ### 2026-07-01 - CBOM export and migration planning - Cryptographic Bill of Materials export in CycloneDX, SARIF, JSON, PDF and the native .kxr format, each finding carrying a post-quantum readiness bucket. - Topologically-ordered migration plan with per-item file and line, replacement algorithm, effort estimate and dependency order, plus an impact simulation. ### 2026-06-24 - SDK and CI/CD integration surface - Documented SDK covering the scanner, reports, inventory, policy, planner, dataflow, exploit and runtime modules. - GitHub Actions step, GitLab CI template and a generic CLI exit code gate builds above a configurable risk threshold, with SARIF findings inline in pull requests. ### 2026-06-18 - Context engine and language coverage - Two-pass context engine with dataflow tracking, taint analysis and cross-file union-find clustering, following values across import hops. - Coverage across 18 languages spanning TypeScript through COBOL and Zig, plus binary and TLS/PKI analyzers. ## Further Pages - Korthex Beta Program (https://korthex.io/beta): Korthex is in public beta for cryptographic analysis, inventory and migration planning. Current scope, roadmap, and how to take part. - Service Level Agreement (https://korthex.io/sla): The Korthex service level agreement: support tiers, response times and availability commitments for Community, Business and Enterprise plans. - Links of Interest (https://korthex.io/links): Curated resources around Korthex and cryptographic migration: standards, tooling and further reading on post-quantum cryptography, CBOM and compliance. - Terms of Service (https://korthex.io/terms): The terms of service for Korthex, the on-premise cryptography scanner by Flowence. - Privacy Policy (https://korthex.io/privacy): The Korthex privacy policy: what is collected, what is never collected, and how the on-premise scanner keeps source code inside your infrastructure. - Imprint (Impressum) (https://korthex.io/imprint): Legal imprint for Korthex: provider identification, contact address and responsibility under German law. Korthex is a product by Flowence.