Docs / DEPLOYMENT
DEPLOYMENT
Custom Rules & Extensibility
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
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)
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.
| Surface | Edits via | Use case |
|---|---|---|
| Detection toggles | korthex config set detection.<key> | 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. |
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.