Build a queue that reflects the environment

A true positive reports a weakness that is present; a false positive reports one that is absent. A true negative correctly reports no relevant weakness, while a false negative misses a weakness that exists. These labels describe a comparison with reliable validation evidence. A scanner result alone cannot prove its own correctness, particularly when access or test coverage is incomplete.

Validate important findings with configuration, package details, approved retesting, and subject-matter expertise. Preserve the reason for suppressing a false positive so a later analyst can review it. Look for false negatives by comparing independent evidence and known test conditions. A failed authenticated scan is primarily a coverage gap; do not mark its missing findings as true negatives without further support.

CVSS describes technical severity using metrics such as attack vector, complexity, required privileges, user interaction, and confidentiality, integrity, and availability consequences. Store the score, vector, version, and source together. Interpret the stated version: for example, CVSS 3.1 uses Scope, while CVSS 4.0 distinguishes impacts on the vulnerable and subsequent systems. Neither a base score nor a severity label supplies the full business context.

FIRST’s EPSS estimates the likelihood of a published vulnerability being exploited in the wild over the next 30 days. It is not proof that the organisation has been attacked. A probability and a percentile also mean different things: a percentile describes relative ranking. Combine these signals with credible reports of actual exploitation and local telemetry, rather than letting a low prediction override observed attack activity.

Ask who can reach the affected service and what a successful attack would change. Distinguish public exposure, internal access, and effective isolation, including administrative paths and shared credentials. An internal system can still be critical or reachable after an endpoint compromise. Check the evidence for isolation instead of using a network label as a reason to ignore the finding.

Add asset value, data sensitivity, dependencies, recovery difficulty, and the availability of a supported fix. Explain the proposed order in business terms. A moderately severe weakness with observed exploitation on a public identity service may outrank a higher-scored issue on an unused isolated training image. Keep both tracked, and specify what change in exposure or threat evidence would trigger reprioritisation.