TL;DR overview
- Deeper SAST detects deeply hidden security vulnerabilities that arise from interactions between first-party code and third-party open-source libraries—a blind spot for traditional SAST tools that treat dependencies as black boxes.
- A real-world Jenkins path traversal vulnerability (reported by Sonar researchers) demonstrates why deeper SAST is necessary: neither Jenkins code nor the args4j library alone contained the vulnerability; only analyzing both in combination revealed the security flaw.
- On average, for every 10 regular vulnerabilities found in a code project, Sonar's deeper SAST detects one additional deeply hidden vulnerability by tracking data flows across library boundaries without requiring extra configuration.
- Deeper SAST is available in SonarQube Cloud and commercial editions of SonarQube Server for Java, C#, and JavaScript/TypeScript, with coverage expanding to additional languages and libraries over time.
Last year, Sonar announced its innovative analysis technology, deeper SAST, for detecting deeply hidden code vulnerabilities at the BlackHat security conference. Since then, we have continued to refine and expand this technology with the goal of discovering even more vulnerabilities with high accuracy so that your code stays clean.
At the same time, we have been evaluating and monitoring the impact of analyzing open-source software with deeper SAST. In this blog post, we would like to highlight why deeper SAST is essential for finding hidden vulnerabilities that otherwise remain undetected by showcasing a critical real-world vulnerability example that impacted the world.
What is deeper SAST?
Nearly every software has multiple dependencies, such as the Spring framework or the Log4j library. However, traditional Static Application Security Testing (SAST) tools only analyze a project's first-party code, neglecting the code within third-party dependencies. These dependencies are black boxes for traditional SAST but often contain sensitive pieces of code that can lead to security vulnerabilities when used incorrectly in your project. As a result, traditional SAST misses hidden vulnerabilities that stem from the unique interaction with third-party code in your project's first-party code.
These sensitive code pieces in dependencies only become vulnerabilities when they are misused in your project. They are not vulnerabilities by themselves, and they are not classified and documented with a CVE. Hence, traditional SCA tools cannot detect these vulnerabilities.
Left side (red): Traditional vulnerability using only first-party code; Right side (purple): Hidden vulnerability connecting first-party code and third-party code.
Deeper SAST addresses this gap by extending its taint analysis to cover the interaction of first-party code with the dependencies used in your project. This enables our technology to have unique insights into the security side effects of dependent code. Deeper SAST evaluates all security-sensitive interactions between your project's code and its dependent code without any additional configuration or major performance overhead. This allows Sonar to find vulnerabilities in your project that traditional SAST and SCA tools miss. You can learn more about how our deeper SAST technology works behind the scenes in this blog post.
Jenkins Security Vulnerability CVE-2024-23897
Now, what kind of hidden code vulnerabilities can deeper SAST find? Let's look at a real-world example. Last year, our researchers reported a critical vulnerability in the code of Jenkins, one of the most popular CI/CD software used by over 10 million developers. We will examine the individual code pieces involved in this vulnerability and explain why only deeper SAST is able to connect the dots.
The vulnerability affected the built-in CLI tool of Jenkins which is used to manage a Jenkins server remotely. To parse command line arguments for this CLI tool, Jenkins imports a small third-party library called args4j. Within this args4j library, there is a hidden feature during argument parsing: When arguments start with an "@" character, they are opened and read as files. Ultimately, this feature can be abused by remote attackers when passing malicious arguments to Jenkins to steal sensitive files. You can find out more about the details of this vulnerability in our technical blog post.
The key point is that when analyzing only the code of Jenkins, no vulnerability can be found because the security-sensitive part of opening files is performed in the library code. By analyzing only the code of args4j, no vulnerability can be found either because opening files alone are harmless. There is only a security problem when a malicious user can tamper with the file path. It is up to the developer to use this library securely, and there is no entry in the CVE database.
Only deeper SAST can analyze the specific interaction between the first-party code (Jenkins) and the third-party code (args4j), determine it's insecure, and raise a security vulnerability.
Open vulnerability finding on SonarQube Cloud
The Jenkins maintainers quickly fixed this issue after our report and released patch versions 2.442 and LTS 2.426.3. They rated the vulnerability as critical, with a score of 9.8 in the Common Vulnerability Scoring System (CVSS).
The impact of a single, deeply hidden critical vulnerability
This vulnerability in Jenkins is only one example of code interactions that can be obscure and difficult for a developer to review, especially when many transitive dependencies are used. Yet, a single code vulnerability ending up in production can have a tremendous impact on your software and business. The following video demonstrates how attackers can exploit this hidden vulnerability to steal sensitive files and potentially take over the Jenkins server.
Due to the popularity of Jenkins, the public was warned by multiple media sites1,2,3,4,5 and governments1,2,3.
DarkReading wrote that "One reason for the concern is the fact that DevOps tools such as Jenkins can often contain critical and sensitive data that developers might bring in from production environments when building or developing new applications. A case in point occurred last year when a security researcher found a document containing 1.5 million individuals on the TSA's no-fly list sitting unprotected on a Jenkins server, belonging to Ohio-based CommuteAir."
TechRadar reported in January that "there are roughly 45,000 unpatched Jenkins servers that could be potential targets. The majority of these endpoints are located in China (12,000), followed by the United States (11,830), Germany (3,060), India (2,681), France (1,431), and the UK (1,029)". BleepingComputer added that "Researchers report that their Jenkins honeypots have already caught activity in the wild, suggesting that hackers have started exploiting the vulnerabilities". These ongoing attacks were later confirmed by a report by TrendMicro.
Conclusion
Deeper SAST is indispensable for finding deeply hidden vulnerabilities and writing Code Quality. We demonstrated the importance of deeper SAST with a single vulnerability example. A single vulnerability can have drastic consequences. Sonar uncovers hundreds of new deeply hidden security vulnerabilities every day.
Deeper SAST functionality is available to Sonar's commercial customers at no extra cost. You can experience it firsthand with SonarQube Cloud, our cloud-based solution, or with self-managed SonarQube Server Developer Edition or above (version 9.9 LTS or later).
Try deeper SAST for free on your project or using our demo repository.
Further reading
- Press release: Sonar's Powerful Deep-Analysis Finds Hidden Security Issues in Code
- Website: Security starts with Code Quality - the benefits of deeper SAST
- Technical blog post: Behind the scenes of deeper SAST
- Technical blog post: Critical security vulnerability in Jenkins
- Finding on SonarQube Cloud: Jenkins Path Traversal vulnerability
