An SAP vulnerability assessment produces a list. That is the honest description, and it is the first thing to say when you ask a CFO to fund one. The list says: here is what is reachable, here is who can reach it, here is what it touches. It does not say that anyone has done it yet. The list is worth paying for because in SAP, reachable and money-moved sit two or three steps apart, and almost nobody has written those steps down.
This post is for the person who has to defend the line item and turn an SAP vulnerability assessment into business risk somebody outside IT can act on. Not the Basis lead who already knows what gw/reg_no_conn_info does, but the risk owner who has to explain to a non-SAP executive why a finding about an ABAP report matters to the quarterly close.
At a glance
What an SAP vulnerability assessment actually covers
Four layers. A decent assessment covers all four, because the paths worth worrying about run across the boundaries: a stored credential in SM59 is a dull configuration finding right up to the moment you notice the ABAP on the other end never checks who called it.
Start with platform and configuration, the classic Basis surface. Profile parameters you can read in RZ11: password minimum length under login/min_password_lng, automatic SAP* recreation under login/no_automatic_user_sapstar, session timeout under rdisp/gui_auto_logout. Gateway access control through secinfo and reginfo, and whether gw/reg_no_conn_info and gw/acl_mode are actually set or were left at whatever the install produced. Message server ACLs. Active ICF services in SICF, where plenty of production systems still have /sap/bc/echo and /sap/public/info switched on. RFC destinations in SM59, read for the rights of the stored user rather than for the count.
Identity and authorization is the layer everyone assumes the annual SoD review already handled. Default users still holding default passwords, which RSUSR003 will tell you in about ten seconds. Who holds SAP_ALL. Who holds S_DEVELOP in a production client. How wide S_TABU_DIS and S_TABU_NAM have been granted, because SE16N with a broad table group is a read of anything. S_RFC values left at *.
Custom code is where most of the real exposure lives, and where most assessments are thinnest. Every Z and Y program written since the implementation, every customer exit, every RFC-enabled function module somebody built for an interface a decade ago and never revisited. The recurring defect classes are boring, consistent, and the same handful in every system: missing authorization checks, injection into whatever the program assembles at runtime, file and command handling that trusts its input, and credentials left sitting in source. What varies between customers is not the kind of defect. It is how many.
If you are on BTP there is a fourth surface: Cloud Foundry application configuration, Integration Suite iFlows and the Groovy scripts inside them, API Management proxies and their policy definitions. A Groovy script step is application code running on your tenant, with the same ability to run commands and handle credentials as anything on premise.
Assessment and penetration test are different purchases
An assessment enumerates. A penetration test demonstrates.
The assessment answers “what is exposed, across everything, right now.” It is broad, repeatable, and it can be run against a hundred systems on a schedule. The penetration test answers “can someone actually get from here to there,” and it is narrow, expensive, and true only on the day it was run. A tester takes three findings the assessment listed on separate pages and chains them: a low-privilege user in the HR client reaches the ERP production system through a trusted RFC. That screenshot ends arguments in steering committees that a spreadsheet never will.
Both are worth buying, for different reasons. Confuse them and you end up with an annual pentest report on a shelf and no idea what changed in the eleven months after.
If you can only fund one, fund the assessment first, and fund it at a cadence rather than once. A pentest tells you that one path worked on one day. An assessment tells you the size of the surface, and surface size is what you manage. The fair counterargument: assessments generate findings nobody believes until someone proves one. That is exactly why the pentest exists.
Connecting findings to consequences an executive recognizes
This is the translation layer that most reports skip, and it is the only part a non-SAP executive will read.
Take a single finding. A custom report, call it ZFI_VENDOR_UPD, updates vendor master records and has no AUTHORITY-CHECK before the update. In scanner terms that is one HIGH with a CVSS score attached. In business terms: anyone who can execute that report through SE38 or a menu role can change vendor bank details in LFBK without holding XK02. Change the bank account, wait for the next payment run in F110, and the money leaves through your own controls, correctly approved, to the wrong account. Nothing in the payment process looks broken afterward.
Same exercise on an authorization finding. S_TABU_DIS granted too broadly to a support role means employee compensation, customer pricing conditions and open bank data are all readable by a group that was scoped to reset passwords.
Now the one that reaches the auditor: a missing authority check inside a function module that was released as RFC-enabled. Your segregation of duties model is enforced in the role design. This module ignores the role design. So an SoD control somebody signed off on is not actually in force, and that is how a code finding becomes an ITGC deficiency. Escalate that deficiency to significant and the external auditor moves toward extended substantive testing, right in the window where you are trying to close and file. The security risk and the filing risk arrive as one event.
Three sentences per finding is usually enough. Object, who can reach it, what it touches in the business. If your report cannot produce those three sentences, it is not yet a risk report.
Cadence, and who owns the fix
Cadence splits by layer, because the layers change at different speeds.
Configuration and authorizations drift slowly and are worth a full pass quarterly, plus a check after every major upgrade or support package. Patch state should be reviewed monthly against SAP Security Notes, which land on the second Tuesday. Custom code breaks the annual model completely. It changes every time a transport moves, so an annual scan describes a system that no longer exists. Scan custom objects as they are developed, in the IDE where the developer already is, and gate the transport before it leaves the development system. Our ABAP scanner connects over ADT and also runs as an Eclipse plugin, where double-clicking a finding opens the object at the offending line. That placement is the whole point: the finding arrives while the author still remembers writing it.
Ownership is where programs die. The default failure mode is that every finding lands on Basis, Basis owns maybe a third of them, and the rest sit in a spreadsheet until the next audit. My view: remediation ownership follows the object, not the org chart. A profile parameter belongs to Basis. A role that grants S_DEVELOP in production belongs to the authorization team. A Z report missing an authority check belongs to the application team that owns the process it serves, and their sprint, and their budget. Security owns the finding, the severity, and the deadline. Security does not own the code.
Whatever tracker you use needs more states than open and closed, and the one that matters most is risk accepted with a named person against it. A signed acceptance is a legitimate outcome. A tracker that does not offer it teaches people to close tickets dishonestly, and then your remediation metrics are fiction and you find out at the worst possible time.
What a finding costs before and after go-live
Before go-live, a missing AUTHORITY-CHECK is an edit to an object in an unreleased transport. The developer adds the check, retests the unit, and moves on. Cost: an hour, maybe two, and no coordination with anyone outside the team.
After go-live, the same finding is a change request. It needs an impact assessment, because the report now has users whose access will change when you add the check, and some of them are running it in ways nobody documented. It needs regression testing, a CAB slot, and a transport path through QA into a production window. If the object touches a financially relevant process, it may need a control owner sign-off and an update to the control documentation. And if the finding is discovered because someone used it rather than because someone scanned for it, add forensics, add a scope determination, and possibly add a notification obligation.
The multiplier is not a number I can source, so I will not invent one. Nobody who has sat through a change board disputes the shape of it.
Where an SAP vulnerability assessment stops
An SAP vulnerability assessment enumerates exposure. It does not prove exploitability, and you should be suspicious of any vendor who blurs that line.
Static analysis of ABAP reads what the code does. It cannot see that the only role containing that transaction was assigned to four people in Treasury, all of whom already have the underlying authorization anyway. Configuration review reads a parameter value. It cannot see the network segmentation in front of the port. CVSS scores are computed without your context, so a HIGH on a sandbox object and a HIGH on a production interface score the same and matter differently. Severity ranking is an input to prioritization, not the prioritization itself.
So findings need triage by somebody who knows the system, and a few of them need a tester to settle the argument. An assessment that ends at the PDF export is half a project. The other half is unglamorous: rank the list by what the objects touch, hand each item to the team that owns the object, then scan the same objects again a month later. The rescan is the part programs skip, and it is the only thing that tells you a fix held.
Talk to us about scoping an assessment
We run SAP vulnerability assessments and penetration tests, and we will tell you on the call which one your question actually needs.
Contact RedRaysRedRays is an independent SAP security vendor and is not affiliated with SAP SE. SAP and the product names referenced here are trademarks of SAP SE. Transaction codes, authorization objects and parameters named in this article are given for orientation; verify them against your own release before acting on them.
