No ABAP security process works efficiently without a code scanner. But are ABAP security scanners actually as effective as claimed? What value do they offer, and to what degree can you rely on them? This blog post reveals several technological limitations of ABAP code scanners.
ABAP security scanners look for dangerous programming statements or sequences thereof in code. This would be a trivial task and could be done with free tools from SAP. However, these programming statements are not generally dangerous, but only under certain conditions. It is the job of an advanced security scanner to assess whether any given dangerous programming statements actually represent a risk in a given program. Such functionality is worth money. Because without it, companies would have to inspect each such command manually.
Scanners use techniques like control flow analysis and data flow analysis in order to assess the actual risk caused by any such statement. They need to find out if a critical statement can actually be reached during execution (control flow) and whether it can be manipulated through input (data flow). Unfortunately the ABAP language contains several dynamic commands that can be used to trigger control flows and data flows. The execution of these commands depends on data and can therefore only be analyzed when a program is executed.
But ABAP code scanners need to make assumptions about how a program behaves by analyzing its source code. Since they can't run a program and observe its behavior step by step, they must make assumptions about code execution, which leads to mistakes being made. They don't detect every control flow, nor do they understand every data flow.
In such cases, they report the presence of potentially dangerous programming statements, but with a low probability rating, as it is unclear whether there is actually a risk. If they were to report them as critical, they would produce lots of false positives. Since nobody wants to use ABAP security scanners that produce false positives, vendors have no option but to reduce the probability.
If a company had only a few potential risks identified by their scanner, they could all be manually validated. However, most ABAP code scanners are overloaded with security test cases and often produce reports spanning several thousand pages. Therefore, in practice, analyzing all potential issues would be extremely time-consuming and costly. This is why companies usually only deal with high-priority, high-probability risks. As a statistical consequence, some dangerous programming statements are overlooked.
Unfortunately, not all security risks in ABAP code are the result of mistakes. Backdoors and malware are intentionally designed to cause harm. Consequently, their developers try to take measures to obscure the true nature of their programs. They use techniques such as SCA evasion, which are designed to trick scanners into reducing the probability rating of an issue. These techniques are effective because scanners reduce the priority of issues in cases of uncertainty. This is to avoid false positives. Since false positives don't generate sales, SCA evasion techniques exploit a design weakness in scanners that cannot be fixed.
Malware developers have an additional advantage in that they do not require input to cause harm. They can write scripts that attack a system in a predefined way. While the scanner would detect the risky commands involved, it would assign a low rating since there is no input.
Please also refer to our article "ABAP Code Scanners are useless against ABAP Malware" for more information on the risks of such scenarios.
However, there are also other tricks that can be used to bypass scanner detection. These work when companies use scanners as a gatekeeper between their development and QA systems, a process euphemistically referred to as 'stay clean'. In such scenarios, all code packaged in a transport is scanned the moment it is passed on to the next system. If the scanner detects a significant vulnerability, the process is halted and the developer must correct the code.
However, what if the developer simply splits the dangerous programming statements and distributes them across more than one transport? The scanner will only see multiple fragments, each representing low risk. It is only when these fragments are assembled — after all relevant transports have been deployed to the target system — that the vulnerability becomes active.
This means that, in addition to the number of security risks that the scanner's algorithm misclassifies, security risks that have been deliberately programmed also remain unnoticed.
This technical deficiency alone creates a significant gap in an ABAP security process based solely on scanner analyses.
These are not the only shortcomings, however. Code scanners cannot detect design flaws in code because they cannot understand what a program actually does. For instance, while scanners can easily determine that a program does not perform any authorization checks, they cannot assess whether an existing authorization check is appropriate and sufficient. Therefore, any project that only adds the authorization checks reported as missing by the scanner falls far short of what is required.
But how to do it better?
To address potential obfuscation techniques, companies need to enhance their processes.
First, they should create a list of all dangerous programming statements that could fully sabotage an SAP system, as well as a list of those that could substantially damage important business processes, e.g. by deleting arbitrary data. This list should be carefully compiled with stakeholders to ensure that all high-risk statements are included.
All scanner results relating to any of the commands on this list must be manually inspected by experienced ABAP security experts to identify any tricks aimed at circumventing the scanner's rating algorithm. Such analysis is also helpful in eliminating false positive results among issues with high probability ratings.
In order to address risks associated with bad design, companies are encouraged to work with threat modeling. Threat modeling is a structured process designed to enhance the security of software by identifying, assessing, and mitigating potential threats early in the development lifecycle. It begins with mapping out the application’s components, data flows, and trust boundaries. Next, potential threats, such as unauthorized access or data breaches, are identified through brainstorming sessions or by applying frameworks like STRIDE. Each threat is then assessed for its likelihood and potential impact, allowing teams to prioritize risks based on their severity. Mitigation strategies, such as implementing encryption or access controls, are developed to address these risks. Finally, the threat model is continuously reviewed and updated as the project evolves to ensure ongoing relevance.
The advantages of threat modeling are significant. It promotes proactive security by catching vulnerabilities early, which reduces the cost and effort required to address issues compared to fixing them after deployment. It also improves the overall design of the software by encouraging secure architecture and coding practices from the outset. By prioritizing risks, threat modeling enables teams to allocate resources efficiently, focusing on the most critical threats. Additionally, it supports compliance with regulatory and industry standards by providing a systematic approach to security. Furthermore, threat modeling fosters collaboration and raises security awareness among developers, architects, and stakeholders, ultimately leading to more robust and secure software that is better protected against costly security breaches.
This is the first article in our series related to a secure ABAP coding process, that provides you with insights into issues with tool-driven security initiatives.
If you'd like to know more about optimizing your secure coding process, please contact us.