An exemption is the deliberate decision to exclude or suppress specific findings, warnings or errors identified by a code scanning tool. While it may seem reasonable not to report false positives in future results, this mechanism poses significant risks.
As usual, we only discuss technical issues in the context of SAP security. In an SAP code security process, an exemption is applied when the flagged issue is deemed acceptable or irrelevant for a particular case, often due to:
False Positives: The tool incorrectly flags code as problematic when there is actually no technical risk
Context-Specific Cases: The issue does not apply due to the specific context of the code (e.g., a hard-coded user account that does not exist in the system).
Risk Acceptance: The team acknowledges the issue but accepts the risk for business or technical reasons.
Exemptions are usually documented with a justification and require approval to ensure accountability. They are supposed to help focus development efforts on critical issues, while avoiding the implementation of unnecessary fixes for low-risk or inapplicable findings.
From that perspective, exemptions make perfect sense. However, the devil is in the detail. The challenge lies in reliably and repeatedly identifying a specific risk in the code. Once an exemption has been approved, the tool must remember this decision and link it reliably to the relevant code.
Let's look at a simple example. Imagine that line 100 of program Z_EXAMPLE contains a statement that the scanner has erroneously identified as problematic, and that an exemption is to be made. The scanner could create an identifier for this by storing the ID of the check that flagged the issue, the program name, the line number where the statement was found, and the SAP system where the code is stored. This would work well until someone adds code to the program between lines 1 and 100. This would change the line number of the exempted code. Consequently, the exempted issue would reappear upon the next scan.
Therefore scanner developers that want to provide exemptions need to design an algorithm capable of re-identifying an exempt issue, even if the code has been modified in places that are not relevant for the issue. Without going into technical details, this is a highly complex problem. It is almost equally as complex as reliably identifying the corresponding security risk. Whatever solution a scanner vendor comes up with, the scanner either re-reports an issue due to changes that are not actually related to the issue, or it does not re-report the issue even though there has been a relevant change to the code in question. To minimize false positives, vendors tend to implement option two.
Let’s take SAP’s exemption logic as an example for option two. The documentation on help.sap.com says:
„The minimum scope of an exemption is for all instances of a particular check message in a single ABAP include or other type of repository object. Developers and quality managers should be aware that exemptions are not user-specific. That is, an exemption for a check message or entire check in code on which several developers are working masks findings for all of the developers, not just for the developer who requested the exemption.“
What are the consequences of SAP’s algorithm?
1. If an ABAP program contains multiple security vulnerabilities of the same type, exempting one of them exempts them all - no matter who caused them.
2. If a vulnerability is exempted in an ABAP program, another vulnerability of the same type introduced months or years later will not be reported - no matter who causes it.
Both situations could pose a severe risk to a company. This is because it would be possible to create vulnerabilities/backdoors 'in the shadow' of an exemption. If a malicious developer knows that a potentially harmful statement has been exempted in a program, they can easily add a real vulnerability to the program without setting off any alarms. Every approved exemption increases such a risk.
But how to do it better?
The root cause of this issue is that scanner results are sent to developers without being qualified by ABAP security experts first. An effective approach could be to not allow any exemptions and force developers to fix all reported issues. However, this would also force them to 'fix' false positives and thereby creating lots of discussions.
A better approach would be for a team of ABAP security experts to validate the results of a code scan and only forward the ones that matter. This team should review every program change that is linked to potentially critical issues. If they identify a risk, they can create a ticket for the responsible developer and provide concrete guidance on how to mitigate it. Although there may still be a need for repeated reviews of the same findings, ABAP security experts can usually judge more quickly and accurately whether these represent a risk than developers can. Such pre-qualification also eliminates false positive results. All in all, this approach frees up developers to focus on what they love most: creating cool new programs.
This is the second 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.