¶ ABAP Code Security Scanning
The RedRays ABAP Code Scanner is a security analysis tool for custom ABAP: it reads the programs, function modules and classes written inside an SAP system and reports the security defects in them, which no SAP Security Note and no support package will ever close.
- Reads source, runs nothing
- Nothing to deploy inside SAP
- Clean means clean for that profile
Every other security question about an SAP landscape is a question about software SAP wrote. Which ports answer, which notes are missing, which profile parameters are weak, who holds which authorisation: all of those have a vendor behind them. Custom ABAP has nobody behind it. It carries no CVE, it appears in no note, and it reaches the same tables, the same function modules and the same authorisation objects that SAP's own code does. A landscape can be fully patched, fully hardened, and still be one dynamic CALL FUNCTION away from arbitrary execution on the application server, because the statement that gets there was typed by the customer.
¶ What is ABAP code security scanning?
ABAP code security scanning is static analysis of custom ABAP source. The scanner reads the source of an object out of the SAP system, analyses it without executing anything, and reports each defect as a finding that names the object, the object type, the line range, the class of defect and the path through the code that makes it a defect.
Nothing is run. No business transaction is executed, no business data is read, and no repository object is created or changed. The subject is the text of the program, and the product of a scan is a statement about that text as it stood when it was read.
Every count on the landing view is taken over objects that were read and analysed, not over the custom code that exists.
¶ What does the scanner look for?
The scanner ships with a fixed catalogue of checks over the classes of defect that appear in custom ABAP. The categories, rather than the individual rules:
| Defect class | What it looks like in ABAP | CWE |
|---|---|---|
| Code injection through dynamic dispatch | a variable target on CALL FUNCTION, CALL METHOD, PERFORM, SUBMIT, CREATE OBJECT or a generated subroutine pool, where the variable comes from input | CWE-94, CWE-470 |
| Missing authorisation check | a sensitive read, write, transaction call or file operation with no AUTHORITY-CHECK in front of it | CWE-862 |
| SQL injection | dynamic Open SQL, native SQL through EXEC SQL, or ADBC statements built from input | CWE-89 |
| Operating system command injection | external command execution on the application server with an input-controlled command or parameter | CWE-78 |
| Directory traversal and unsafe file access | OPEN DATASET and related file operations on paths the caller controls | CWE-22 |
| Hardcoded credentials and secrets | passwords, keys and tokens written into the source | CWE-798 |
| Cross-site scripting in SAP web content | unescaped output in BSP applications, Web Dynpro components and ICF handlers | CWE-79 |
| Backdoors and hidden logic | comparisons against a specific user name, client or system id that switch behaviour | CWE-912 |
| Information disclosure | sensitive table content written to a list, a log or a trace | CWE-532 |
The full breakdown, with what each class does to an SAP system, is on ABAP security defects the scanner finds.
¶ What does one finding tell you?
A finding names one object, one line range and one class of defect, and where the analysis established a data path it prints that path as a source and a sink: the statement that takes the input, and the statement that uses it. That pairing is the reason a scanner exists at all. A dynamic CALL FUNCTION is not a defect on its own, and a selection screen parameter is not a defect on its own. The edge between them is.
What one ABAP finding identifies sets out every part of a finding and what each part does and does not claim.
No user, no role and no authorisation assignment is analysed. Several checks ask whether the code contains an authorisation check; none asks whether a particular person would pass it.
¶ How does source get to the scanner?
Four routes, and they do not need the same access:
- a live connection to the SAP system, over native RFC, over SOAP RFC, or over the ABAP Development Tools interface
- a transport request, scanned by its object list, on demand or as new transports are released
- an upload of source, or an import from a Git repository
- a developer key used from the Eclipse plugin or from a build pipeline, which submits source directly and needs no SAP connection at all
How ABAP source reaches the scanner compares them, and what the ABAP scan account can read is what an SAP security team is being asked to grant.
There is nothing to deploy in the SAP system. The scanner connects to SAP as a read-only service user over a standard interface, or it takes source that has been uploaded, imported from Git, or submitted from an IDE or a pipeline.
¶ Where does the code go?
The product is installed on the customer's own infrastructure. Source, SAP connections, scan history and findings stay there. The one exception is the analysis itself: 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.
That is one outbound path, it is the only one, and it is described in full on deployment and where data goes.
¶ What does a clean result mean?
A scan runs the checks in the profile it was given, and a clean result is a statement about that profile. A scan run under a critical-only profile that comes back clean says the critical checks found nothing. It does not say the object has no security defects, and it does not say that a check for the defect actually present was ever asked.
Read every clean result together with the profile that produced it. Scan profiles and what clean means is that point in full, and what a finding does and does not claim is the same rule across the platform.
¶ Limits
- The scanner does not execute anything. An exploitability verdict on a finding is a judgement about the code, not the result of an attempt against a running system. Nothing here is proved by execution.
- It does not say who can run the program. No user, no role and no authorisation assignment is analysed. Several checks ask whether the code contains an authorisation check; none asks whether a particular person would pass it. That question belongs to SAP segregation of duties analysis.
- It does not read SAP Security Notes. Custom code appears in none of them. Note and patch status is a different capability.
- A finding describes the code as it was read. A scan stores the source it analysed. Re-checking a finding against the current source is a separate action.
- What is scanned is what discovery matched. SAP has no flag meaning "custom", so the candidate list comes from a namespace pattern the operator supplies. A pattern that misses a namespace produces a scan that misses it too.
- Findings are not deduplicated across runs or systems. Two scans of one object write two sets of findings. Nothing joins one defect across two objects, two projects or two systems.
¶ Which page answers which question?
¶ Frequently asked questions
¶ Does the scanner need to be installed inside SAP?
No. There is nothing to deploy in the SAP system. The scanner connects to SAP as a read-only service user over a standard interface, or it takes source that has been uploaded, imported from Git, or submitted from an IDE or a pipeline.
¶ Does it scan SAP standard code?
The scan account can read SAP standard source, and the product's subject is the custom code the customer wrote. Standard code is SAP's to fix and is covered by notes and support packages, which is exactly the coverage custom code does not have.
¶ Can it run in a build pipeline?
Yes. A developer key authenticates source submitted from the Eclipse plugin or from a CI job, so code can be scanned before its transport is released. See how ABAP source reaches the scanner.
¶ Does customer source leave the network?
The source of each object being scanned is sent to a RedRays analysis service in the United States, and findings come back. Everything else stays in the installation, and no model vendor receives customer source code at any point.
¶ What does a scan produce for an auditor?
A per-object report that states what was looked at before it states what was found, plus workbook, CSV, JSON, XML and SARIF exports. See ABAP scan reports and exports.
¶ How long does a scan take?
It scales with the number of objects, not with the number of defects. Each object is read, analysed and stored separately, so the cost of a scan is set by how wide the namespace pattern is rather than by how much turns out to be wrong.
Part of the RedRays SAP security platform. Related: why no SAP patch covers custom ABAP, ABAP scanner against manual review, deployment and where data goes.