Ashwin Kallingal Joshy

Ashwin Kallingal Joshy, Mirza Sanjida Alam, Shaila Sharmin et al.

Deep learning vulnerability detection tools are increasing in popularity and have been shown to be effective. These tools rely on large volume of high quality training data, which are very hard to get. Most of the currently available datasets provide function-level labels, reporting whether a function is vulnerable or not vulnerable. However, for a vulnerability detection to be useful, we need to also know the lines that are relevant to the vulnerability. This paper makes efforts towards developing systematic tools and proposes. ActiveClean to generate the large volume of line-level vulnerability data from commits. That is, in addition to function-level labels, it also reports which lines in the function are likely responsible for vulnerability detection. In the past, static analysis has been applied to clean commits to generate line-level data. Our approach based on active learning, which is easy to use and scalable, provide a complementary approach to static analysis. We designed semantic and syntactic properties from commit lines and use them to train the model. We evaluated our approach on both Java and C datasets processing more than 4.3K commits and 119K commit lines. AcitveClean achieved an F1 score between 70-74. Further, we also show that active learning is effective by using just 400 training data to reach F1 score of 70.23. Using ActiveClean, we generate the line-level labels for the entire FFMpeg project in the Devign dataset, including 5K functions, and also detected incorrect function-level labels. We demonstrated that using our cleaned data, LineVul, a SOTA line-level vulnerability detection tool, detected 70 more vulnerable lines and 18 more vulnerable functions, and improved Top 10 accuracy from 66% to 73%.

Ashwin Kallingal Joshy, Wei Le

Software development is inherently incremental. Nowadays, many software companies adopt an agile process and a shorter release cycle, where software needs to be delivered faster with quality assurances. On the other hand, the majority of existing program analysis tools still target single versions of programs and are slow and inflexible to handle changes. In the popular version control systems such as git, the program changes are still presented using source code diffs. It is hard to understand what program conditions are changed and which source code lines cause them. In this paper, we propose to compute "invariant diffs" to specify changes. Similar to source diffs that report common code and code churns, we define version invariants to represent program conditions that are common across versions, and invariant churns to show the changes of program conditions between versions. We designed a static demand-driven, path-sensitive analysis to compute and compare invariants for multiple versions of programs using multiversion control flow graphs. We report invariant diffs at the matched program points where comparing invariants are meaningful. Importantly, our analysis correlates source diffs with invariant diffs to explain what source code changes lead to the property changes. We implemented our algorithms in a tool called $H_2$ and performed experiments on 104 versions of programs. Our results show that we are able to compute invariant diffs correctly within reasonable amount of time. The version invariants can capture the common properties of program versions even constructed by different persons, and the invariant churns can specify the semantics of changes such as how a patch changed a buggy condition to a correct condition.