¶ What the ABAP Scan Account Can Read
The ABAP scan account is a read-only SAP service user: it can read the complete ABAP source of the system, SAP standard code included, and anything hardcoded in it, and it cannot read business data, user data or configuration.
That is the sentence to put in front of an SAP security team, because it is the honest shape of what is being asked for. Reading ABAP source is not a narrow right. Source contains whatever the developer put in it, including credentials, endpoints and logic somebody wanted kept quiet. It does not contain the contents of the tables the code touches, and the account cannot reach those.
¶ What does the scan account need?
The grant depends on which transport the connection uses. All three read the same objects; they differ in how the SAP system exposes them.
| Transport | SAP prerequisite | Authorisation objects | What activating it exposes |
|---|---|---|---|
| Native RFC | a reachable SAP gateway | S_RFC, S_TABU_NAM, S_DEVELOP |
nothing new; the gateway is already there |
| SOAP RFC | an HTTPS port on the internet communication manager, and the relevant service node active | the same three | one SOAP endpoint |
| ABAP Development Tools | an HTTPS port and the ADT node active | S_ADT_RES, S_DEVELOP, S_TRANSPRT |
the ABAP development REST interface as a whole |
Remote-call authorisation is granted per function group, and the SOAP route needs one group that the native RFC route does not, so the SOAP grant is slightly wider than the native one for the same work. The ADT route is wider again, and it is the one to weigh most carefully, because activating it opens the whole development interface rather than one path.
A role definition for each transport ships with the product for the customer's SAP security team to review and build. Build the role from that definition rather than from a summary.
¶ What can the account not reach?
- Business data. The tables the scanned code reads and writes are not readable by this account.
- User and authorisation data. User master records and role assignments are out of reach. Analysing those is SAP segregation of duties analysis, which is a separate connection and a separate grant.
- RFC destination definitions and system configuration. Those belong to other capabilities and are not part of this grant.
- Anything writable. The account does not create, change, activate, delete or transport repository objects, and it does not execute business transactions.
The one qualification to "it does not write" belongs here rather than in a footnote: listing transport requests over the ABAP Development Tools interface stores a server-side search configuration in the SAP system, and it does so on each listing. That is a property of the ADT route only. The native RFC and SOAP routes write nothing.
¶ Is the account used only during a scan?
No. Connections are re-tested on a background interval so the console can report whether each registered system is reachable and whether its credentials still work. The account therefore logs on periodically for as long as a connection is active, not only when a scan runs, and those logons appear in the SAP security audit log.
The register records when each connection was last checked, which is why the account logs on between scans as well as during them.
Two consequences follow. The credential is a live one and should be managed as such: an expired password stops the register, not just the next scan. And a connection that is not wanted can be deactivated, which is what stops the checking.
¶ How do you confirm the role is complete?
A connection test proves the account can log on and read a sample. It is not proof that the role reaches every object type in scope, and a role that cannot read one object type produces a shorter report rather than an error.
The check that settles it is a single scan with every object type in scope, followed by a comparison: the number of objects in the report against the number of candidates discovery offered. If the report is shorter, something was refused and needs adding to the role. Run that comparison once when the role is first built, and again after any change to it.
¶ Limits
- A refused read does not appear in the findings. An object the account cannot read contributes nothing to the report, and is not counted as clean either. Use the object count comparison above rather than assuming coverage.
- A successful connection is not a complete role. They are different facts, and only the second one decides what a report covers.
- The account can read SAP standard source. That is unavoidable, since the repository read is not partitioned by namespace. The product's subject is the customer's own code; the access is wider than the subject.
- Source contains secrets. Granting source read is granting whatever the developers hardcoded. That is precisely why a scan is worth running, and it is also why the account and the installation holding the results need the same protection as a source repository.
¶ Frequently asked questions
¶ Does the scan account need SAP_ALL or developer rights?
No. It is a read-only account built from a named role, and it holds no change or transport rights. A person reading the same code by hand would typically need wider rights than this account has.
¶ Can the scan account read our customer or HR tables?
No. It reads repository objects and their dictionary attributes. The contents of application tables are outside the grant, including the tables the scanned programs themselves read.
¶ Which transport should we choose?
Native RFC where the gateway is reachable, because it is the narrowest grant. SOAP RFC where it is not. ADT where the landscape already runs it and transport-level scanning matters, keeping in mind that it exposes the whole development interface.
¶ Does the account need to exist in every client?
It needs to exist wherever the code you want scanned lives. Code is client-independent in the repository, but the connection records a client and a scan records the client it ran in.
¶ Will the scan account lock itself out?
The background check stops after repeated authentication failures rather than continuing to try, so a changed password does not keep hitting the SAP system. The connection then reports that it needs new credentials.