The anatomy of a finding

Five questions, a rule id, a location and masked evidence - written deterministically by the rule before any model is asked anything.

Every finding answers the same five questions, in the same order, whatever raised it. The answers are written by the rule itself, which is why a free scan needs no AI to produce a readable report.

What is wrong: The fact, stated plainly, with the file or URL it concerns.
Why it matters: The consequence for this application, not a textbook definition.
How it would be abused: The realistic route an attacker would take. Omitted when there is not one.
How to fix it: The specific change, in the terms of your stack.
How we verify: What has to happen for this finding to resolve - and what we cannot verify for you.

What else a finding carries

The rule id and version, so you can tell exactly which check fired.
A location: a URL, a header, a cookie, a script, a certificate or a repository path.
Evidence, already masked. A credential is identified, never stored in full.
A fingerprint built from semantic identity rather than line numbers, so a refactor does not create a duplicate.

A finding, abbreviated

rule      source.secrets.credential-committed  v3
severity  CRITICAL      confidence 0.95      domain SECURITY
location  src/lib/stripe.ts
evidence  stripe secret key  sk_live_51H8…VqR  (masked)
status    OPEN          fix available: yes

Questions

Who writes the text of a finding?

The rule does, deterministically. AI can add an explanation in your application’s terms afterwards, but only when you ask - and the original five answers never change.

Will you show me the secret you found?

No. It is masked at detection. Enough is kept to identify which key it is and where it lives; the value itself never reaches our database and never reaches a model.

Something here wrong, missing or out of date? Tell us and we will fix the page.