Vulnerabilities, threats, and risks in SAP applications are some of the most important concepts in the domain of SAP cybersecurity because they are used to build any cybersecurity program.
Therefore, understanding these concepts, as well as the standards that are used to normalize them, is of key importance. These concepts also relate to each other, so we’ll wrap up by understanding their relationship and how we can use that in our efforts of securing SAP applications. We’ll begin by discussing the types of security vulnerabilities before moving on to introducing you to the main vulnerability standard.
Security vulnerabilities are weaknesses in a computer system, which could be in the form of any building block of the technology stack: the application, the operating system, the database, or even within network devices. Security vulnerabilities could be present in the software itself or in its parametrizations/configurations, but these could also be present due to design flaws, which are the hardest vulnerabilities to fix. Vulnerabilities often expose certain parts of the application to be abused by an attacker, which could be an internal attacker (i.e., an insider) or an external attacker, to eventually gain some level of access into the system.
We can separate security vulnerabilities into two big categories, as follows.
In most cases, weaknesses are introduced into the software unintentionally by developers and affect a specific version of that software. The solution to this type of vulnerability is usually a security patch. In SAP applications, a security patch is known as an SAP Security Note. In most cases, once these vulnerabilities are patched, they remain patched and the security vulnerability goes away.
Parametrizations of an application can introduce a risk into a certain part of the application. In most cases, these configurations are well documented except for “undocumented features.” The solution to these types of weaknesses is typically a specific value or set of values to be applied to that configuration, which is usually documented in an SAP Note. One particularity of this type of weakness is that they don’t go away entirely, as configuration values can be changed over time and move from a secure value into an insecure one. This type of vulnerability requires constant oversight to avoid being reintroduced into the application.
There are several standards that can help organize and identify vulnerabilities, as you’ll see in the next sections.
If you’re an SAP-savvy person instead of a cybersecurity expert, you might not be familiar with the terms around vulnerability standards, but in the domain of cybersecurity, there are very important pillars to describe specific vulnerabilities as well as types of vulnerabilities.
Here are some common terms you should become aware of.
CVE is a unique ID assigned to each software vulnerability that is publicly disclosed and becomes known to the world. This assigned ID contains not only a numerical part but also the year of assignment, which provides an overview of how old the vulnerability might be in terms of years. These IDs are assigned by a CVE Numbering Authority (CNA). In 2017, SAP became a CNA, which allows SAP to issue the specific IDs of vulnerabilities that affect SAP software and for which SAP releases security patches. That is why for the past couple of years, SAP has been releasing security patches (SAP Security Notes) with the CVE directly assigned to the title of the note.
CWE is a unique ID assigned to each type of software vulnerability. This helps categorize vulnerabilities and grouping them into the same type of vulnerability, which can be helpful in several initiatives, including vulnerability management programs. SAP doesn’t release CWE in the vulnerabilities that are periodically patched.
Both CVE and CWE are sponsored and maintained by MITRE, which according to its website “is a not-for-profit corporation committed to the public interest, operating federally funded R&D centers on behalf of US government sponsors”. Thanks to the contributions of MITRE, all software vendors around the world can pinpoint individual vulnerabilities so organizations (and individuals) can properly manage those vulnerabilities, including detecting and solving them.
CVSS is a standard that allows you to describe the characteristics of a given vulnerability, with the output being a numerical score from 0 (least critical) to 10 (most critical). A CVSS of 10 represents those vulnerabilities that are remotely exploitable with no user and that can be used to completely compromise a system. There are several versions of CVSS from the first version released in 2005 (V1), all the way to the latest V4, which was released in November of 2023. The latest version of CVSS incorporates the following attributes as part of the base calculation of the score:
CVSS is sponsored and maintained by the global Forum of Incident Response and Security Teams (FIRST), which aims to assist organizations be more effective in responding to security incidents. SAP incorporated CVSS v3 into all security patches (SAP Security Notes) for the past few years, so this is a standard that was widely adopted by SAP and the product security response team at SAP.
To make it more concrete, let’s analyze a specific example of a security vulnerability in SAP. This vulnerability was reported by the Onapsis Research Labs and patched by SAP in 2024.
Let’s answer some questions about it:
Earlier, we discussed the different security vulnerabilities that could affect SAP applications, and later we discussed the standards that we can use to identify and manage security vulnerabilities. In this section, however, we’ll discuss what happens when the vulnerability is actually used. According to NIST, a cyberthreat is defined as follows:
Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability.
So, bringing the definition back to earth is when an attacker is targeting our landscape and abusing vulnerabilities or weaknesses (i.e., by exploiting a vulnerability).
Threats are driven by threat actors, which could be script-kiddies, cybercriminals, or state-sponsored. All three types have different motivations and more importantly different types of resources to target organizations. Research has demonstrated that all types of attackers are currently also targeting SAP applications and have the knowledge as well as the tools to do that. This is why it’s so important to address vulnerabilities and weaknesses in SAP applications, so they don’t materialize into cyberthreats.
Traditional risk management practices define an equation to quantify risk, based on two main components: probability and impact.
So, when it comes to quantifying risk to SAP applications, let’s consider how these two components balance in terms of yielding a value for the risk of a given vulnerability:
This component of the equation for SAP applications becomes straightforward because, for most SAP customers, these applications run the most critical business processes and store some of the most sensitive information for the organization. Therefore, downtime is prohibitively expensive, a data leak could have significant monetary and compliance consequences, and modification of business information could lead to substantial financial fraud. Because of all this, when we talk about SAP applications, the impact component of risk is among the highest possible values.
It may have been true a few years back that the complexity of SAP applications wasn’t known to threat actors, so they weren’t targeting this technology stack. However, over the past couple of years, we’ve seen an increase in the interest in threat actors to target SAP systems as part of their campaigns by exploiting SAP vulnerabilities and actively compromising these systems. Because of this, the probability component has been increasing on cybersecurity risks for SAP applications.
These two building blocks of the risk equation for cybersecurity risks affecting SAP applications are extremely high, so these cybersecurity risks have been increasing over time to levels that shouldn’t be ignored by upper management.
Editor’s note: This post has been adapted from a section of the book Cybersecurity for SAP by Gaurav Singh and Juan Perez-Etchegoyen. Gaurav is an SAP cybersecurity manager at Under Armour with more than 19 years of experience and a proven track record of helping organizations protect themselves from cyber threats while maximizing their SAP investments. Juan is the chief technology officer at Onapsis. With more than 20 years of experience in the IT security field, JP is a leading expert in business-critical application security, specializing in safeguarding ERP landscapes.
This post was originally published 9/2025.