Data Security Drop Vol.11 - Defects in our AppSec Methods

As the Security community sits on the edge of their seats awaiting the next Third Party Software Component (TPSC) Zero Day to make headlines, there is something more critical that continues to impact the Application Security community.? The constant scrutiny of compliance driven “Application Security” checks boxes due to the lack of resourcing at the National Vulnerability Database (NVD), coupled with knowledge gaps of what Software Composition Analysis (SCA) results really mean.?

You are probably wondering about Software Composition Analysis (SCA).? Well, SCA is a Application Security “AppSec” methodology, leveraged by development and security teams to understand the contents of TPSCs being pulled into their code base, software supply chain impacts, and vulnerabilities. Some of the insights that SCA provides are foundational to securing our software, however the way SCA tooling identifies vulnerabilities today can cause more harm than good (or at least the way security and compliance teams infer the results).?

Value of SCA Tooling

SCA plays a pivotal role in providing invaluable insights into your code base. SCA generates a Software Bill of Material (SBOM) that not only identifies TPSCs, but also sheds light on their licensing types. This is crucial for maintaining a pristine software supply chain that complies with contractual agreements and terms of service.

SCA is the foundation for the future of application security. As this effectively reduces risks within the software supply chain. A significant byproduct of SCA and SBOM is the emergence of the Vulnerability Exploitability Exchange (VEX). VEX aims to deliver a comprehensive analysis of vulnerability exploitability, complemented by the SBOM, thereby serving as a trusted guide in assessing and mitigating third-party software supply chain risks.

The Issue…?

SCA's reliance on high-level vulnerability databases, like the National Vulnerability Database (NVD), which employs simplified scoring methodologies such as the Common Vulnerability Scoring System (CVSS) and Common Vulnerabilities and Exposures (CVE), may give the impression that these databases are the primary issue. However, the main problem lies in the (lack of) context in which the information from NVD is applied. It is crucial to recognize that while improving the databases is undoubtedly important, addressing the broader context in which NVD contents are interpreted and acted upon should take precedence.

NVD was established with good intentions: to serve as a comprehensive repository of all publicly known vulnerabilities. In essence, NVD plays a crucial role in today's Security community. However, it faces significant challenges due to inadequate funding, which hinders its ability to employ a sufficient number of researchers to keep pace with the continuous influx of newly discovered vulnerabilities. As a result, their databases often contain more noise than genuinely impactful vulnerabilities.

It's important to emphasize that NVD remains essential for the risk reduction efforts of all organizations. Nevertheless, the trustworthiness of NVD or CVE risk scoring has been somewhat compromised, particularly in light of buzz word “zero-days”, public sector policies, and every security company trying to show how important the research they are working on is. Due to the nature of how SCA tools function, scanning code repositories and essentially searching for matches with CVE definition has caused friction in the AppSec Community.

1. Example: a Node.js package contains a CVE 2023-12345 (fake CVE) that is deemed ‘critical’ without ever taking into account if that function is ever called or if it’s even exploitable within the specific environment. ? As we all know, vulnerabilities present risk to an organization and need to be quantified, however we seem to be missing our simple risk calculation = likelihood x impact.?
2. An SCA tool scans a node.js library, finds a plethora of vulnerabilities, some rated as “Crititical CVEs” (at least according to our trusty scoring methodologies)?
3. Prints out a report that this software has 25 Critical, 15 high, 40 Medium, and 23 low vulnerabilities! Just like that with no actual analysis.??

While you may think this is great to have this insight, however this report is then being used by software consumers (organizations) and internal stakeholders to hold development and AppSec teams accountable to do vulnerability patching and comply with Service Level Agreements (SLAs), even though if you thoroughly investigate the identified vulnerabilities they are probably not exploitable thus presenting 0 risk.??

According to BigIDs, Application Security Leader, Diogo Raposo, “As an example, In a microservice setup where one microservice manages all system interactions through its API, it's not possible to exploit a CVE that affects a package on another microservice where an exploitation of such a vulnerability would require a specific trigger, like a specially crafted payload or a command-line interaction.”? This continues to be a commonality across the Application Security landscape. Depending on the research you read on TPSC vulnerabilities approximately 70-90% of CVEs identified are not actually exploitable.? Raposo says, “Exploitability is obviously dependent on safe APIs and infrastructure security.”

The Impact on the Software Companies and Software Buyers

I advocate for a strategic approach to reducing risks associated with third-party software vendors, with a specific emphasis on vulnerability exploitability. Simply checking a box to claim that you've reviewed third-party software for vulnerabilities using SCA tools isn't sufficient. In fact, it can lead to a stagnant deployment process and hinder the time-to-value of the software you've acquired.

Every moment your development teams are diverted from addressing bugs or customer requests represents a loss in product velocity. Similarly, when Application Security teams are consumed with writing advisories explaining why a CVE isn't exploitable, valuable time that could be better spent on threat modeling or dynamic analysis/pentesting is squandered. In this scenario, the pursuit of risk reduction is compromised, and it's essential to reevaluate our approach.

Both SCA and SBOM offer substantial value by enhancing software security and transparency. When properly leveraged, they can help organizations mitigate vulnerabilities, streamline compliance, and build trust with stakeholders. However, it's essential to recognize that while SCA and SBOM provide significant value, the ultimate game-changer in software development and security could be VEX. By prioritizing the most exploitable vulnerabilities, VEX promises to revolutionize how organizations allocate resources and focus on addressing critical security issues, making it potentially the most valuable asset in the cybersecurity toolkit.