Big CodeLearning from open source
In our Machine Learning (
ML) for secure code
series the mantra has always been the same:
to figure out how to leverage the power of
ML to detect security
vulnerabilities in source code, regardless of the
technique, be it deep
learning, graph mining,
natural language processing, or anomaly
In this article we present a new player in the field,
DeepCode, a system that has exactly this
ML with data flow analysis, namely in the form of
Taint analysis can come in dynamic and static forms and can be performed at the source and binary levels, but either way, the goal is the same. Start by looking at where input comes from and is controlled by the user, for example, a web app search field. These are named sources in this context. Then, continue to follow the thread to where it gets used by the system in a security-critical fashion, as in using that info to query a database, to continue with the previous example. These points are called sinks.
Figure 1. Taint analysis diagram via Coseinc.
Along the way in the case of a secure application, data should encounter significant input sanitization or validation. These are called sanitizers in the taint analysis context. However, frequently this does not happen, and thus vulnerabilities arise.
DeepCode’s purpose is to remove minor difficulties these taint
analysis tools may have.
DeepCode does this by learning from the vast
quantity of freely-available, high-quality code in open repositories
such as Github, a circumstance then dubbed "Big
Code". The tool is easy and free to use. This provides the added
advantage of also learning from the user’s code, the suggestions made by
the tool, and the user’s feedback (accepting suggestions, how to fix
Another problem with taint analysis is that sources, sinks, and
sanitizers need to be specified by hand, which is extremely impractical
for large-scale projects. This is another area where
DeepCode, but how is that done?
DeepCode has been called Grammarly for
code. It claims to be 90% accurate, and that it understands the intent
behind the code. It also claims to find twice as many issues as other
tools, even some critical ones (
SQL injection and path
traversal, etc.) which is something typical static analysis tools do
not. Moreover, it claims to be easy to use, requiring no configuration.
The tool is friendly. You need only point it to your repository and give the appropriate permissions, and then it will show a dashboard with the issues found. Here is one for Eclipse Che Cloud IDE:
Figure 2. Security issues dashboard for Eclipse Che, adapted from DeepCode demo.
Here we see three instances of a possible path traversal vulnerability.
In the full dashboard, we also see how they report an insecure
channel, a Server Side Request Forgery (
SSRF), a Cross Site Scripting
XSS) vulnerability, and a header that leaks technical information
X-Powered-By). And that’s only the issues tagged as "security". There
API misuse issues, v.g. using
Thread.run() instead of
Thread.start(), general bugs or defects, and now they even throw lint
tools results, which deal with formatting and presentation issues. Oh,
yes, and every issue comes with a possible fix you might implement right
Quite nice, from the point of view of contributing a new vulnerability report to a project, with no false positives. However when the aim is to find all vulnerabilities, one cannot help but raise the question: is that all? Are these all the security vulnerabilities in a project with more than 300,000 lines of code?
Let us take one of the many Vulnerable by Design (
VbD) applications we
use for training purposes in our challenges
site, and see
how many vulnerabilities come up by running
DeepCode on them. By the
way, they currently support
besides the original
Python. That leaves us with two apps to try: the
DVNA) and Damn Small Vulnerable
DSVW), since most
are built with
I forked both of these on
Github, signed up for a
and let it run. For
DSVW, which is a single
Python file under 100
lines of code, but still ridden with vulnerabilities,
zero issues. Perhaps it does not work as well on such tiny projects.
Figure 3. Zero issues in DSVW.
This is, to say the least, disappointing, since that
DSVW has no less
than 26 different kinds of vulnerabilities, as per its
three of those have been manually explored and exploited.
Maybe it’s a problem with having so few lines of code, maybe it’s a
Python thing, so let’s try the other one:
DVNA, built with
with the specific purpose of demonstrating the
OWASP Top 10
This time around,
DeepCode found 9 issues. Of those, take out the 3
which come from
ESLint, and let’s consider the other 6; 2 are
misuses, which are basically "use arrows instead of functions" and 4 are
security vulnerabilities, and pretty serious ones at that:
Code Injection via
evalfunction in calculator module. Not the same one as in the authors' security guide. Also not yet reported in Writeups This should be researched further.
Technical information leakage via the
X-Powered-Byheader, as in
So, altogether, 3 noteworthy security vulnerabilities, in a
application with more than 7,500 lines of code. In
Writeups, at least 29
different vulnerabilities have been reported in
DVNA. You can see a
on manual testing vs the
LGTM code-as-data tool in
there, too, where it is quite clear that tool misses most of the
vulnerabilities as well.
Now for a more realistic test, let’s try running
DeepCode on some of
our own repos, namely, Integrates, our platform for vulnerability
centralization and management and
asserts, our vulnerability
automation framework. Both are
open-source, written in
actively developed. As before, the vast majority of issues found by
DeepCode are of the
API usage kind.
Figure 4. Integrates Dashboard
Integrates we see a possible command injection in the spreadsheet
report generation function. However, this input is not controllable by
the user, so this does not pose a real threat at the moment:
Command Injection in Integrates?.
However, the suggestion to sanitize the input via
not bad. Who knows if
Integrates will later have user-configurable
passwords for reports, or a different vulnerability enables an
attacker to change this parameter.
The other security issue is in the
Path traversal. Again, probably difficult to exploit,
but should be sanitized anyway.
Asserts, however, the 15
issues found by
DeepCode are less worrisome, for two reasons:
Assertsis not a client-server application, but an
APIthat runs locally.
Of course, all the issues detected by
DeepCode will be taken care of.
Once again, this confirms our other mantra we have held in this
Machine Learning (
ML) series and also
website. While automated tools, even
ML-powered ones, may have the potential to do what a human could not
do in terms of repetitions and scalability, as of yet, they do not have
the malice or creativity which humans have in finding critical and
interesting security vulnerabilities.
V. Raychev. 2018. DeepCode releases the first practical anomaly bug detector.
V. Chibotaru. 2019. Meet the tool that automatically infers security vulnerabilities in Python code. Hackernoon