RedRays, Inc. builds security products for SAP landscapes: a platform that reports what an SAP estate exposes, how it is configured and who can do what, and a scanner that analyses the custom ABAP written inside it.
These are the questions that belong to no single capability; anything specific to one is answered on that capability's own page.
RedRays, Inc. is a software vendor with two products. The RedRays Security Platform is one console over an SAP estate: exposed services, known issues, profile parameters, password hashes, segregation of duties, BTP content and the paths between systems. The ABAP Code Scanner covers the custom code no SAP Security Note will ever fix.
It is not a governance, risk and compliance suite, not an access provisioning system, not a log monitoring platform, and not a managed service. Nothing here requests access, approves it, grants it, or watches a system between runs. Every capability reads, reports, and stops there.
Checks are written per component rather than per release, so the answer is a list of components and not a version matrix. The ABAP application server is reached over Remote Function Call (RFC), its SOAP form and the ABAP Development Tools interface; network checks cover the dispatcher, the message server, the Internet Communication Framework, the SAP Java HTTP stack and its P4 service, SAP HANA, SAP Cloud Connector, SAP Business One Web UI and SAP BusinessObjects REST web services. The BTP assessment reads Integration Suite, API Management and Cloud Foundry, one tenant at a time. Nothing outside SAP is covered.
On your own infrastructure, inside your own network. Connections, credentials, scan history and findings live in that installation, and RedRays operates no multi-tenant store of customer data and no account that findings are uploaded to.
One thing, and only for code analysis: the source of the object being analysed. Custom ABAP, and BTP integration flow scripts and application bundles, go to a RedRays analysis service in the United States and findings come back; password hashes, user and role data, authorisation values, network inventory and configuration values do not. That is not the same claim as "nothing leaves", and the difference is visible at your own egress. Deployment and where data goes is the full statement.
No external model provider sees customer source code at any point. The model performing the analysis runs inside the RedRays deployment that receives the object and transmits nothing onward. What that deployment retains, and for how long, belongs in the agreement and should be settled before an evaluation.
Nothing has to be requested from RedRays: scan history, findings and stored source are in your installation, so removing the deployment removes them, and retention while it runs is your setting.
No. There is no transport to import into the ABAP system and no agent to deploy on a host. Each capability connects over a standard interface, or works from an upload or an offline extract.
A read-only service user per connected system, scoped to what that capability reads: profile parameters, RFC destination configuration, user and role data, repository source, or the password fields of the user master. These are separate grants on separate connections, and the port and service scan needs no credential at all. What SoD analysis reads from SAP and what the ABAP scan account can read set out two of them.
Every capability reads: nothing is written back, nothing is provisioned or patched, and no business transaction is executed. One exception belongs to one route, and is named rather than hidden: listing transport requests over the ABAP Development Tools interface stores a server-side search configuration in the SAP system.
A dated result with a stated scope, whose shape is set by the capability rather than by what it finds. None produces a single score, and none adds an unmeasured item to a pass count.
| Capability | What a first run produces |
|---|---|
| Port and service scan | Hosts, instance numbers and services, with no severity on any row |
| Vulnerability assessment | Findings per host and per port, in four bands, no score |
| Profile parameter review | One row per catalogued parameter: secure, vulnerable, or not found |
| Password strength testing | Per client, hashes read and hashes recovered. Never a password |
| Segregation of duties | One finding per person per rule, its grant paths, and what was suppressed |
| ABAP code scanning | Per object, the line range, the defect class, the path to the sink |
| BTP assessment | One finding per defect class, per file, per object, per connection |
| Threat modelling | The systems read, and the RFC hops that need no second password |
The technical part is short: an installation on a machine you provide, one system connected, one scan. What sets the calendar is the approvals: the read-only account, a network scope authorised in writing, and a non-production system to start on.
Yes, and the formats differ by capability. ABAP results export as a workbook, CSV, JSON, XML and SARIF, the last for when SAP findings must sit beside other application security results. There is no built-in ticket integration, and exporting is a separate permission from viewing.
SAP's own tools answer about the thing you named; these answer about the list you should have named. Transaction RZ11 gives the value of the parameter you typed and nothing about the one you forgot; a note list says what is installed, not what a service answers on its port. Neither was built to produce the denominator an auditor asks for.
An audit is a person's judgement over a sample at a point in time; this is a repeatable read of the whole list, asking the same questions in the same order every run, with the value and the condition that judged it side by side. It does not replace that judgement, which knows your business and your controls.
Nothing is exploited, nothing is written back, nothing is watched between runs, and nothing is compressed into one risk number. Coverage is bounded by what was asked, and each capability states its own boundary.
No, and the whole site is written to keep those apart. A clean result says the checks that ran found nothing, in the scope they ran over, on the date they ran. A check that never ran is not a check that passed. What a finding claims sets out where that is easiest to miss.