Docs / ANALYSIS ENGINES
ANALYSIS ENGINES
Context Engine
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
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
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
| 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" |
| 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. |
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.