Fixing of Security Vulnerabilities in Open Source Projects: A Case Study of Apache HTTP Server and Apache Tomcat

Fixing of Security Vulnerabilities in Open Source Projects: A Case Study of Apache HTTP Server and Apache Tomcat
复制标题

开源项目安全漏洞修复:以Apache HTTP Server和Apache Tomcat为例

DOI:
--
复制
发表时间:
2019
期刊:
International Conference on Information Control Systems & Technologies
影响因子:
--
通讯作者:
Rocco Oliveto
Rocco Oliveto
中科院分区:
--
文献类型:
--
作者:
Valentina Piantadosi;Simone Scalabrino;Rocco Oliveto

文献摘要

被引文献

相似文献

软件漏洞是特别危险的错误,可能会使攻击者违反软件系统的机密性,完整性或可用性约束。很快解决漏洞至关重要;此外,释放完整的补丁至关重要,这些补丁不会留下任何未覆盖的角色。在本文中,我们研究开源软件中脆弱性修复的过程。我们专注于三个维度:个人,即修复软件漏洞的人;暂时性,即发布补丁需要多长时间;程序性,即解决漏洞的过程是什么。在研究的背景下,我们分析了有关Apache HTTP服务器和Apache Tomcat的337个CVE条目,并将它们手动链接到编写的补丁程序以修复此类漏洞及其相关的承诺。结果表明,修复软件漏洞的开发人员比平均水平要经验丰富得多。此外,我们观察到,漏洞是通过提交固定的,而且令人惊讶的是,在大约3%的情况下,这种漏洞再次出现在将来的发行版中(即它们实际上不是固定的)。鉴于这种结果,我们得出了一些经验教训,这些教训代表了未来研究方向的起点,旨在在文档和修复漏洞的过程中更好地支持开发人员。
Software vulnerabilities are particularly dangerous bugs that may allow an attacker to violate the confidentiality, integrity or availability constraints of a software system. Fixing vulnerabilities soon is of primary importance; besides, it is crucial to release complete patches that do not leave any corner case not covered. In this paper we study the process of vulnerability fixing in Open Source Software. We focus on three dimensions: personal, i.e., who fixes software vulnerabilities; temporal, i.e., how long does it take to release a patch; procedural, i.e., what is the process followed to fix the vulnerability. In the context of our study we analyzed 337 CVE Entries regarding Apache HTTP Server and Apache Tomcat and we manually linked them to the patches written to fix such vulnerabilities and their related commits. The results show that developers who fix software vulnerabilities are much more experienced than the average. Furthermore, we observed that the vulnerabilities are fixed through more than a commit and, surprisingly, that in about 3% of the cases such vulnerabilities show up again in future releases (i.e., they are not actually fixed). In the light of such results, we derived some lessons learned that represent a starting point for future research directions aiming at better supporting developers during the documentation and fixing of vulnerabilities.