The RedRays Security Platform and the RedRays ABAP Code Scanner are installed on the customer's own infrastructure: connections, credentials, scan history and findings stay there, and one outbound path exists, which carries source to be analysed.
That path is stated at the top of this page rather than at the bottom, because a reader who finds it buried stops trusting the rest.
On a machine the customer provides, inside the customer's own network. It holds the SAP and BTP connections, the credentials stored against them, whatever each scan read, every finding and the whole history of both. So the customer holds the data, in their own database, under their own backups and their own access control.
RedRays operates no multi-tenant store of customer data, no vendor tenant that findings are uploaded to, and no back channel into the installation.
The source of an object being analysed, and nothing else a scan reads. To analyse a custom ABAP object, the installation sends that object's source to a RedRays analysis service in the United States and receives findings back. The same path carries the integration flow scripts and application bundles described in SAP BTP security assessment, and it is the only path the product opens on its own.
One behaviour belongs beside that. Where the analysis cannot settle whether a candidate finding is real, it asks for the bodies of the routines the code calls, and the installation resolves each one and sends it once. An object nobody selected can therefore be sent while another is analysed, and the alternative is a verdict reached without the evidence.
Two further things leave only when a person presses something, both into the customer's own systems: a downloaded report file, and a tracker export writing one record per finding into a configured Jira or ServiceNow instance.
| Leaves the installation | Never leaves the installation |
|---|---|
| The source of a custom ABAP object being scanned | SAP password hashes, and any password recovered from them |
| The bodies of routines it calls, where the analysis asks | User master data, roles, authorisation values and the conflicts computed from them |
| BTP integration flow scripts and application bundles | BTP API proxy policy content, analysed inside the installation |
| A report file an operator downloads | The port and service inventory, vulnerability findings and their evidence |
| One ticket per finding, on a tracker export | Profile parameter values, RFC destination configuration and the landscape map |
| Nothing else | SAP and BTP connection details, and the credentials stored against them |
SAP password strength testing, the profile parameter review and segregation of duties call no external service at all: the hashes are read into the installation and attacked there.
It analyses the source it was sent, returns the findings and keeps no copy. Nothing about a landscape is assembled on the RedRays side, because nothing is retained there to assemble.
No. The model that performs the analysis runs inside the RedRays deployment that receives the source and transmits nothing onward, so no external model provider holds customer source code.
A read-only service user per connected system, scoped to what that capability reads. None needs an administrative profile or change authorisation, and none writes.
| Capability | The kind of access it needs |
|---|---|
| ABAP code security scanning | Repository source and object attributes. Source holds whatever a developer put in it, the widest read here |
| Segregation of duties analysis | User, role and authorisation master data. No business documents |
| Password strength testing | The password fields of the user master, one client at a time. The most sensitive grant here |
| Profile parameter review | The instance profile parameters in force |
| Threat modelling | Each system's outbound RFC destination configuration |
| Vulnerability assessment | No credential for checks a stranger can get answered; a stored logon only where you choose |
| Port and service scan | No credential at all: its subject is what an unauthenticated caller sees |
| BTP security assessment | A service key or read-only technical user, issued in the customer's own tenant |
No. There is no transport to import, no add-on and no agent on a host. Each capability connects over a standard interface, or works from an upload or an offline extract. The SAP system talks to the installation, and the installation is what reaches outward.
One qualification, so that "nothing is written" survives being checked: listing transport requests over the ABAP Development Tools interface stores a server-side search configuration in the SAP system, on each listing. That is the ADT route alone, and native RFC and SOAP write nothing.
Everything the installation holds. Retention is a customer decision rather than a vendor setting, because the history sits in their own database, and deleting a scan, a connection or the installation deletes it with no copy left behind. Stored credentials are encrypted with the installation's own key and never returned, so they cannot be read back by an operator, an administrator or support. What an operator downloads is theirs to look after, and a recovered-password export is a credential file rather than a report.
Every capability except code analysis, yes. Port scanning, vulnerability assessment, profile parameters, password testing, threat modelling and segregation of duties all run inside the network, the last of which also accepts an offline extract: see analysing an air-gapped SAP landscape. Code analysis needs the analysis service reachable, so a fully air-gapped installation produces no code findings.
For code scanning, one outbound HTTPS destination from the machine the installation runs on, and nothing inbound from the internet. RedRays names that destination, so it can be allowed on its own and everything else denied. Every other path stays inside your network.
The scan reports the failure, and an object whose analysis did not complete is recorded as not analysed rather than as clean. An outage cannot become a clean report, which is the rule set out in what a finding does and does not claim. Unfinished objects can be re-run once the path is back.
No. It answers the installation over a standard SAP interface, and if your SAP servers have no route out today, that stays true after this product is installed.