Safeguarding Partner Products from Security Threats and Vulnerabilities
                            (As a part of Endorsed Apps -Premium Certification)

                                 Secure your app before selling to customers

Most of the companies build their software applications with focus on the functionality and features to ensure it will work absolutely fine at the customers’ landscape. The security aspects are sidelined due to this and are a factor for security issues for any SAP customer. In industry terms, it is called as security of the software supply chain. Like any other chain, it is the link that needs to be strengthened. Major security breaches have happened due to lack of security in the software supply chain. In this aspect, SAP would like to help their partners to elevate the security in their software.

There are two aspects to it: Secure development programming and Security Code scans (static and dynamic). To gain the customers trust, security plays a vital role and is a mandatory aspect for any serious software application built.

Today, application layer attacks are the most frequent pattern in confirmed data breaches. Currently, application security solutions can be difficult for overworked security teams to manage and scale, developers are not empowered to fix security issues and can find only certain software vulnerabilities.

– To whom this blog is intended for?

This information is primarily for partners undergoing Premium Certification as part of Endorsed App engagement with SAP. Binary Security code of the partner application(Static Code Scan) is a mandatory part of the Premium Certification.

This blog is addressed to developers, testers or security experts in partner teams, who are involved in the application build phase to understand what are the security threats/flaws and how securely this can be checked and rectified.

– What are the major security risks while building the application/solution?

According to the OWASP Top 10, following are the ten most critical web application security risks that must be taken into account during secure development:

Few other common security risks during the time of developing the Software:

Improper Validation of Array Index, External Control of File Name or Path, Stack-based Buffer Overflow, Use of Inherently Dangerous Function, Cross-Site Request Forgery (CSRF), Download of Code Without Integrity Check, Indicator of Poor Code Quality, Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP Remote File Inclusion’), Incorrect Ownership Assignment etc.

For more details on secure development practices, you can refer the below link https://cwe.mitre.org/index.html

-Overview process:

-Why my binaries did not pass the first scan as per the policy?

Based on the first scan results, partners find that there are a lot of security issues (especially Very High and High priority issues) which he/she couldn’t find all security vulnerabilities during a manual review (while writing the code).

In case partners have used other tools (e.g., open-source scan tools), similar errors may not have been identified. That is because automated checking tools provide only the high-level assessment or report of the code and it wouldn’t have checked the deeper security review.

Another reason could be because of the usage of third party libraries there by affecting partners code in turn though it is not a security issue as a part of partner code.

-Even after fixing the issues the scan is still showing few issues, why?

Based on the first scan result, it would just list the classes of vulnerabilities found in your application but wouldn’t have checked every instance of code.

Partners security expert has to validate and make sure that the binaries meets the current best security practices (Security Policy) and make sure that there are NO known vulnerabilities.

-The binaries have failed multiple times showing the issues still, why?

There could be multiple reasons.

1) Only few issues are fixed but not all.

2) Even after changing the code, not all dependencies related issues are fixed.

3) Based on the code change, new issues would have been encountered.

4) Issues are not remediated correctly because of misunderstanding what is the exact issue.

5) Bad security design where in it requires re-architecting of the complete design looking from the security aspect as well.

-There are false positive results and have to be mitigated, how?

It is true that sometimes the scan can also provide false positive results because of the nature of design, OS environment used, network environment used.

Partners can provide their mitigated comments but have to follow the process thoroughly.

Points to note for mitigation:

1) While providing mitigating comments, it is required to follow the company provided RISK Tolerance guidelines.

2) Mitigations must be appropriate to the type of flaw.

3) It is expected from a partner to follow the monster mitigation board: http://cwe.mitre.org/top25/mitigations.html

4) These mitigated comments have to be checked by the security consultant of the security tool used and has to say whether the provided comments conforms/deviates as per the company’s security policy.

-Example for mitigation proposal:

Let us see an example of providing the mitigated comments for CWE 89 (SQL Injection)

Technique: M1- Establish and maintain control over all of your inputs

Specifications: The dynamic parameter is used in a location of the query that cannot be parameterized. In order to mitigate the risk of SQL injection, we check that the received value from the user is either “ASC” or “DESC” as implemented in the ” query White List Order (string query order)” as part of ($this_class/$class_name).

Risk: There is a risk that in future development someone may use the same query execute statement without using the query White List Order (string query order) function. We have added a task (APP-1495) to the backlog for 2018.3 to update the query execute function to include calls to query White List Order (string query order)

Verification: Please refer to unit test results query White List Order Test that are checked in to source control as part of every build cycle. This is also validated in manual test case scenario APP-TEST-4292 with results also in our tracking system.

– How to identify the issues in SAP partner software?

With SAP Security Policy in place, SAP provides a platform to SAP partners to identify these above mentioned security threats, vulnerabilities (and more..) in partners’ products and gain insight into the security of the partner software.

Refer the below blog / documents for more details:

Blog link: https://blogs.sap.com/2021/05/19/gain-sap-customers-trust-by-making-your-product-secure/

SAP ICC finder page: https://www.sap.com/documents/2017/10/c4d06eb1-dc7c-0010-82c7-eda71af511fa.html

For more details, kindly reach out to icc@sap.com