Most quotes for an ABAP code security scan arrive as a number per system per year. That unit is convenient for whoever wrote the price list and close to useless for you, because it has almost no relationship to the work involved. Two companies can each run three SAP systems and hold completely different amounts of custom code, and the one with more code pays more for everything downstream: reading the results, arguing about them, fixing them, checking the fixes.
What follows is the list of variables that actually move that number. No price list, and no benchmarks I cannot point at a source for. These are the questions a vendor should be asking you before quoting, and most of them you can answer yourself in an afternoon.
At a glance
Per-system pricing is the wrong unit for an ABAP code security scan
The scanning work is proportional to code, not to hostnames. An ECC development system carrying twenty years of Z reports is a different job from an S/4 sandbox with a handful of custom classes, and both count as “one system” on a per-system price sheet.
Per-system pricing survives because procurement likes it. It is one line on the contract, and it maps to a CMDB entry someone already maintains. I still think it is the wrong unit, for two reasons. It overcharges small systems, so people quietly drop them from scope, and those are often the ones with the ugliest code, because nobody reviewed them either. And it undercharges the one enormous system, so the vendor recovers the margin elsewhere, usually by shipping a raw finding dump and calling triage a services add-on.
Object count is the honest unit, ideally paired with a separate count of connected systems, since every connection carries its own setup work regardless of how much code sits behind it. When you evaluate a vendor, ask which of those two numbers the price follows, and ask what the invoice does when your developers add two thousand objects next year. Get that answer in writing before the renewal rather than after it.
Count the custom objects, then the effective lines
Before anyone quotes you, get your own object count. It takes ten minutes in SE16 against TADIR: filter on PGMID = ‘R3TR’, restrict OBJECT to the types that carry executable logic (PROG, CLAS, INTF, FUGR, ENHO, BDEF), and exclude the SAP-owned development classes so you are left with your namespaces. That number is the first thing to put on the table.
Then correct it, because the raw count lies in both directions.
- Includes inflate it. Every PROG/I is its own TADIR row, and a function group is a pile of generated includes around your actual function modules. Scanning by object type without collapsing includes counts the same code twice.
- Generated objects inflate it. Table maintenance dialogs from SE54, Smart Form function modules in the /1BCDWB/ namespace, proxy classes from SPROXY. They are custom by namespace and boring by content.
- Dead code inflates it. A Z report written for a 2011 data migration is still a TADIR row. Run SCMON or check SUSG usage data before you pay to analyze code that has not executed in years.
Effective lines matter more than object count once you get past a few thousand objects, because data flow analysis scales with paths through the code, not with file count. Four thousand forty-line ALV wrappers are a smaller job than four hundred classes averaging two thousand lines with real branching. If a vendor asks only for the object count and never asks how big those objects are, they are guessing.
Systems, clients, and where SAP standard code fits
Clients barely matter. ABAP source lives in REPOSRC and is client independent, so scanning client 100 and client 200 of one system returns the same source and the same findings. Configuration, authorization data and role design do differ by client, but that is a separate assessment with a separate method. Do not pay twice for one code base.
What does matter is how many independent code streams you have. One development system feeding QAS and production through STMS is one code base, and you should scan the development system, not production. That is where the source is editable, where the fix lands, and where you can open the object in ADT and look at it. Scanning production tells you the same thing a week later.
Three separate development systems for ECC, S/4 and BW are three code bases, three ADT connections, three sets of prerequisites. Each connection has a real setup cost that vendors tend not to mention: the /sap/bc/adt service tree active in SICF, a named user with S_DEVELOP and S_RFC authorization, and on the cloud ABAP stack a business user with a role built from the SAP_BR_DEVELOPER template, because technical users get rejected outright.
SAP standard code should be out of scope, and you should insist on it. You cannot fix it, changing it means a repair registration and an argument with support, and findings in SAP-delivered packages bury the ones you can act on.
The exception is your code living inside standard objects. Enhancement implementations, BAdI implementations, and the customer exits still registered in CMOD and SMOD are yours. So are genuine modifications, which you can list in SE95. Those belong in scope even though they sit in SAP namespaces, and a scoping conversation that misses them misses some of the highest risk code you own, because it runs inside standard transactions users already have access to.
A one-time ABAP code security scan costs less than continuous scanning, and is worth less
A one-time engagement is a fixed shape of work. Connect, enumerate, scan, triage, hand over a PDF and an Excel export, invoice. It is easy to buy and easy to sign off.
It also decays from the day it is delivered. Your developers keep releasing transports. The finding count starts climbing again immediately, and two years later you buy the same scan and rediscover much of what you already paid to find.
Continuous scanning inverts the cost curve. The marginal scan is small, because you analyze the objects inside the transport being released and skip everything unchanged. What you are actually paying for is the gate: a severity threshold that blocks a release, an exception path for the times the threshold is wrong, and a named person who owns the blocked queue at six in the evening on release day. That last one is the real cost, and it is organizational, not technical.
The technical side of a gate like that is trivial: a threshold, a list of changed objects, a pass or fail. The hard part arrives the first Friday it fails a release everyone wants shipped. If the answer that day is always to override, the gate is decoration, and you would be better off cancelling it and going back to scans you schedule on a calendar.
The two line items nobody budgets: triage and retest
A first scan of a mature custom code base returns more findings than you have developers. Every one of them needs a decision, and the decision is not automatable, because it depends on things the source does not state.
Take a missing AUTHORITY-CHECK. Whether it matters depends on whether the object is reachable, who can reach it, and what it touches. A dynamic SELECT built from a selection screen field is a different risk from the same statement built from a constant three lines above it. Somebody who knows both ABAP and the business process has to look. That person is usually the same senior developer you need for the fixes, so triage competes with remediation for the scarcest resource on the project.
Two things reduce the cost. First, record the decision as well as the fix. Each finding should move through a real status set (open, in review, confirmed, false positive, resolved, risk accepted) with the reason attached, and stable finding identifiers so the next scan does not re-ask a question you already answered. Second, triage by rule class first, not object by object. If a pattern fires two hundred times because of one code generator, you make one decision and close two hundred rows.
Retest is the line item that gets left out of the plan entirely. When a developer adds an authorization check, someone has to confirm it is the right check. An AUTHORITY-CHECK on S_TABU_DIS where the code should have used S_TABU_NAM will satisfy a pattern-based scan and still leave the table readable by anyone with a broad display authorization. The retest is a rescan plus a read of the diff, and on a long remediation program that repeats often enough to be its own line item.
What the scan cannot tell you
Static analysis proves that a pattern exists in source. It does not prove that a human being can reach it.
The RedRays ABAP Code Scanner narrows the gap by reading object metadata alongside the code, including object type, package, and for function modules the release state and the RFC scope, so a remote-enabled function module with a missing check does not read the same as a local subroutine with the same gap. That is still inference from metadata, and inference is not confirmation. Reachability through a custom transaction defined in SE93, a background job in SM37, an OData service, or a legacy RFC destination with a stored password has to be checked in a running system, by someone with access.
That is penetration testing, and it is priced and staffed separately. Any vendor who tells you a code scan alone establishes exploitability is selling you the easy half of the problem.
So when you ask for a quote, bring four things: your corrected TADIR count, the number of independent development systems, your monthly transport volume, and the name of the person who will triage the output. The first three size the scanning. The fourth sizes everything after it, and it is the one most buyers leave blank. Fill it in before you sign anything.
Count your objects, then talk to us
The RedRays ABAP Code Scanner reads objects from your system over ADT and runs inside Eclipse, so a finding opens at the line that caused it.
Explore the ABAP Code ScannerRedRays 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.
