¶ Published Severity Against Recorded Status
Every SAP vulnerability finding in the RedRays Security Platform carries two published ratings that ship with the check catalogue, one from RedRays and one from SAP, and two values this installation records for itself, a status and a severity, and the product refuses to merge them into a single number.
That refusal is the design of the capability, not an omission. A published rating is what an organisation said about a class of issue. A recorded status is what your team decided about one finding, in one place, on one day. They answer different questions, and a single blended score would hide which one a reader is looking at.
¶ Who decides how serious a finding is?
Three parties, and the finding shows all three.
| Value | Who sets it | What it is a statement about | Can it be edited |
|---|---|---|---|
| Severity by RedRays | The check catalogue | The class of issue, everywhere it occurs | No |
| Severity by SAP | The SAP vendor rating carried in the catalogue | The same class, as the vendor rated it | No |
| Severity | Your installation, seeded from the RedRays rating when the finding is written | This finding, on this host and port | Yes |
| Status | Your installation, set by a person | Whether anybody has answered for this finding | Yes |
The two published ratings can disagree with each other, and the product draws them side by side rather than picking a winner. A reader is being shown two opinions and is deliberately not being told which to believe.
¶ What do the four severity bands mean?
They are an order and nothing else. Severity is one of four constants, critical, high, medium and low, and there is no numeric field behind them anywhere in the capability. No CVSS score, no risk figure, no weighting. Findings are sorted worst first, and the ranking used for sorting is the band order rather than the alphabet.
Some catalogue descriptions quote a CVSS figure inside their prose, because the vendor wrote it there. That text is prose. Nothing sorts by it, filters on it or aggregates it, and two findings side by side, one quoting a score and one not, are not two grades of anything.
¶ What do the three statuses mean?
- New means no person has answered this finding. It does not mean unfixed, and it is the only status a scan ever writes.
- Fixed means a person chose that word. Nothing re-ran the check, and no evidence is attached to the choice.
- Accepted means a person decided to carry the risk. The published ratings do not move and the finding's own severity does not move, because accepting a risk is not regrading it.
The honest reading of any status other than new is: somebody with access to this console chose this word, at a time and for a reason the finding does not record. That is a useful thing for a team to record, and it is recorded honestly as long as it is read that way. If the reason matters to an auditor, keep it where reasons live, in the change record or the ticket the export created.
A decision is recorded against one finding in one place, and nothing re-runs the check when it is made.
¶ What changes when you accept a risk?
One value on one finding, and nothing else. The finding stays in its report, keeps its severity, and continues to be counted by the report summary, by the exports and by the comparison view. Dashboard figures across the platform count open findings, so a decision moves a finding out of one population and leaves it inside another. Both counts are right; they answer different questions. When a number is quoted to somebody outside the team, say which population it came from.
A decision is recorded against a finding, not against an issue. The same issue on a second port of the same host is a second finding and still reads new until somebody answers it too, and a later scan writes fresh findings that read new whatever was decided about the previous ones. That is the mechanical consequence set out in repeat scans and comparing reports.
¶ What this does not give you
- No workflow. There is no assignee, no due date and no approval step. The capability records an answer, not a process.
- No re-test. Nothing in the product verifies a fixed finding. Verification is the next scan, and the next scan reports independently.
- No audit trail on the value itself. Plan for the who and the why to live in your ticket system, and use the export for it.
- No mark on an overridden severity. A band you changed and a band the catalogue published look the same in the table.
¶ Related pages
- SAP vulnerability assessment, the capability these values belong to
- What one vulnerability finding says, for the rest of the record
- Repeat scans and comparing reports, for what happens to a decision at the next scan
¶ Frequently asked questions
¶ Why not just show one severity per finding?
Because the three values are not the same kind of statement. Merging a vendor's opinion about a class of issue with a decision your team made about one host would produce a number nobody measured, which is the one thing the platform is built not to do.
¶ If I change a severity, does the catalogue change?
No. The published pair belongs to the check and is read-only. Your value belongs to that one finding.
¶ Does marking a finding fixed remove it from the report?
No. The report is a record of one scan and does not change shape when you triage it. The status is recorded beside the finding, and the report summary counts every status.
¶ Which severity is used by exports and reports?
The one your installation records, because that is your team's current answer. The published pair is shown for context on the finding itself. See vulnerability reports and exports.