¶ ABAP Scanner Against Manual Review
An automated ABAP scanner and a manual code review answer different questions: the scanner finds defect patterns and data paths across every object in scope and records exactly what it examined, while a reviewer judges whether the code should exist, whether its business rule is right, and whether a defect matters here.
The two are complementary and the split is not subtle. Most of the argument for a scanner is not that it is cleverer than a reviewer. It is that it is repeatable, and that a review which cannot be repeated stops being evidence the moment it is filed.
¶ What does a scanner find that a reviewer does not?
Coverage that can be stated. A scan records the object list it worked through. A review records what it found. The difference matters at the next audit, when somebody asks whether an object is absent from the report because it was clean or because nobody reached it.
Every run stays on the record with the scope it was given, so the next review starts from what the last one examined.
Paths across statements, at scale. A reviewer reading one program sees a dynamic call and traces its variable back. A reviewer reading four hundred programs does not do that four hundred times with the same attention on the last one as on the first.
Absences. A missing AUTHORITY-CHECK is invisible to a search and easy to miss by eye, because nothing on the screen draws attention to a statement that is not there.
The same standard every time. A scanner does not have a bad week, does not know who wrote the code, and applies the same catalogue in November that it applied in March.
A denominator. A scan states how many objects it read and how many lines it covered before it states what it found, which is the number every other figure has to be read against.
¶ What does a reviewer find that a scanner does not?
Whether the program should exist at all. A scanner has nothing to say about a report that extracts the full customer master to a spreadsheet every night, correctly, with every authorisation check in place.
Business logic defects. Wrong tolerance, wrong account determination, an approval step that approves its own document. The code does what it was written to do, and no static check knows what it should have done.
Intent. A reviewer can tell a deliberate backdoor from a debugging shortcut somebody forgot to remove, and can ask the author. A finding cannot.
Context that decides severity. Whether a defect matters here depends on who can start the program, which client it runs in, whether the system is reachable from outside, and what a compensating control already covers.
The design around the code. A pattern repeated across forty programs is one architectural decision, not forty findings, and only a person reading them together says so.
¶ Comparison
| Automated ABAP scan | Manual code review | |
|---|---|---|
| Objects covered | every object matching the scope pattern | as many as time allows |
| Record of what was examined | the run's object list | the reviewer's memory |
| Repeatable next quarter | same scope, re-run | starts again |
| Data path from input to sink | printed on the finding | traced if the reviewer sees it |
| Missing authorisation check | found when that check is in scope | found with effort |
| Hardcoded credential | found | found |
| Business logic defect | not found | found |
| Whether the program should exist | not addressed | addressed |
| Severity adjusted for this landscape | a general rating | a judgement |
| Access needed to do the work | a read-only service account | usually developer rights |
| Cost of a second pass | another run | another review |
¶ How the two fit together
The order that works is scan first, review the output. The scan produces a list with a denominator attached, which turns the reviewer's job from "read the custom code" into "confirm or reject these findings and look at these objects". Triage decisions recorded against findings carry forward to the next scan of the same object, so the reviewer's judgement is not thrown away at the next run.
The cases worth a reviewer's whole attention after a scan are the ones a scanner is weakest on: the objects with no findings but a large blast radius, the repeated pattern that is one design decision, and anything where the fix is not local.
¶ Limits
- A scanner reports what is in its catalogue. A defect class nobody wrote a check for is not reported, and a check outside the profile that ran did not run. See scan profiles and what clean means.
- A finding is not proof. Nothing is executed against a running system. An exploitability verdict is a judgement about the source.
- False positives exist. A path that looks reachable in the source may be closed by a caller the analysis did not see. That is what triage is for, and a decision recorded on a finding stays recorded.
- A reviewer needs the code too. Removing the scanner does not remove the access question; a person reading ABAP by hand usually holds wider rights than the scan account does.
¶ Frequently asked questions
¶ Can a scanner replace an ABAP code review before transport?
It can replace the security half of it, and it can run earlier. Scanning from the IDE or from a build pipeline puts the finding in front of the developer before the transport is released, which is the point at which fixing it is cheapest.
¶ How do we handle false positives?
Triage them once. A finding can be marked not exploitable with a reason, and the decision carries forward to later scans of the same object rather than reappearing at every run.
¶ Is a scan enough for an audit?
It is the evidence half. A scan states what was examined, under which scope, and what was found, which is what an auditor cannot get from a review document. Whether the findings were acted on is a separate record.
¶ Which should we do first?
Scan, because it tells you how much code there is and where the concentrations are. A review planned against that list is a different exercise from a review planned against a namespace.