A data analyst takes a deep-dive into defect-datasets. What does she learn about AppSec on the way? Welcome to the third installment of Enso Security’s AppSec research series comparing defect data, the technologies involved in collection, severity levels, and CVE alignment over time from the perspective of a data analyst.
What did we review in the previous blogs?
Vulnerability Data for Security Risks
As application security has become a business critical requirement, many AppSec teams utilize various vulnerability listing services to help them focus on specific weaknesses, including:
These lists offer different approaches to vulnerability categorization.While the CWE top 25 list covers a broad range of vulnerability types and categories, such as cross-site scripting and buffer overflow, OWASP’s list categorizes vulnerabilities in a more general sense to provide a broad, risk-oriented perspective. In addition, there can be an overlap between categories in these two lists, and some CWE categories are categorized as sub-categories of the OWASP top 10 list.
Common Vulnerability Categories
In our data collection, we see that SCA tools usually rely on a CVE feed as a standardized source of information for publicly known vulnerabilities and exposures, while SAST tools usually rely on the CWE for categorizing issues. Many scan results contain information that can be easily attributed to the data in common CVE databases, such as a description of the vulnerability, exploitability and a fix suggestion. This information is very useful for tagging vulnerabilities into categories that can later assist AppSec teams to identify the most relevant issues to address, and also provide context for the developer who would eventually need to fix them.
During our research, we used the common vulnerability lists mentioned above, and CVE data sources such as CVE Details as a reference when tagging our data collection. CVE Details is an example of a known CVE database which adds tags to vulnerabilities with common categories that often can be found in CWE top 25 vulnerabilities, such as: cross-site scripting, overflow and SQL injection.
When we look into our CVE data collection, we see that code execution, uncontrolled memory manipulation and injection, are among the most discovered vulnerabilities.
This category drill-down helps identify the most common security risks that were mentioned both in OWASP top 10 and CWE top 25, for example:
Looking at the exploited CVEs, it is no surprise to see injection listed as the most exploitable category, with 20% out of injection-type vulnerabilities that have exploit attachment.
Since injection vulnerability is considered a generic, rather than specific, issue type, it can be linked to directory traversal and code execution vulnerabilities. This can suggest that the rise in the number of CVE and the proportion of exploited CVEs tagged as injection is caused by the association with other types of vulnerabilities that can be attributed to injection.
In addition, code execution and memory manipulations are considered more difficult to discover than client/server injections based. The rise in injection exploits may indicate that the shift to cloud-native environments contributes to the elevation of lower severity issues such as a blind SSRF in a cloud environment, to exploited remote code execution with critical severity. Cloud platforms offer thorough documentation for handling resources, but this can also be a double-edged sword. Attackers can use this information to their advantage, as misconfigurations and other weaknesses may be easier to exploit.
Continuing with the exploited CVEs, we examined vulnerabilities created between 2019 to 2022, as this is a significant period of time in recent security trends covered by vulnerability and risk lists such as OWASP and CWE-25.
Cross-site scripting is considered one of the most relevant weaknesses according to CWE-25. While the overall ratio of exploited CVEs for the XSS category is relatively low - at only 4% as mentioned above, the number of exploited CVEs has become more significant in recent years. However, it is surprising to see that almost all of the exploited CVEs related to this category are considered of low and medium severity.
We should note that in terms of risk, XSS is a client attack, concentrating on browsers of users. While it can have a major effect for users, it is, in most cases, a limited attack. Server attacks have greater potential to access multiple cross-users data and capabilities which usually increase severity of server attacks.
Get More Value Out of Your Issues Data
It is worth mentioning that by following vulnerability lists alone and focusing on specific categories, researchers may be incentivized to mostly target vulnerabilities within those categories.This approach may contribute to the abundance of issues that AppSec researchers identify and teams need to track and remediate. This may also result in a false sense of security, as organizations may assume that by addressing the vulnerabilities on the list, they have effectively secured their applications, which might not be the case.
Nevertheless, vulnerability lists are valuable resources for identifying overall common and critical security issues, as well as providing guidance on how to remediate vulnerabilities.
From a data driven perspective, we suggest using issue metadata for building an internal category tagging system for security issues. By doing so, organizations can gain a better understanding of the types of security issues they are facing and where they need to focus their efforts. This can help prioritize remediation efforts and improve overall security coverage, and eventually ensure better management of the organization’s security posture with a more effective response to threats and vulnerabilities.
In the next and final blog post we will cover the differences between SAST and SCA tools in different categories.
Alina Nikitin is a Data Analyst at Enso Security, the first Application Security Posture Management (ASPM) tool used daily by AppSec teams to enforce, manage and scale a robust AppSec program, all without interfering with development. Questions and suggestions are welcome! Please reach out to Alina at email@example.com to get in touch.