SAP Code Quality & Security Vulnerabilities detection

Note: the information contained in this article is obsolete. For updated info, please read our Official Product Documentation here

ABAP applications programming -most of which are large customized systems- adds to the challenge of managing these large development projects, to ensure that the resulting code has the necessary quality and security, in order to avoid problems once in production, or excessive maintenance costs. The lack of verification or manual verification of the quality and security of these large systems is still a reality in about 40% of developers. Using Kiuwan Code Analysis helps reduce maintenance costs by up to 50%.


About ABAP

00 SAP

ABAP (Advanced Business Application Programming) is a fourth-generation language developed in the 1980s and created by SAP company. Originally used to develop the SAP R/3 platform, first released in 1992, it was also intended to be used by SAP customers to enhance SAP applications. Its syntax is similar to COBOL and is fairly easy to learn for programmers. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, so object-oriented concepts are necessary to create ABAP programs. And, finally, it also requires knowledge of relational database design.

Code Quality & Security in ABAP

SAP Applications have moved from “isolated systems”, characterized by long release cycles, few attack vectors and companies security based on the use of firewalls, to the current “open systems”, with frequent release cycles, no network boundaries, cloud-based applications and hacker attacks. And for the next future they have to face high frequency releases, interconnected networks and cyber attacks.

Despite SAP has its own tool call Code Inspector for checking ABAP coding and DDIC objects under aspects of functional correctness, performance and statistical information, it has meaningful drawbacks that make it no suitable to be used by quality or security offices that have to lay down a holistic solution for all the languages in the customer application portfolios, or need to take into account other code analysis critical characteristics, like portability or security.

Surveys show that, at least, 40% of developers do not measure, monitor nor fix their code quality and security problems. Those who do it, increase their job’s delivery predictability in 9% and they also improve their application quality and security in 9%, reduce their maintenance costs up to 50%, or its technical debt till 90%.

Some warnings, errors or programming best practices should be obvious and generally valid for everybody, but they are not detected automatically by ABAP Development Environments and you may want to get help to know if the code you write or is written for you matches your organization code style, as well as your quality and security goals.

There are several kinds of tools that can help your development team, your quality and security office to do that, like Static Code Analysis Tools (SCA), Metrics, Dynamic Code Analysis, Profilers, Memory Tools or Monitoring Tools. Of these, the ones which provide more benefits are the SCA Tools.

Common issues when developing in ABAP

Talking with ABAP programmers and Project managers, they have exposed me several known problems, like:

  • Team size and fluctuation, that lead to very heterogeneous knowledge and skill set.
  • Maintenance, that gets harder with each iteration.
  • There is too much code for manual review of coding guidelines.
  • Complexity, that is too high for manual checks, because with code size, complexity grows exponentially.
  • Code that looks locally ok, that can lead to problems when seen in its context and call hierarchy.
  • Development teams ignarance about secure coding best practices.

In most cases, the main problem is that you do not know what your problems are until you analyze and measure your code.
We need to detect several types of issues, i.e. security flaws, code style, incompetent or inefficient code, concurrency and design issues, etc., although not everyone has the same consequences immediately.
For this post, let me focus on security flaws, where it is possible to found the kind of vulnerabilities that I am showing in the next paragraphs that have a very high impact:

Call transactions without check that current user has authorization

Without proper authorization checks, the program may allow an unauthorized user to start a restricted transaction.
Should we care about this? SAP was obviously aware of this security flaw and, in recent versions (7.4 and higher), they added WITH AUTHORITY-CHECK to CALL TRANSACTION command for explicit authorization check.
In 7.0 with enhancement package 3 (and higher), S_TCODE authorization object is checked in CALL TRANSACTION, so this vulnerability is especially useful for previous versions of ABAP.

This is a piece of code that violates this practice:



Use of Dynamic Code Constructs

ABAP Dynamic Code constructs are potential targets to code injection attacks, particularly when dynamic code generated could be affected by external inputs.

Such dynamic code constructs cannot be fully tested by QA team and leaves no trace, as code exists in memory (it is generated at runtime); it could be used to encode backdoors that may pass security audits.

This is a security defect APP-01 in BIZEC APP/11 standard.
As in the example below, these are several pieces of code that violates this practice:




Kiuwan Code Analysis helps us avoid these pitfalls.

Only for ABAP, it brings more than 230 rules. Among others, Kiuwan has these rules to detect the common mistakes with exceptions showed above:

  • Authorization check must be done explicitly before CALL.
  • Avoid Dynamic Code constructs.

First, I check if  I have the rules capable to detect the above vulnerabilities in my Quality and Security Model:




The details of the rules can be found in the rules library, where you can consult examples of right code that solves the founded vulnerabilities.




Then, by analyzing the code, I get these results (among many other metrics, indicators, reports, etc.) in Kiuwan’s Summary:




And these other detail result in Kiuwan Defects Dashboard:



If we have the time that Kiuwan suggests us in order to fix theses vulnerabilities, we can see the effect once we do it.


Kiuwan has an interesting feature to quantify our progress, comparing some of its indicators:




If you are interested in a more detailed guide, we reccomend you download our free ebook Bulletproofing your SAP ABAP applications