Chapter 1
Finding lifecycle
- 01
Record the observed state
Open the finding and keep its deterministic rule identifier, target, scan time, severity, confidence and evidence. These details define what must be checked again.
- 02
Keep the original evidence
Do not replace the first observation with a comment or screenshot of the fix. The original evidence remains the comparison point for the next result.
- 03
Request verification after deployment
Review, test and deploy the scoped change first. Then request verification against the same intended environment, not a local or preview state.
Check before continuing
- Observed
- Verification requested
- Resolved or still observed
Chapter 2
Choose the matching verifier
- 01
Match the evidence kind
Identify whether the finding came from an HTTP response, browser behavior, repository snapshot or another authorized check. Select the verifier for that same evidence kind.
- 02
Keep target and scope stable
Use the same normalized host, environment and authorized scope. If any of them changed, record a new baseline instead of comparing unlike observations.
- 03
Run a fresh observation
Start the matching verifier and wait for a completed, still observed or inconclusive result. Do not reuse cached output as fresh evidence.
Check before continuing
- Match rule and verifier
- Keep target and scope stable
- Preserve previous evidence
Chapter 3
Interpret the result
- 01
Compare the documented threshold
Read the new evidence beside the rule threshold. Resolve only when the observed state satisfies that documented condition.
- 02
Read an inconclusive result
If the verifier lacked access, timed out or could not collect enough evidence, keep the finding open and address the stated reason before trying again.
- 03
Watch for regression
A later scan can observe the condition again. Reopen the finding with the new evidence instead of preserving an outdated resolved state.
Check before continuing
- Resolved is rule specific
- Inconclusive is not passed
- Regression can reopen a finding