Big Code

Learning from open source

Blog Big Code

| 5 min read

Table of contents

Contact us

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 detection.

In this article we present a new player in the field, DeepCode, a system that has exactly this purpose, combining ML with data flow analysis, namely in the form of taint analysis.

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.

Taint analysis diagram

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.

Traditional taint analysis tools, however, usually present high false positive rates, as is the case with Bandit and Pyt (see some critique here).

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 them, etc).

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 ML helps 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 (XSS, 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:

Dashboard for Eclipse Che

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 HTTPS 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 are also API misuse issues, v.g. using 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 away.

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 Javascript, TypeScript and Java, besides the original Python. That leaves us with two apps to try: the Damn Vulnerable NodeJS Application (DVNA) and Damn Small Vulnerable Web (DSVW), since most VbD apps are built with PHP.

Get started with Fluid Attacks' Secure Code Review solution right now

I forked both of these on Github, signed up for a DeepCode account, and let it run. For DSVW, which is a single Python file under 100 lines of code, but still ridden with vulnerabilities, DeepCode reports zero issues. Perhaps it does not work as well on such tiny projects.

Dashboard for DSVW

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 README. In Writeups, 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 NodeJS with the specific purpose of demonstrating the OWASP Top 10 vulnerabilities.

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 API misuses, which are basically "use arrows instead of functions" and 4 are security vulnerabilities, and pretty serious ones at that:

  • Code Injection via eval function in calculator module. Not the same one as in the authors' security guide. Also not yet reported in Writeups This should be researched further.

  • SQL injection. As per security guide and Writeups.

  • Open Redirect. Also in the security guide and Writeups.

  • Technical information leakage via the X-Powered-By header, as in Che.

So, altogether, 3 noteworthy security vulnerabilities, in a NodeJS 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 report 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 Python, and actively developed. As before, the vast majority of issues found by DeepCode are of the lint and API usage kind.

Integrates Dashboard

Integrates Dashboard.

In Integrates, the platform that our clients use for vulnerability management, 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?.

Command Injection in Integrates?

However, the suggestion to sanitize the input via is 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 PDF report generation, this time identified as Path traversal. Again, probably difficult to exploit, but should be sanitized anyway.

Asserts Dashboard

In Asserts, however, the 15 issues found by DeepCode are less worrisome, for two reasons:

  • Asserts is not a client-server application, but an API that runs locally.

  • Most of the 15 issues are several instances of SSRF, when Asserts makes HTTP requests via Requests, generally to client’s ToEs as one would in a browser.

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 elsewhere on our 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.


  1. V. Chibotaru. 2019. Meet the tool that automatically infers security vulnerabilities in Python code. Hackernoon

Table of contents


Subscribe to our blog

Sign up for Fluid Attacks' weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by Claudio Schwarz on Unsplash

Is your financial service as secure as you think?

Photo by Brian Kelly on Unsplash

We need you, but we can't give you any money

Photo by Valery Fedotov on Unsplash

A digital infrastructure issue that many still ignore

Photo by Mike Lewinski on Unsplash

It's about time you relied on code-assisted pentesting

Photo by Pawel Czerwinski on Unsplash

Attackers can indirectly instruct AI for malicious aims

Photo by Ray Hennessy on Unsplash

Let's rather say a bunch of breaches in a single box

Photo by Fervent Jant on Unsplash

NIST sheds light on the classification of attacks on AI

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.