Understanding results

Risk is not coverage

Severity describes a detected risk. Coverage describes what was actually checked. An unfinished scan or a clean public surface does not establish that the whole platform is secure.

Read the evidence

Open a finding to see what was observed, why it matters and the next action. Distinguish live observations from code or configuration evidence. Missing access and checks not run remain limitations, not proof of safety.

Use severity to prioritize, not to infer completeness

Critical, High, Medium and Low describe the impact of identified issues. Completion describes whether the intended work finished. A Medium summary must not be interpreted as evidence that no Critical finding exists elsewhere: use the finding list and its severity filters alongside the summary.

1. Start with the overall completion notice and coverage.
2. Filter confirmed findings by severity and platform.
3. Read the affected resource, evidence and limitation before assigning the issue.

Recognize the different kinds of evidence

A live observation records what a request or browser actually returned in its specific context. A source review points to code or configuration. An unavailable check records a limitation, not a vulnerability. Raw URLs, headers, code and rule identifiers remain unchanged across languages so evidence stays traceable.

Example: a 200 response containing the same HTML application shell on several paths does not by itself prove a public user API. A 401 on a replay is evidence of refusal in that context, not successful unauthorized data access.

Resolve uncertainty without hiding it

If the evidence does not match current behavior, compare the commit, deployment, authentication context and observation time. Use a finding recheck where available. For a disputed finding, include the finding reference and a sanitized explanation in Help; avoid sending credentials or customer records.