¶ What One Vulnerability Finding Says
A vulnerability finding in the RedRays Security Platform is one catalogued SAP issue, recorded at one host, one instance and one port, inside one report, together with the severity band and status this installation holds about it. It is narrower than the sentence "this system is vulnerable", and the difference matters when the findings are counted.
¶ What is on a finding?
Three groups of fact, from three different places.
| Group | Fields | Where it comes from |
|---|---|---|
| Where it was found | Host, instance, port, service type, and the path where the service has one | The scan, at the moment it ran |
| What it means | Title, description, impact, solution, SAP note references, and the two published severity ratings | The check catalogue, read when the finding is displayed |
| What you decided | Status and severity | A person in the console, after the scan |
Only the first group is a measurement of the landscape. The second is what a vendor published about the class of issue and would read the same on an installation that had never scanned anything. The third is a note this installation makes about the finding, and nothing re-checked it. Published severity against recorded status covers the second and third in full.
One finding holds three kinds of statement at once: where the scan found it, what the catalogue publishes about the issue, and what somebody here decided.
¶ Why is the same issue reported twice on one host?
Because the port is part of the finding, and two ports were two connections. A service commonly presents a plain and an encrypted face; they are separate entries with separate configuration, and they can be patched, filtered or firewalled apart. An issue present on one and absent on the other is a real and ordinary state of an SAP system, so the assessment records each port it measured. It measured two, and it reports two.
There are two more ways one issue arrives more than once. A second service family on the same machine yields findings that look like duplicates and are not, because that service was asked a different body of questions. And a single issue can be checked through a family of near-identical requests, one for each configuration slot a system might expose, so a system exposing several slots shows the same title several times, each with its own record.
The practical consequence: a reader who counts distinct titles will always get a smaller number than the report prints, and both numbers are answers to real questions. The report counts places measured. The title count counts problems to work on.
¶ How is a finding identified?
By a number that is unique within the installation, reachable through the report that carries it. A finding is not addressable on its own, because the record of where it was found only means something inside the run that produced it. A link that names a finding the open report does not contain says so in those words rather than falling back to the first row or opening empty.
¶ What does a report hold?
One scan of one landscape, kept as it was taken. Opening it reads what was found; it re-runs nothing, so a report says today what was written into it on the day it was made.
Reports do not merge. A second scan of the same landscape writes a second report with its own findings. Nothing compares the new rows against the old, nothing carries a decision forward, and nothing marks an issue as gone. That is a deliberate property with a real cost, worked through in repeat scans and comparing reports.
Above the findings table, a summary prints the total, a count and percentage per severity band, and a count per status. Every one of those numbers is computed from the rows in the table underneath, so the summary cannot disagree with what it sits on. Every band is printed even when it is empty, because a band that is empty and a band nobody measured have to look different on screen.
The summary is arithmetic over the rows beneath it, so it cannot disagree with them, and an empty band is still printed.
¶ What does a finding not claim?
- It is not a statement about the estate. It is one check's answer, from one port of one host, at the moment that report was taken. It says nothing about the same port an hour later, and nothing at all about a host the scan did not reach.
- It is not deduplicated in any direction. Nothing joins the same issue across two ports, two hosts, two landscapes or two reports.
- It carries no history. A finding is written once, by the scan that found it, and changed afterwards only by a person. Nothing in the capability can say that a finding on this report is the same issue as a finding on the previous one.
- It is not proof of exploitability. The check inferred a state from how the service replied. A service that answers the same way for another reason produces the same finding, and that is the honest limit of a network check that does not exploit anything.
- It is not a claim about reachability. Everything here was reachable from the machine that ran the scan. On a segmented network that is most of the question, and it is not one this capability answers.
- It says nothing about who did or could do anything. No user, role or authorisation object is part of a finding.
¶ What evidence comes with a finding?
The finding names the check that raised it and the location it was raised at, and the console can hand you the request that check sends, so a reviewer can see exactly what question was asked. Where the response that satisfied the check was captured, it accompanies the request. Where it was not, the file says so rather than presenting an empty box as an answer. Checks that run over a database session rather than over HTTP do not produce a request log of this shape.
Under a demonstration or read-only licence the request log is withheld, and the refusal names itself as a licence restriction rather than returning an empty file.
¶ Related pages
- SAP vulnerability assessment, the capability this finding belongs to
- Published severity against recorded status, for who decides how serious it is
- SAP vulnerabilities an assessment finds, for what the checks look for
¶ Frequently asked questions
¶ Can I merge two findings that are the same issue on two ports?
No, and the reason is deliberate. Merging them would assert that a result from one port holds for the other, which is not what was measured. Each is triaged on its own.
¶ Does a finding record who triaged it?
The record holds the status and the severity. Plan for the decision, the reason and the owner to live in your own change or risk process, and use the export to a ticket system when you need that trail. See vulnerability reports and exports.
¶ Does the text of a finding change over time?
The words come from the check catalogue and are read when you open the finding, so a later catalogue update can change the description of an issue you already have a finding for. The location and the decision are yours and do not move.
¶ Is a finding count a count of problems?
No. It is a count of places measured. For a remediation plan, group by issue; for an exposure statement, count the places.