¶ Triage and Recorded Decisions
A verdict in the RedRays SAP Business Technology Platform (BTP) security assessment is a recorded fact about one finding: a decision, a note, the account that made it and the time the server stamped on it, kept through every later scan of the same object.
Triage here is a record, not a screen setting and not a filter. It changes what a reader knows about a finding, and it changes nothing about the finding itself. What follows applies to findings from any of the three services the SAP BTP security assessment connects to.
¶ What verdicts can be recorded on a BTP finding?
Five, and they are kept apart rather than folded into one idea of "handled".
| Verdict | What the row then asserts |
|---|---|
| Open | Nobody has decided about it. This is the absence of a decision, not a fourth kind of decision |
| Confirmed | A person read it and agreed with the analysis. Somebody owns the fix |
| False positive | A person read it and disagreed. The note is what lets the next person judge whether they were right |
| Accepted risk | The defect is real and is being lived with |
| Fixed | A person recorded that it has been dealt with |
An untriaged finding does not show a blank where the decision would be. It says so in words, because a blank field and "nobody has looked at this" are different statements and only one of them is true.
The band the analysis raised and the decision a person recorded are two facts side by side, and no later scan touches the second.
¶ What does saving a verdict actually write?
The decision and the note, and nothing else. Who decided and when are taken from the signed-in account and the server clock, never accepted from the browser, on the plain ground that an audit trail a caller can write is not an audit trail.
Nothing about the write ever leaves for your tenant. Recording a verdict does not fix, hide or remove anything: the row stays in the table, stays in the count of everything ever reported, and stays on the object.
Choosing a verdict only stages it. Nothing is stored until it is saved, and the discard control stays disabled until something has been edited, so a finding cannot be changed by opening it, only by deciding to. A reader without the permission to triage sees both inputs disabled and is told so in words.
The note is addressed to a person, and the form says so where it asks: the next auditor reads this, not the scan log. Clearing the box clears the stored note, which is stated on the form, because a box that quietly kept the old text would leave a note nobody wrote attached to a decision somebody did.
¶ What survives a later scan, and what does not?
When a later run reports the same finding - same cloud service, connection, object, file, defect class and title - ownership of the row splits cleanly in two.
| Refreshed by every re-scan | Never touched by any scan |
|---|---|
| Scan reference, severity band, score, defect title and description, line, evidence, recommendation, last-seen date, and the object display name where the new run carries one | The verdict, the note, who recorded it, when they recorded it, and the first-seen date |
So the confirmation after a save is literally true rather than reassuring: a verdict survives every later scan of that object, and a finding marked as a false positive never returns as open.
The half nothing on screen flags is the other one. The band is refreshed while the verdict is not. A finding somebody marked as fixed, reported again by a later run, comes back with a fresh last-seen date and possibly a higher severity while its verdict still reads as fixed. Nothing marks that combination, so it is something a reviewer has to look for.
¶ What happens to a finding the newest scan did not report?
It is kept, dimmed and marked as not present in the latest scan, with a warning above the table and a banner in the finding itself. It is never deleted.
The reason is that a defect can drop out of a scan either because it was fixed or because the scan never reached the file, and only a person can tell those apart. The comparison is against the newest run of that object whatever its state, so a newest run that failed, was cancelled or is still going marks that object's earlier findings the same way - which is the honest answer, and worth saying out loud rather than showing a stale finding as current.
¶ Two things this capability deliberately does not do
There is no suppression. Nothing is ever withheld from the findings list on the strength of a recorded decision. A decided finding leaves the count of open findings and stays in the count of everything ever reported, which is why those two numbers differ and why each control states its own scope. A short findings list therefore has exactly two possible causes - little was wrong, or little was read - and coverage and what was not assessed is where the difference is kept.
An acceptance has no expiry, and nothing revisits it. "Until the public release" is a sentence in a free-text box. There is no date field beside it, and there is no scheduler in this capability, so no later scan will come back to an acceptance, or to the open finding beside it, unless a person asks for a run. The note is addressed to the next auditor, and it is the next auditor who has to notice.
¶ Limits
- A verdict cannot change a severity. There is no control anywhere that lets a decision lower a band. A severity a triage decision can move is a severity that stops meaning anything by the third quarter.
- Nothing cross-checks one note against another finding. An acceptance recorded on the grounds that only internal consumers reach a proxy says nothing about an open finding on the same proxy disputing exactly that. Both are recorded, neither is arbitrated. See BTP security defects the scanner finds.
- Two defects of the same class and title in one file share one row, so one verdict covers both. That is a consequence of how a finding is identified; see what one BTP finding is about.
- The only action that removes findings is deleting the connection, which removes its runs and findings together. No scan deletes one.
¶ FAQ
¶ Can a scan overwrite a decision somebody recorded?
No. The decision, the note, the author, the timestamp and the first-seen date are never touched by any scan. Everything the analysis produced about the defect is refreshed, and everything a person produced is left alone.
¶ If I mark something as a false positive, will it come back?
Not as open. The row stays, carrying the verdict and the note, through every later scan of that object. It leaves the open count and remains in the total, so nobody is ever told that a finding went away when what happened is that somebody decided about it.
¶ Who can record a verdict?
Whoever holds the permission to manage findings. Reading, managing and scanning are separate permissions, because the last of the three spends your tenant's own API quota against production integration content.
¶ Is there an approval workflow or a due date on an accepted risk?
No. The capability records a decision, its author and its time, and does not manage a workflow around it. If an acceptance needs an expiry, that belongs in whatever tracks your exceptions, and the note is the place to write the reference.