A vulnerability report in the RedRays Security Platform records the findings a scan produced, not the checks it attempted, which means an issue absent from a report has at least four possible causes and the report does not distinguish them.
This page exists because the cheapest mistake in security scanning costs nothing to make: reading an absence as a clean bill. A report with no findings against a service, a severity band reading zero, a green status on a scan: each is a true statement about something narrower than a reader will take it to mean.
Because four different things produce the same blank space.
| Cause | What actually happened | What the report shows |
|---|---|---|
| Genuinely clean | The check ran and the service did not answer the way an affected system answers | Nothing |
| Never asked | No check exists for that service type, so the service was visited and asked nothing | Nothing |
| Skipped | The check needs a stored logon and none was stored against that service | Nothing |
| Never reached | The port refused, the host was unreachable, or the service was not in the inventory to begin with | Nothing, unless the run recorded an error |
Only the first is good news. The other three are silences, and the difference between a silence and a zero is the rule the whole platform is built on: a number nobody measured must never be shown as if it were measured.
Because checks are routed by service type. A scan runs only the checks written for the service families the port scan recorded on that landscape, which is what makes it fast and what makes it incomplete in a specific, knowable way. Two consequences follow.
A service of a type nothing is written against is scanned only in the sense that the scan visited it. And a landscape whose exposure is narrow is asked few questions, so a short report can mean a small attack surface or a small question set, and the report does not say which.
That the job returned. A scan that reached some hosts, failed on others and found at least one thing is stored as finished, because it produced a result, and it is drawn like any other finished scan. Where a run collected failures, the report carries them and the console surfaces them beside the export control, which is the one place that says a finished report was partly blind. Read that control when it appears, because nothing else on the screen mentions it.
As a record of one run, against the services one earlier inventory recorded, at one moment, with whatever credentials were stored at the time. Four things are worth writing down beside every report you intend to rely on later:
It is plausible and it is not self-verifying. Check the inventory date, check which services carried a logon, and check whether the run recorded failures. A clean report on a landscape where nothing was asked is a different document from a clean report on a landscape where everything was.
Not per report. The catalogue is routed by service type, so the set that ran is determined by the inventory, and that is the thing to record when you take a scan.
Pair the report with the inventory it was routed by and the credential state at the time. Those three together are a defensible statement. The report alone is a statement about findings.
No, and the console prints every band including the empty ones for exactly that reason. A band that is absent and a band that is empty have to look different on screen.