  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.
