RedRays, Inc. builds security products for SAP landscapes: a platform that reports what a landscape exposes, how it is configured and who can do what, and a scanner that analyses the custom ABAP code written inside it.
An SAP estate is not one security question. The services it answers on are a network question, the profile parameters it starts under are a configuration question, the authorisations it generated are a people question, and the ABAP somebody wrote in it last year is a question with no vendor behind it at all. Different teams ask them, on different cadences, usually into different spreadsheets. The products below answer them from one installation, and every answer states what it was measured on.
| Product | What it covers |
|---|---|
| RedRays Security Platform | One console over an SAP landscape: what is exposed, what is affected by a known issue, how the system is configured, whether the stored password hashes hold, who can do what, and which system reaches which |
| RedRays ABAP Code Scanner | Security analysis of the custom ABAP written inside an SAP system: the programs, function modules and classes that no SAP Security Note and no support package will ever fix |
Eight capability areas. Each settles one question, and each links to the page that sets out what it measures and what it does not.
They compose rather than overlap. A port scan produces the inventory a vulnerability assessment runs against. A path into production is worth what the account at the far end of it can do, which is a segregation of duties question. A profile parameter that switches an authorisation check off says nothing about who would pass it. None of them substitutes for another, and no page here pretends otherwise.
The product is installed on the customer's own infrastructure. Source code, SAP connections, credentials, scan history and findings stay there, under the customer's control. There is no multi-tenant service holding customer data, and no RedRays account that customer findings are uploaded to.
There is one outbound path and it belongs to code analysis. To analyse an object, the installation sends that object's source to a RedRays analysis service in the United States and receives findings back. The model that performs the analysis runs inside that deployment and sends nothing onward, so no third party model provider ever sees customer source code at any point.
| Data | Leaves the installation |
|---|---|
| Custom ABAP source of an object being scanned | Yes, to the analysis service, for analysis |
| BTP integration flow scripts and application bundles | Yes, to the analysis service, for analysis |
| BTP API proxy policy content | No, analysed inside the installation |
| SAP password hashes, and any password recovered from them | No |
| User master data, roles, authorisation values, SoD findings | No |
| Port scan inventory, vulnerability findings, profile parameter values, RFC destination configuration | No |
Deployment and where data goes states the whole arrangement, including what the installation needs and what it never sends.
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 standard interfaces: Remote Function Call, its SOAP form, and the ABAP Development Tools interface. On the network side, checks exist for the ABAP dispatcher, the message server, the Internet Communication Framework, the SAP Java HTTP stack and its P4 service, SAP HANA over a database session, SAP Cloud Connector, SAP Business One Web UI and SAP BusinessObjects REST web services. In the cloud, the BTP assessment reads Integration Suite, API Management and Cloud Foundry, one tenant at a time.
By keeping three statements apart, on screen and in every export: what was measured, what was never asked, and what a person decided.
A check that never ran is not a check that passed. A suppressed finding is not a silence. A skipped scan is not a clean scan. A count of rows in a report is not a count of distinct problems.
The rule costs something visible: several screens carry an unmeasured column that a tidier product would fold into the pass count. It is also why a clean result here is worth reading. What a finding claims sets it out, with the cases where the difference is easiest to miss.
On the customer's own infrastructure, inside the customer's own network. Connections, credentials, scan history and findings live in that installation, and RedRays does not operate a multi-tenant platform holding customer code or customer findings.
Only the source of an object being analysed, and only for code analysis: custom ABAP, plus BTP integration flow scripts and application bundles. Password hashes, user and role data, authorisation values, network inventory and configuration values never leave the installation. See deployment and where data goes.
No. The model that performs code analysis runs inside the RedRays deployment that receives the source, and sends nothing to an external model provider. That deployment is in the United States, and it is the only outbound path the product has.
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 where no connection is available.
A read-only service user per connected system, scoped to what the capability reads: profile parameters, RFC destination configuration, user master and role data, repository source, or the password fields of the user master. The port and service scan needs no credential at all, because its subject is what an unauthenticated caller sees.
No. Scans run when they are scheduled or when somebody starts them, and every report carries the date it was read on. A capability that cannot say when it last measured something says so rather than showing a number.
For segregation of duties, yes: an offline extract can be uploaded and produces a full scan, badged permanently as an imported extract. ABAP source can be uploaded, imported from a Git repository, or submitted from a development environment or a build pipeline. The other capabilities need a connection.
With a scope conversation, then an installation on a machine you provide, pointed at one system. Bring one non-production system, a read-only account for it, and a written scope for anything that touches a network, which is a decision to make before it is a technical step. Frequently asked questions covers the rest.