Custom ABAP is the part of an SAP landscape that carries no CVE, appears in no SAP Security Note and is closed by no patch day, because it was written inside the customer's own system and only the customer can fix it.
Patch management answers a question about software SAP wrote and SAP can repair. Every custom program, function module, class, BSP application and enhancement in the Z or Y namespace, or in a registered partner namespace, sits outside that arrangement. Nobody outside the customer has ever read it. It was written to a deadline, often by somebody who has since left, and it runs on the same application server, against the same tables, with the same authorisations as SAP's own code.
Because there is no vendor on the other side of it. A Security Note names an SAP component and a correction. A support package replaces SAP objects. Neither touches an object the customer created, and no note will ever be written about one. A landscape that is completely current on notes has changed nothing at all about the risk carried in its own namespace.
The same is true of the other assessment routes. A configuration review reads profile parameters. A network scan reads what is listening. An authorisation review reads who holds what. None of them opens a program and reads it.
Because the defect is usually a path between two ordinary statements, not a string.
A dynamic CALL FUNCTION, where the function module name is a variable, is not a defect. SAP's own code is full of them, and so is every dispatcher, factory and framework hook ever written in ABAP. A selection screen parameter is not a defect either; it is the most ordinary statement in the language. What makes a defect is a parameter that arrives from whoever runs the report and reaches that call with nothing in between constraining it.
Search for the sink and you get the whole system. Search for the source and you get every report that has an input field. Only the join of the two is the answer, and no text search produces a join.
The same problem runs the other way for a whole class of defect. A missing AUTHORITY-CHECK is an absence, and an absence has no string. A program that reads an HR infotype without checking authorisation looks, character for character, like a program that has no reason to check one. Telling the two apart means knowing what the program touches and what a check would have to cover.
A manual review produces a document of what was found and no record of what was looked at. The second review cannot start where the first stopped. The audit after that cannot tell whether an object is absent from the report because it was clean, because it was skipped, or because the reviewer ran out of time.
There is also no short list to work from. A custom code base is not divided into a dangerous part and a safe part, and no property visible from outside an object says which it belongs to: not its name, not its author, not its package, not its age. The reviewer has to open all of them, against a mental list of defect shapes that is never written down and is not the same on Tuesday as it was on Monday.
And reading the code at all costs privilege. A person doing it by hand usually gets that privilege by holding developer rights on the system, which is wider than a read-only service account and comes with the ability to change what is being read.
| Manual review | Automated ABAP scan | |
|---|---|---|
| Record of what was examined | reviewer's memory | the object list of the run |
| Repeatable next quarter | starts again | same scope, re-run |
| Finds a data path across statements | yes, if the reviewer sees it | yes, and it prints the path |
| Finds an absent authorisation check | yes, with effort | yes, when that check is in scope |
| Judges whether the program should exist | yes | no |
| Understands the business rule behind the code | yes | no |
Neither replaces the other. ABAP scanner against manual review sets out the split in detail.
Yes, and patching is the reason why. Patching closes defects in SAP code. It leaves every line the customer wrote exactly as it was, including anything that reaches the file system, the operating system or the database directly.
Enough that reading it by hand is not a repeatable exercise. The number varies by landscape, and it is one of the first things a scan measures rather than something to assume.
A functional or quality review checks that the code works and follows conventions. Security defects such as a dynamic dispatch fed by user input pass that review routinely, because the code does exactly what it was written to do.
Static quality tooling inside SAP covers a range of correctness and performance issues, and some security ones. It is not the same catalogue, and it does not report a data path from an input statement to a sink as a security finding with a severity.