A case study on software vulnerability coordination

Abstract

Context: Coordination is a fundamental tenet of software engineering. Coordination is required also for identifying discovered and disclosed software vulnerabilities with Common Vulnerabilities and Exposures (CVEs). Motivated by recent practical challenges, this paper examines the coordination of CVEs for open source projects through a public mailing list. Objective: The paper observes the historical time delays between the assignment of CVEs on a mailing list and the later appearance of these in the National Vulnerability Database (NVD). Drawing from research on software engineering coordination, software vulnerabilities, and bug tracking, the delays are modeled through three dimensions: social networks and communication practices, tracking infrastructures, and the technical characteristics of the CVEs coordinated. Method : Given a period between 2008 and 2016, a sample of over five thousand CVEs is used to model the delays with nearly fifty explanatory metrics. Regression analysis is used for the modeling. Results: The results show that the CVE coordination delays are affected by different abstractions for noise and prerequisite constraints. These abstractions convey effects from the social network and infrastructure dimensions. Particularly strong effect sizes are observed for annual and monthly control metrics, a control metric for weekends, the degrees of the nodes in the CVE coordination networks, and the number of references given in NVD for the CVEs archived. Smaller but visible effects are present for metrics measuring the entropy of the emails exchanged, traces to bug tracking systems, and other related aspects. The empirical signals are weaker for the technical characteristics. Conclusion: Software vulnerability and CVE coordination exhibit all typical traits of software engineering coordination in general. The coordination perspective elaborated and the case studied open new avenues for further empirical inquiries as well as practical improvements for the contemporary CVE coordination.

Empirical Notes on the Interaction Between Continuous Kernel Fuzzing and Development

“…Bug fixing times are a classical topic in software engineering. Although not all bugs found by fuzzing are security bugs, previous results generally indicate that also security bugs often take a surprisingly long time to fix in many different contexts [15], [16]. Some bugs are never fixed even though these have been recognized as vulnerabilities [17].…”

“…For instance, different memory management bugs (such as CWE-415 and CWE-416) could be assumed to yield faster fixing times compared to stalls and deadlocks that are usually difficult to debug especially in the kernel development context. In general, a similar rationale applies to the coordination of CVE identifiers and vulnerabilities in general [16]. Of course, testing and reviewing take time, and thus RQ.3b implies a clear-cut hypothesis.…”

“…No universal explanation is known for these and related results. Numerous different explanations are offered in the literature: some build on bug triaging aspects and different incentives for vendors, bug reporters, and developers [15], [18]; others stem from bug severity, testing, architectural flaws, dependencies, code complexity, and code churn [19], [20]; some are related to problems in vulnerability disclosure and associated coordination, including the allocation of CVEs for the vulnerabilities [16], [21]; and so forth. Whatever the explanations may be, the first research question is worth asking to better understand the time delays associated with continuous fuzzing and automated testing in general.…”

A Demand-Side Viewpoint to Software Vulnerabilities in WordPress Plugins

“…The examples include hosting services, blogs, company websites, bug trackers, bug bounty platforms, so-called pastebins, other databases, media outlets, online archives, and personal homepages. Taken together, these diverse sources are a good example on the practical challenges for current vulnerability tracking [28]. Such practical challenges also translate into research challenges: mining a single software repository (or a few repositories, for that matter) is assuredly inadequate for empirically observing most known software (plugin) vulnerabilities.…”

Study on Software Vulnerability Characteristics and Its Identification Method

“…With the rapid development of information technology, software system and its vulnerabilities have become a widespread concern for developers [1][2][3][4]. Software vulnerabilities are defects in software's specific implementation or system security policy, which can enable attackers to access or damage the system without authorization.…”