mlsanityData to 14 Oct 2026

How Do Developers Deal with Security Issue Reports on GitHub?

arXiv 2112.10359 ↗First posted 20 Dec 2021cs.CR cs.SEcited by 4

Not on the map. Why?

Abstract (arXiv)

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.

Key facts. Cited by 4 papers in the map (data through 14 Oct 2026). First posted on arXiv 20 Dec 2021.

Builds on

No reference list yet.

Built on by

Cited by year (2026 to 14 Oct)

Citing papers per year: 2023: 1; 2024: 0; 2025: 2; 2026: 1.

4 papers.