How much we can see. Published openly.

Our detection library carries 10,046 rules across 50 technology definition packs, covering 27 languages and runtimes. They break down as 5,950 misconfiguration checks, 1,402 default-credential and default-configuration checks, 1,385 hardening-baseline checks and 1,232 end-of-life or unsupported-version checks. By severity: 1,974 Critical, 2,026 High, 3,276 Medium, 1,437 Low and 1,333 Informational. Alongside these we run 13,532 active test templates that are refreshed continuously as new techniques are published.

We track 356,454 CVEs with exploit-probability scores, refreshed daily. That is paired with a 226,392-row index mapping specific product versions to the vulnerabilities that affect them, and the CISA Known Exploited Vulnerabilities catalogue at 1,662 entries. The version index is what lets a finding name the exact affected build rather than guessing from a service banner.

Because CVSS measures how bad a vulnerability would be if exploited, not how likely it is that anyone will. A Medium-severity flaw being actively exploited across the internet is a more urgent problem than a Critical that requires physical access and has never been weaponised. We score every CVE with EPSS, which estimates the probability of exploitation in the next 30 days, and we escalate anything on the known-exploited catalogue regardless of its CVSS score. This is what stops a remediation queue from being sorted by the wrong number.

On its own, no — and any vendor implying otherwise is selling you a number. Rule count tells you about breadth of automated coverage, which matters because it means nothing obvious gets missed. It tells you nothing about whether the findings are real. That is why every finding in our reports has been verified by a person before you see it, and why our reports are short. Coverage is the automated half; judgement is the half that makes the report worth reading.

Vulnerability intelligence — exploit-probability scores, the known-exploited catalogue, version-to-CVE mappings and vendor advisories — is refreshed daily. Test templates are updated continuously as new techniques are published. Our own definition packs are versioned individually, each carrying its own version number and review date, so we can tell you exactly how current the rules that produced a given finding were.

Because publishing the internals of a testing engine helps the wrong people more than the right ones. We publish scale openly — how many rules, how many CVEs, which standards we work to, what you receive — because that is what lets you evaluate us. We do not publish payloads, sequencing, evasion behaviour or tooling chains, because that is operational detail whose only practical use is to help somebody avoid detection. Clients receive full detail of exactly what was run against their environment in their report.

No. Every figure on this page describes our engine capability, not any individual engagement or client. What actually runs against your environment is agreed in writing during scoping, and nothing is ever tested outside that agreed scope.