Cutting down on false positives with vulnerable methods for Ruby
Today we released vulnerable methods support for the Ruby language, adding to the existing support for Java and Python. Vulnerable methods analysis uses call-graph analysis to trace the actual use of the vulnerability in your projects. To understand the impact that vulnerable method support can have, we analyzed the top 1,000 starred Ruby projects on GitHub, and discovered that without vulnerable method detection, users would see a false-positive state of more than 85%! With vulnerable methods detection, users would see these false-positive rates decrease significantly. To get this feature, paid users can simply update their agents (i.e. brew upgrade srcclr) and free users can upgrade to a Pro trial.
What are vulnerable methods?
A vulnerable method of a library is a method through which a given vulnerability can be exploited. For each vulnerability in our database, our researchers:
-
Analyze the vulnerability report and identify the root cause. This allows us to determine what methods are affected by the vulnerability, and the vulnerable methods.
-
Our platform automatically analyzes every release of every library and determines public methods that call the vulnerable methods.
-
When you scan a project we build a call-graph for the project and check if it calls the public vulnerable methods of the library.
To demonstrate how this looks in action, let's scan a Ruby project :
As you can see above, there is a call chain from the project code to the vulnerable method of two libraries that are used in the project. The SourceClear platform provides a full call chain which can be used to fully understand the control flow. If you would like to know more about how we generate call graphs, then you can read our previous post.
With vulnerable methods scanning you get more accurate information about the impact a vulnerability has on your application. If you are not calling the vulnerable parts of the library then you are not affected by the vulnerability, reducing the false positives rate in analysis significantly. To get a better picture on how vulnerable method detection helps reduce false positives, we analyzed the top 1,000 starred open-source Ruby projects on GitHub.
In order to build a call graph the project must build and scan: 860 out of 1,000 completed successfully from the master branch.
| Total Scanned | Libraries/Project | Direct | Transitive | Vulnerable |
|---|---|---|---|---|
| 860 | 54 | 20% | 80% | 4% |
From the statistics you can see that, on average, a Ruby project had 54 libraries-out of which 4% have vulnerabilities. Do note that about 20% of libraries are included directly while the majority (80%) are included transitively.
| Vulnerable Libraries/Project | Public CVEs | Premium | Vulnerable Methods |
|---|---|---|---|
| 2 | 40% | 60% | 15% |
On average, a Ruby project has about two vulnerable libraries. 40% of these vulnerabilities are from public CVEs; on the other hand, 60% of them are detected based on premium SourceClear data not available anywhere else. Moreover, in only 15% of the cases are the vulnerable methods called by the application. In other words, in 85% of the cases where a vulnerable library is used, there is no call chain to the vulnerable methods and it is therefore, a false positive.
False positives are the enemy of developer friendly security. Modern continuous delivery and vulnerable methods detection are becoming a must-have feature in open-source testing.
Check it out
You can scan this example repository to see vulnerable method detection for Ruby in action:
srcclr scan --url https://github.com/srcclr/example-ruby
Related Posts
