¶ Coverage and What Was Not Assessed
Coverage in the RedRays SAP Business Technology Platform (BTP) security assessment is the number of objects whose newest run completed, over the number of objects the scanner has ever queued - printed as two numbers rather than as a percentage, because a percentage hides its own denominator.
An object is assessed when its newest run completed. Nothing else counts as assessed, and the distinction between an assessment that came back clean and one that never happened is the thing this page is about - and the rule the whole SAP BTP security assessment is arranged around.
¶ What does "assessed" mean here?
It means one thing: the newest run of that object read it and analysed it. A run that failed, was cancelled, is still queued or is still going leaves the object unassessed, and its findings, including none, are not a result.
That is a stricter rule than "no failures". An object whose run is still going has established nothing in either direction, so it is not counted as clean, and the all-clear message shown when every object's newest run finished is withheld while any object is in an unresolved state. The five states a run can end in, and which of them counts, are set out in what one BTP finding is about. Claiming nothing is in an unknown state while an unfinished object sits underneath would have one screen contradicting itself two rows apart.
¶ What does the coverage denominator exclude?
Objects nobody has ever queued. The denominator is the scanner's own history with that tenant, not a count of what the tenant holds.
This is the limit to carry away from the figure: a full bar is not a swept tenant. If every unassessed object finished tomorrow, coverage would be complete and would still say nothing about integration content in those subaccounts that has never been scanned. An object the credential could not list in the first place never becomes a run at all, so it is in neither half of the fraction and on no screen.
Nothing in the capability can count what a credential was never shown. That is a limit of any tool held out at arm's length by a key somebody else issued, and the honest response to it is to print "unknown" where a count would go rather than a number nobody measured. What the credential reaches is decided when you connect a BTP tenant.
A tenant that has not answered is given a statement that its content is unknown, not an empty table that would read as a tenant with nothing in it.
¶ How is an object nobody read shown?
In a panel that names it, placed above the figures it qualifies rather than below them, so a reader meets the caveat before the numbers it applies to. The panel counts the objects, names each one with its tenant and cloud kind, prints the reason recorded against the failed run, and - in the position a finding count occupies on an object that was read - prints "unknown, not checked".
The objects nobody read are named above the figures they qualify, each with the reason recorded against it and no count invented in its place.
The placement is the argument made in layout. An object nobody read can never be skimmed as an object with nothing wrong.
The sentence under the heading is chosen from what was recorded, because the operator's next move differs:
| What was recorded | What the panel says | What to do next |
|---|---|---|
| The tenant refused or did not answer | The objects were never read, so nothing about them has been assessed | Check the credential, its role assignment, and the route to the tenant |
| The objects were fetched and not analysed | Your tenants are reachable and the analysis did not answer | Nothing points at your BTP configuration; retry once the analysis service is back |
| A mixture of the two | Both, with each group counted | Both, in that order |
Neither sentence claims anything about whether the object is clean, and neither names a single cause where the record does not distinguish one.
¶ Why do two counts of "not assessed" differ?
Because they answer different questions and both are right. The panel counts objects whose newest run failed. The per-tenant chip counts every object whose newest run is not a completed one, which also takes in queued, running and cancelled objects. A reader who expects them to match will conclude one is broken; they are two populations, and the product names both rather than showing only the flattering one.
¶ Why an empty findings list is not a clean result
Because a findings list is a list of what was found, not a list of what was looked at. Filter to a tenant, a cloud kind or an object with nothing recorded, and the product refuses to congratulate the reader: the empty state says in words that no findings recorded for this filter is not the same as nothing being wrong, and points at the screens that say which objects were never assessed.
The same rule runs through every count in the platform. 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". See what a finding does and does not claim.
¶ Limits
- Re-queueing does not move coverage. Retrying a failed object moves it from failed to queued, which is still not assessed. One press does not change the fraction, and nothing pretends it did.
- A retry queues one run per failed object, not a tenant-wide sweep, because re-reading everything to fix a handful of objects spends your API quota on work that already succeeded.
- The figures are historical. They are read from runs recorded earlier. A tenant that stopped answering last month is flagged on its own card, but the counts above it still show what the last successful runs reported, and the date on the card is the place to catch that.
- Coverage is assembled from a bounded walk of scan history. On a tenant with a long enough history, the oldest objects fall off the end of that walk, and the denominator becomes a floor rather than a total.
¶ FAQ
¶ Why not just show a coverage percentage?
Because a percentage hides its denominator, and the denominator is the interesting part. Two numbers force the question "five of what", which is the question a reader should be asking.
¶ Does a failed run mean the object has a problem?
No. It means nothing about the object was established. The failure is about reaching or reading the object - a credential, a role assignment, a route - and not about what is inside it.
¶ How do I get a tenant fully covered?
Queue the objects you care about, fix the failures the panel names, and re-run them. Coverage will then describe the objects you have queued, which is the strongest statement the capability can make, and it is still not a claim about content nobody has scanned.
¶ Does the assessment re-scan on its own to keep coverage current?
No. There is no scheduler in this capability. Every run is started by an explicit request that records who made it, so coverage ages until somebody asks for a new run. See triage and recorded decisions for what that means for decisions recorded against findings.