Article Preview
Top1. Introduction
Software design and development is an error-prone process, which inadvertently introduces a number of weaknesses that can later be exploited for malicious purposes. A weakness is the result of a flaw that creates pre-conditions necessary for the introduction of vulnerabilities within that software. Weaknesses in software present opportunities for malicious attacks that compromise the security policy expectations. Common sources of weaknesses are validation errors, domain errors, and serialization/aliasing errors (Landwehr et al., 1994). Vulnerabilities and weaknesses are related but different, i.e. only exploitable (or already exploited) weaknesses can be considered as vulnerabilities. Weaknesses might stay in software but never cause any problems if they remain un-exploitable by an attacker. In this work we focus on annotating reports that document exploitable and publicly known vulnerabilities with corresponding standard weakness definitions. Several vulnerability reports in widely used software packages are cross-referenced from the National Vulnerability Database (NVD) (NIST, 2012) that maintains the Common Vulnerabilities and Exposures (CVE) list (MITRE, 2011b).
Most software development projects have some processes, tools and techniques to document and track reported vulnerabilities. This information is recorded in existing project repositories such as change logs in version control systems, entries in bug tracking systems and communication threads in mailing lists. As these repositories were created for different purposes, it is not straightforward to extract useful vulnerability-related information. In large projects, these repositories store vast amounts of data, and as a result, the relevant information is buried in a mass of irrelevant data. Natural language text descriptions and discussions do not facilitate mechanisms to aggregate vulnerability artifacts from multiple sources or pinpoint the actual software fault and affected software elements.
Two key problems exist: information overload of vulnerability information in software repositories and, paradoxically, lack of techniques to systematically annotate and analyze this data. The large volume of data in software repositories and other project information sources make it difficult to locate the artifacts needed to identify, track and study previously recorded vulnerabilities. This condition is compounded by the fact that the complete record of information is scattered over several separate systems with different information schemas and natural language descriptions. Even if the information is found, a significant amount of work is needed to reconstruct the trail of artifacts that help understand the actual vulnerability. Thus, the information within software project repositories is not in a representation that can be easily extracted and analyzed for vulnerability-related questions.
On the other hand, while a significant body of knowledge exists for classifying and categorizing software weaknesses, it is hardly applied in the context of a software project. From the information assurance community, there have been several attempts to catalog the knowledge and information gathered from past vulnerabilities in order to avoid future occurrences. The Common Vulnerabilities and Exposures (CVE) (MITRE, 2011b) provides an identification scheme that enables the collection and recording of known vulnerabilities from software development organizations, coordination centers and individuals. This facilitates review by experts which in turn leads to the generalization of similar vulnerabilities into higher-order software weaknesses. Several such software weakness categorizations have been attempted. Among these, the Common Weakness Enumeration (CWE) (MITRE, 2011c) is a community developed dictionary of such software weakness types that attempts to encompass other weakness categorization efforts.