CVA - Code Vulnerability Analyzer
The SAP Code Vulnerability Analyzer 🔗 (new version of the document 🔗) is SAP’s recommended tool 🔗 for checking ABAP code for security issues. It scans for common security issues and comes with the usual features like baseline, false positives handling or IDE integration 🔗. The tool is available on-premise and in the cloud (BTP, ABAP environment) 🔗. While the tool’s pricing strategy is a blocker for on-premise usage 🔗, it comes “for free” with the BTP ABAP environment 🔗. As it is part of ATC, CVA can be easily intergrated into the developer workflow.
The tool offers a wide range of checks. SAP Note 1921820 🔗 provides an overview of the checks and their availability. A blog post lists some of those in more detail 🔗. On top, CVA allows to cover the BSI requirements for APP.4.6 ABAP Programming 🔗 (additional hints 🔗) as stated in SAP Note 3704459 🔗.
The tool is used internally by SAP to check their own ABAP coding.
The problem
Humans.
To be more precisely: security fixes 🔗 caused by high CVSS Scores. For instance:
- CVSS Score 9,1. Code injection via remote exposed function SAP Note 3697979 🔗
- CVSS Score 9,1. Code injection via remote exposed function SAP Note 3694242 🔗
- CVSS Score 9,9. Insufficient input validation: execute SQL queries SAP Note 3687749 🔗
- CVSS Score 8,1. Run form routines SAP Note 3688703 🔗
- CVSS Score 8,1. Missing authorization checks SAP Note 3565506 🔗
- CVSS Score 9,9. Code injection SAP Note 3668705 🔗
- CVSS Score 9,9. Code injection via remote exposed function SAP Note 3627998 🔗
Those are elevated security issues. Code injection, sql injection, missing authority checks. The have one thing in common:
CVA detects them.
So, why do these security issues exist? Does CVA not detect them? Is CVA not the right tool for finding security issues in ABAP coding?
No. CVA works. It detects security issues. The problem here is the human in the loop. CVA allows to ignore security findings. Code can be put in production even when CVA reports it as dangerous. Humans can bypasse the findings. This is a common feature. Intended for bypassing blockers during a go-live. While those findings should then be fixed as soon as possible, for a release, this is harder to achieve. The result of prioritizing quick success is to roll-out insecure software.
The solution
Maybe SAP not allowing humans to ignored findings for high risk issues like missing authority check or (remote) code injection? Making it clear(er) that a missing feature is better than introducing a security risk to customers? Maybe adding more people to the security audit and ask for a group to approve bypassing critical findings? Raising more security awareness inside SAP? Maybe. All could work. But the risk could be too high for SAP as this would mean to not be able to ship certain features in time. It is a fine balance between shipping features to customers, deadlines and security. The way how software - and therefore features - are shipped in the SAP universe does not make this decission easier.
Trust
That software with a certain complexitiy is bug free will never happen. It will also always contain at least one security vulnerability. But a question that CVA has to answer is: if it is used by SAP, why was the vulnerability not catched? Was it the tool that failed, or the process inside SAP?
What could also help is to provide customers and users the critical ABAP coding for self evaluation. Provide the faulty code so customers can check it in their Z-namespace with CVA. This shows that the finding was reported and that it was not a CVA error that the security issue was not catched. This at least establishes trust in the CVA tool. Everything else is a process that each company must decide for itself.