MAXIMAL DIVERGENCE SEQUENTIAL AUTO- ENCODER FOR BINARY SOFTWARE VULNERABILITY DETECTION *
Due to the sharp increase in the severity of the threat imposed by software vulnerabilities, the detection of vulnerabilities in binary code has become an important concern in the software industry, such as the embedded systems industry, and in the field of computer security. However, most of the works in binary code vulnerability detection has relied on handcrafted features which are manually chosen by a select few domain experts. In this paper, we attempt to alleviate this severe binary vulnerability detection bottleneck by leveraging recent advances in deep learning representations and propose the Maximal Divergence Sequential Auto-Encoder. In particular, latent codes representing vulnerable and non-vulnerable binaries are encouraged to be maximally divergent, while still being able to maintain crucial information from the original binaries. We conducted extensive experiments to compare and contrast our proposed methods with the baselines, and the results indicate that our proposed methods outperform the baselines in all performance measures of interest.
This paper sets out to classify source code snippets are “vulnerable” or “not vulnerable” using sequential auto-encoders with two latent distributions (corresponding to the output classes), regularized to maximize divergence between theses two distributions (named Maximal Divergence Sequential Auto-Encoder).  The authors created a compiled subset of the NDSS18 vulnerable vs. non-vulnerable software dataset (which is listed as one of their primary contributions). The dataset construction required non-trivial effort since example code snippets are often incomplete and the authors needed to “fix” these code examples in order to compile them. The fixed code examples are then compiled against both Windows and Linux and both the x86 and x86-64 architectures. The inputs to all predictive models are the opcode sequence of the compiled programs. 
This paper compares against one previously published vulnerability detection method (VulDeePecker) which is a bidirectional RNN followed by a linear classifier. They also compare with a cascade of models with increasingly complex components:
* RNN-R: A recurrent neural network trained in an unsupervised fashion (language modeling over opcode sequences), whose representations are then fed into an independent linear model. 
* RNN-C: End-to-end training of a recurrent model over opcodes, followed by a single dense layer.
* Para2Vec: Encoding of the opcode sequence using the paragraph-to-vector architecture — I’m curious what they used as the paragraph boundaries in the compiled programs and whether the subsequent classifier was the same as RNN-C. 
* SeqVAE-C: Sequential variational auto encoder trained end-to-end with a final classification layer. 
* MDSAE-RKL:  Maximal divergence sequential auto-encoder with KL divergence between the two class’s latent distributions, final classifier trained independently. 
* MDSAE-RWS: Maximal divergence sequential auto-encoder with L2/Wasserstein  divergence between the two class’s latent distributions, final classifier trained independently. 
* MDSAE-CKL: Maximal divergence sequential auto-encoder with KL divergence between the two class’s latent distributions, final classifier included as the final layer of the whole model.
* MDSAE-CWS: Maximal divergence sequential auto-encoder with L2/Wasserstein  divergence between the two class’s latent distributions, final classifier included as the final layer of the whole model.
The two MDSAE models using Wasserstein divergence vastly outperform the two equivalent models using KL divergence. Another generalization that can be drawn from the evaluation is that models which are trained  with supervision end-to-end outperform those which train representation and classifier separately. 
Overall, I think this is an interesting and cool paper but I’m not sure I actually buy into the basic premise that it makes sense to model vulnerable vs. non-vulnerable code as two different latent spaces. Aren’t the changes to make a vulnerable function safe again rather small and/or subtle? I think that beyond visualizing the convergence of properties of the latent spaces it would greatly improve this paper to inspect which aspects of the source contribute to both the latent representation and final classification as vulnerable vs. non-vulnerable. 
Also, I wish the process of “fix”ing the input code was better described, since the failure of this procedure excluded 4k/13k of the programs/functions in their initial dataset and had the potential to introduces learnable biases in the source code. At the very least, the authors should list how many vulnerable vs. non-vulnerable samples required fixing vs. could be compiled in their original form. 
Lastly, the definition of "vulnerable" may be obvious to someone more familiar with the domain but seemed to me somewhat vague and never directly addressed. 
Typo:
p3, need space in "obtain32, 281"