What gets detected

Four ways to count, and what each one means#

There is no single number for 'how many kinds of vulnerability'. A check, a rule and a CWE class measure different things, and quoting only the biggest would be flattering rather than useful. All four of these are counted from the code.

• 46 checks — a check is one investigation the scanner performs. 32 standard website, 4 deep website, 10 repository.
• 41 static code rules — patterns matched against source during a repository scan. One check ("Code patterns") runs all of them.
• 18 AI rules — a separate rule set for model and agent code, because the failure modes have no equivalent in ordinary application code.
• 80 distinct CWE classes — the weakness taxonomy a finding can be classified as. This is the closest thing to "types of vulnerability", and it is smaller than the rule count because several rules can find the same class of weakness in different places.

What can affect what#

The three target types do not overlap, and this is the question most people get wrong when they first sign up. A website scan cannot see your dependencies, and a repository scan cannot see your TLS configuration.

• A website scan sees what is served: headers, cookies, TLS, DNS, mail records, the scripts a page loads, the technologies it exposes, and anything reachable without credentials. It cannot see your source, your dependency tree, or your infrastructure code.
• A repository scan sees what is committed: dependencies, secrets (including in history), code patterns, Dockerfiles, Kubernetes manifests, Terraform, and AI usage. It cannot see how the running site is configured, because that is not in the repository.
• The AI inventory is built from a repository scan. Without one, the AI Security page has nothing to show — that is not an error state.
• Cloud posture is separate again: it reads a live account with read-only credentials, and it is the only thing that can tell you about drift between what your repository says and what is actually deployed.

Severity and confidence are independent#

Severity is how bad the problem is if it is real. Confidence is how sure the engine is that it is real. They are separate axes and a finding carries both.

A critical finding with low confidence is worth confirming before you act. A medium finding that is confirmed is worth fixing today. Sorting by severity alone gets this wrong in both directions.

Compliance frameworks#

Findings are mapped onto 5 frameworks. The mapping is by CWE, so a finding reaches a control area because of what kind of weakness it is, not because somebody tagged it by hand.

• OWASP Top 10 (2021) — 10 categories mapped
• NIST SP 800-53 — 12 controls mapped
• CIS Controls v8 — 6 safeguards mapped
• ISO/IEC 27001:2022 — 7 controls mapped
• SOC 2 Trust Services Criteria — 5 criteria mapped

What is refused, and why#

Some classes of vulnerability can only be confirmed by performing the attack. Those are refused rather than half-implemented, and the refusal is published with its reasoning.

• SQL injection, command injection, deserialization and request smuggling — a conclusive payload is one that executes on somebody's database, shell, or a connection shared with their other users.
• Credential stuffing and brute-force testing — it locks real people out, is indistinguishable from an attack in the target's own logs, and success means holding a working credential.
• Rate-limit enforcement testing — proving a limit is enforced means sending the burst that degrades the service.
• Active WAF evasion and cache poisoning — poisoning a shared cache serves the result to other people's users.
• Stored XSS markers and file upload handling — both leave something behind in the customer's system. Held pending legal review rather than refused permanently.