Separate finding confidence from security severity
Avoid treating a serious hypothesis as a confirmed defect. Record evidence confidence, technical severity, and business priority separately.
Severity describes the consequences and characteristics of a vulnerability. Confidence describes how well the evidence supports the finding. Keep them separate. A potentially serious issue with incomplete evidence is not a confirmed critical defect, and a clearly demonstrated low-impact issue does not become severe because it is easy to reproduce.
The FIRST CVSS v4 specification defines a method for describing vulnerability severity. It does not replace the application's business context or establish that a proposed finding exists in your system. The review labels below are suggested workflow states, not CVSS categories.
Which labels help a reviewer make decisions?
| Dimension | Example value | Supporting record |
|---|---|---|
| Evidence confidence | Hypothesis | A suspicious code path with unresolved conditions |
| Evidence confidence | Supported | Version-bound evidence supports the stated behavior |
| Evidence confidence | Confirmed in scope | An approved controlled test or qualified review resolves the claim |
| Technical severity | Stated CVSS version and vector | Rationale for each metric |
| Business priority | Fix before launch | Owner's decision based on exposure and consequences |
Do not publish a score without explaining its assumptions. A guessed vector creates false precision. If the affected deployment, privileges, or reachable behavior are unknown, record those gaps.
How do you avoid inflating a hypothesis?
Write the strongest alternative explanation next to the claim. A code path may be protected by a policy check earlier in the request. A dependency may be present but not used in the affected mode. A synthetic response may come from a fixture rather than the deployed service.
Resolve those questions within the authorized review. If they remain open, keep the finding at the appropriate confidence state. Two reviewers repeating the same unsupported assumption do not increase evidence quality.
Avoid a single status such as “high risk” that combines uncertainty, severity, and urgency. The engineering team needs to know whether to investigate, mitigate immediately, or schedule a verified repair.
What should the report show?
State the observation first. Then state the supported impact, severity rationale, remaining uncertainty, and next action. Assign an owner to each missing fact so uncertainty does not become an indefinite parking place.
A later retest can change confidence without changing severity. Conversely, discovering a narrower exposure may change the severity assessment even when the underlying behavior remains confirmed. Keep that history.
Discuss a focused review with Sourced when you need a clear distinction between a scanner alert, a supported finding, and a repair that has been checked.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.