Module coverage reference

What the numbers mean

Koruqan ships 290+ modules spread across five testing layers. Two things are worth separating, because vendors often blur them. First, detection versus proof: more than 90 of the modules are offensive — they do not stop at flagging an issue, they exploit it. Second, the layer a module belongs to (source code, live web, and so on) is independent of whether it is offensive, so an offensive module is a live-web module that also proves, not a separate product.

290+ modules · five layers

Coverage. Roughly 80+ are static source-code modules and 160+ are dynamic web modules; the remainder cover dependencies, server and infrastructure, and secrets.

90+ offensive modules · proof

These do not stop at detection: they attempt the exploit and capture the result as evidence. This is the number to ask any vendor about, because it separates a scanner from a platform that proves. Most sit in the live-web layer.

~50 Kali tools · isolated engine

Execution. Modules orchestrate roughly fifty tools running inside a Docker sidecar, never directly on the host.

Layer 1 — Source code (SAST)

Static analysis runs before anything is deployed, which makes it the cheapest place to catch a class of bug. Koruqan traces data from untrusted input to dangerous sinks rather than pattern-matching on keywords, so a sanitised path does not produce a finding and an obfuscated one still does.

Injection sinks

SQL, command, LDAP, template and deserialisation sinks reachable from request-controlled input.

Weak cryptography

Deprecated hashes, ECB mode, hardcoded IVs, insufficient key length, predictable randomness in security contexts.

Hardcoded secrets

API keys, database passwords and tokens embedded in source rather than injected at runtime.

Unsafe patterns

Language-specific footguns: PHP type juggling, unsafe reflection, path handling that permits traversal, missing output encoding.

Layer 2 — Live web (DAST)

The 160+ dynamic modules test the running application. Coverage spans both the classic OWASP categories and the protocol-level issues that only appear against real infrastructure.

Layer 3 — Dependencies (SCA)

Dependency scanning is easy to do badly: a raw CVE list sorted by CVSS produces hundreds of findings and no priority. Koruqan maps every hit to four feeds so remediation is ordered by what is actually being exploited in the wild rather than by theoretical severity.

CISA KEV

The Known Exploited Vulnerabilities catalogue. A hit here means active exploitation has been observed, which outranks any CVSS score.

EPSS

Exploit Prediction Scoring System — probability that a CVE will be exploited in the next 30 days.

NVD

The National Vulnerability Database, for canonical CVE metadata and CVSS vectors.

GHSA

GitHub Security Advisories, which frequently carry ecosystem-specific detail earlier than NVD.

Layer 4 — Server and infrastructure

This layer tests the host the application runs on, which is where a web-layer foothold usually becomes a full compromise.

Privilege escalation

Linux escalation paths to root: SUID binaries, writable service units, sudo misconfiguration, kernel exposure.

Multi-tenant isolation

Whether one tenant can reach another tenant on a shared host. Relevant to hosting and VDS providers, where an isolation break affects every customer at once.

Service hardening

nginx configuration, TLS parameters and certificate handling, database exposure and authentication, mail configuration, SSH policy.

Layer 5 — Secrets

Secrets leak in places people forget to look. Koruqan searches code, build artifacts and container images for keys, tokens and credentials, then attempts to determine whether a leaked credential is still live rather than reporting every high-entropy string as a finding.

The Kali tooling behind the modules

Roughly 50 tools ship inside an isolated Docker sidecar, so offensive tooling never runs directly on a host you care about. A single flag switches engines. Named tools include nuclei, sqlmap, nikto, ffuf, semgrep, grype and MobSF, alongside around forty more.

Modules orchestrate these tools rather than merely wrapping them: the platform decides which tool to invoke, feeds it the context gathered by earlier layers, and normalises the output into a single findings model so a sqlmap result and a semgrep result can be correlated instead of sitting in separate reports.

Smart module selection

Running all 290+ modules against every target wastes time and generates noise. Koruqan fingerprints the stack — PHP, Node, Java, Go, WordPress — and runs only the modules that can plausibly apply. A WordPress target does not get Java deserialisation probes, and a static site does not get database injection sweeps.

The practical effect is a shorter scan with a higher signal ratio. In the reference scan shown on the home page, 214 module executions across five layers completed in six minutes.