¶ What One BTP Finding Is About
A finding in the RedRays SAP Business Technology Platform (BTP) security assessment is one defect the analysis reported in one file of one scanned object, on one connection. It is never a tenant, never a person, and never a whole scan run.
Everything the SAP BTP security assessment counts is built on that unit, so it is worth being precise about what the unit includes and what it deliberately leaves out.
¶ What does a single BTP finding identify?
Every finding names six things: which cloud service the connection speaks to, which connection, which object as the tenant identifies it, which file inside that object, the defect class, and the defect title. Alongside those it carries the line or line range, a severity band, a score where the analysis produced one, a description, the evidence it was read from, and a recommendation.
One row is one defect class in one file of one object, and it carries the verdict a person recorded beside the band the analysis raised.
Those first six are also the finding's identity - what decides that two reports are the same finding rather than two. Two consequences follow directly:
- The same defect reached through a second connection is a second finding, with its own decision recorded against it. Connecting the same subaccount twice produces two independent sets.
- Renaming an object in the tenant does not split its history, because the identity is over the object id the tenant uses, not the display name shown on screen.
¶ Why is the line number not part of a finding's identity?
Because code moves and the defect does not move with it. If the line were part of the identity, adding an import above a hardcoded credential would create a new finding and quietly drop the decision somebody recorded against the old one.
So the line is displayed and refreshed, but it is not what makes a finding itself. It is also stored as text rather than as a number, which lets an analysis that objects to the shape of a whole file say so as a range - an empty request pre-flow in an API proxy is a fact about the file, not about one statement in it.
One trade comes with that choice: two defects of the same class and title in the same file collapse onto one row by design, and one decision then covers both. A finding count is therefore not a count of vulnerable lines.
¶ What does one finding not claim?
It does not claim to be one occurrence, one line, or one exploitable path. It claims that a named defect class was reported, in a named file, of a named object, on a named connection. The evidence block is what lets a reader who did not run the scan check that claim.
Two more limits worth naming. The score attached to a finding is an assessment of the defect class; the product does not re-compute it and has no control that adjusts a score for how the object is deployed or who can reach it. And a finding about a missing authentication policy says what the deployed policy content does, not whether the backend behind the proxy enforces authentication of its own.
¶ What is the state of an object, as opposed to a run?
Runs accumulate; objects do not. The scan history is collapsed to one row per object, and the state of the object is the state of its newest run. An object that failed on Monday and completed on Tuesday is one object in the completed state. An object that completed on Monday and failed on Tuesday is one object in the failed state, and the product shows the failure rather than the last good result.
Of the states a run can end in, exactly one counts as assessed.
| State of the newest run | Assessed | What it means about the object |
|---|---|---|
| Completed | Yes | The object was read and analysed. Its findings, including none, are a result |
| Failed | No | The object was never read. Nothing about it has been established either way |
| Running | No | A result may be coming. There is not one yet |
| Queued | No | Accepted for scanning and not started |
| Cancelled | No | Stopped by an operator before it finished |
The last-scan date shown against a connection is a narrower thing than any of that. It is the newest run recorded for that connection, whatever its state and whichever object it was about. It is not a statement about the rest of the tenant, and it is not evidence that the tenant answered today.
¶ Which counts are shown, and why they differ
Three different statements are made about the same set of findings, and they are never added together.
| The count | What it counts |
|---|---|
| Open findings | Findings nobody has recorded a decision about yet |
| Ever reported | Everything reported on that scope, decided or not |
| Per severity band | The same open findings, split by band, with empty bands omitted |
A decided finding leaves the open count and stays in the ever-reported count. Both are correct answers to different questions, and each control states its own scope in words. A count that could not be produced shows a dash rather than a zero, because zero would read as "nothing found" when the truth is "the question did not get an answer" - the rule set out in what a finding does and does not claim.
None of these counts is a statement about the size of an estate. They count what the recorded runs reported, over the objects those runs covered.
¶ Limits
- A finding count is not a defect count. Same class, same title, same file collapses to one row.
- A severity band is the analysis engine's, and a recorded decision never changes it. A finding somebody marked as fixed and a later scan reported again can return with a higher band while its decision still reads as fixed. Nothing on screen flags that combination, so a re-opened band is something a reviewer has to look for.
- Nothing ages a run out. A run recorded as still going stays that way until something changes it, and the product cannot tell a run in flight from one nobody is working on.
- Object state says nothing about objects nobody queued. See coverage and what was not assessed.
¶ FAQ
¶ If I re-scan an object, do my recorded decisions survive?
Yes. A re-scan refreshes the scanner-owned half of a finding and leaves the decision, the note, who recorded it, when they recorded it and the first-seen date untouched. Triage and recorded decisions lists exactly which fields fall on each side of that line.
¶ Why does one object show a failure when it scanned successfully last week?
Because the newest run describes the object. Showing the last good result instead would mean reporting an object as assessed on the strength of a run that has been superseded by one that never read it.
¶ What happens to a finding the newest scan did not report again?
It is kept and marked rather than deleted. A defect can drop out of a scan because it was fixed or because the scan never reached the file, and only a person can tell those apart.
¶ Does a finding tell me whether the defect is exploitable?
No. It tells you a defect class was found in a named file, with the evidence it was read from. Whether the credential is still valid, whether the proxy has ever been called, or who can reach either is outside what the assessment reads. See BTP security defects the scanner finds for what each class does and does not assert.