Security issue reports are the primary means of informing development teams of security risks in projects, but little is known about current practices. We aim to understand the characteristics of these reports in open-source projects and uncover opportunities to improve developer practices. We analysed 3,493 security issue reports in 182 different projects on GitHub and manually studied 333 reports, and their discussions and pull requests. We found that, the number of security issue reports has increased over time, they are resolved faster, and they are reported in earlier development stages compared to past years. Nevertheless, a tiny group of developers are involved frequently, security issues progress slowly, and a great number of them has been pending for a long time. We realized that only a small subset of security issue reports include reproducibility data, a potential fix is rarely suggested, and there is no hint regarding how a reporter spotted an issue. We noted that the resolution time of an issue is significantly shorter when the first reaction to a security report is fast and when a reference to a known vulnerability exists.
翻译:安全问题报告是向各发展小组通报项目安全风险的主要手段,但目前的做法却鲜为人知。我们的目的是了解这些报告在公开来源项目中的特点,发现改进开发者做法的机会。我们分析了182个关于GitHub的不同项目中的3 493份安全问题报告,人工研究了333份报告,以及这些报告的讨论和拉动要求。我们发现,安全问题报告的数量随着时间推移而增加,解决的速度更快,而且报告的发展阶段比往年要早。然而,一小撮开发者经常参与,安全问题进展缓慢,而且许多报告长期悬而未决。我们认识到,只有一小部分安全问题报告包括可复制数据,很少提出可能的解决办法,而且没有说明记者如何发现一个问题。我们注意到,当对安全报告作出第一次反应的速度很快,当发现存在已知的脆弱性时,问题的解决时间会大大缩短。