An SAP vulnerability assessment from the RedRays Security Platform runs two populations of check against the same landscape: those written to be answerable by an anonymous caller, which always run, and those that need a stored logon, which run only against the services where one is stored.
The difference is not a setting to get right once. It changes what a report means, and two scans of one landscape against one catalogue produce materially different reports depending on which logons were stored at the time.
What a stranger on the network sees. That is the point of it, and it is the population worth running first, because everything it finds is reachable by somebody who has no account on your system. Anonymous checks cover the classic exposure questions: administrative endpoints that answer without authentication, optional services and test handlers left enabled, information a component gives away about itself, and known defects distinguishable from the outside.
Its limits are the same as its virtue. It cannot see the inside of a component, cannot read a configuration table, and cannot ask a database anything.
Access to what only a logged-on caller can read. Checks over an SAP HANA database session are the clearest case: they open a session and ask the database, so they need a database user and password stored against that service and do not run without one. Certain HTTP checks are in the same position, because the state they distinguish is only visible behind a logon.
| Population | Runs when | Answers the question |
|---|---|---|
| Anonymous checks | Always, against every service of a matching type | What can a stranger on this network reach |
| Credentialed HTTP checks | Where a logon is stored against the service | What does the component look like from inside |
| Database session checks | Where a database logon is stored against the service | What does the database itself report |
The check is skipped. It is not run and found clean, and this is the single most important sentence on the page: a service saved with no logon produces a short report for a reason no reader can see on the report.
The capability does not print, on a report, which logons were stored when it ran. If you plan to compare two scans of one landscape, record what was stored at the time of each, or the comparison will attribute to remediation a difference that credentials caused. The same trap is the subject of what a clean report does not say.
Both, and in that order the first time. Run anonymously to establish what is exposed without any account at all, because that population is the one an outsider has. Then store logons for the services where a credentialed check is worth the access, and run again to see what the outside view could not reach.
Storing a credential is a decision with its own consequences. It creates a stored SAP or database logon inside the platform, it widens what one press of a scan does, and it is the reason the scanning account should be a purpose-made account with the narrowest access the checks require, rather than a convenient administrative one.
Yes, and many customers start there because it needs no account provisioning. Read the result as what an unauthenticated caller on that network can reach, and nothing wider.
The narrowest that lets the checks you care about run, on a dedicated account, with its use logged on your side. Treat it as you would any account that reads across a production landscape.
The network and database checks read. A full scan also reads profile parameters, component versions and SAP note status over Remote Function Call (RFC) where the licence permits.
It regularly does, because the most serious exposure classes are precisely those an unauthenticated caller can reach. See SAP vulnerabilities an assessment finds.