Future Research Opportunities

In this section, we discuss some opportunities for future work on using SVDBs to support SE tasks.

Using SVDBs beyond just being information silos. Our results show that a majority of SE

researchers use SVDBs to gain security related knowledge. In fact, developers already use SVDBs to identify security vulnerabilities and determine features (e.g., vulnerability patch information) that they want to implement. Presently, the role of SVDBs is mostly as a repository for reporting known security vulnerabilities. However, we envision that future versions of SVDBs will play an increasing role as an integrated knowledge source for guiding secure software development, providing security testing, and refining software security design. Hence, we believe that future versions of SVDBs need to incorporate a mechanism through which SE researchers can link and trace vulnerability information directly across knowledge resources.

Another interesting finding is that SE researchers reuse vulnerability information usually only from one source (single SVDB), thus limiting their analysis approach to the data available

in this SVDB. One approach to address this problem is to improve the accessibility of information across SVDBs boundaries. Providing users with standardized access to these knowledge resources, where queries will retrieve information across SVDBs boundaries, will represent a first step to performing new types of vulnerability analyses (e.g., global security impact). While linking these knowledge resources is an important initial step, additional semantic modelling will be needed to ensure the consistency and quality of knowledge across SVDBs boundaries. For example, threats to consistency and ambiguity across these knowledge resources will have to be addressed to ensure that a vulnerability reported in two databases is actually the same (or different) instance. One approach would be to replace current proprietary knowledge modelling approaches used by SVDB providers and agree upon a standardized knowledge modelling approach, which would include the ability to semantically link query SVDBs across the repository boundaries and to provide each vulnerability with a global, unique identifier, similar to the Universal Resource Identifier used by the SW.

Linking Security Commit Changes to SVDBs. With more widespread use of SVDBs in software

development, we believe that SVDBs should become an integrated part of current software development processes and best practices. Similar to the current practice of adding an issue number to a commit message, a commit message also should include a link to the vulnerability in the SVDB where it is reported. Such vulnerability traceability can provide additional insights and documentation to QA45 _{and future maintainers when analyzing and comprehending the code}

patch. Furthermore, a bi-directional link from the vulnerabilities to the known and patched code would be desirable. We further believe that next generation IDEs should not only facilitate this linking process, but also take advantage of these links to recommend patches or identify potential impacts of these vulnerabilities on other parts of the system.

Vulnerability scanner tools using SVDBs. The existing vulnerability detection tools provide too

much detail about the vulnerability issue and these details, sometimes, are unnecessary to the regular developer which affects the vulnerability comprehension. We do not see this as something that can be enforced, but at least guidelines can be developed to help regular developers achieve vulnerability patches easily.

The unified model for the public SVDBs (suggested above) can be used to enhance the vulnerability scanner tools to reduce false positive and negative results. Thereby, we suggest the following list of tool features that encourage future tools or solutions design to be considered:

 Support at least the following tasks: tracing the same vulnerability from different SVDBs, summarized report about the vulnerability and its impacts, provide patch information if it exists, automatically deploy the patch to the vulnerable project if needed, vulnerability dependencies and its global impact (find relevant libraries that might be affected with the same vulnerability).

 Given a piece of code that introduces the vulnerability, identify any internal or external calls for this vulnerable code.

3.8 Chapter Summary

While the SE research community is increasingly focusing on security and reliability, no comprehensive literature survey exists that studies how SVDBs are used and integrated in the SE life cycle. Knowing how researchers use SVDBs may also help future studies improve software security. In this study, we surveyed 94 articles from the SE literature that used SVDBs. We found that:

 there is an increasing awareness of SVDBs in the research community in terms of papers being published describing the use and application of SVDBs in the SE domain;

 the majority of the surveyed studies applied SVDBs only to a limited number of SE activities;

 most studies relied on only one SVDB for their contribution.

We have also discussed potential directions for future work on using SVDBs for different SE tasks, which also were the motivation for our research presented in Chapters 4–7 of this thesis.

In the next chapter, we discuss in more detail the knowledge engineering process we applied to create a unified ontological representation for SVDBs, which forms the basis for a more seamless integration of SVDBs into existing SE development tasks.

Chapter 4

4 A Unified Ontology-based Modeling