On Categorizing Open Source Software Security Vulnerability Reporting Mechanisms on GitHub

TL;DR

This study analyzes how open source projects on GitHub report security vulnerabilities, highlighting the importance of structured reporting files and the need for improved security practices to prevent exploitation.

Contribution

It provides empirical insights into vulnerability reporting mechanisms, emphasizing the role of SECURITY$.md files and identifying gaps in current security practices.

Findings

Email remains the primary reporting source.

Projects without SECURITY$.md files have lower security scores.

Some contributors disclose vulnerabilities publicly despite private reporting encouragement.

Abstract

Open-source projects are essential to software development, but publicly disclosing vulnerabilities without fixes increases the risk of exploitation. The Open Source Security Foundation (OpenSSF) addresses this issue by promoting robust security policies to enhance project security. Current research reveals that many projects perform poorly on OpenSSF criteria, indicating a need for stronger security practices and underscoring the value of SECURITY$.$md files for structured vulnerability reporting. This study aims to provide recommendations for improving security policies. By examining 679 open-source projects, we find that email is still the main source of reporting. Furthermore, we find that projects without SECURITY$.$md files tend to be less secure (lower OpenSSF scores). Our analysis also indicates that, although many maintainers encourage private reporting methods, some contributors continue to disclose vulnerabilities publicly, bypassing established protocols. The results from this preliminary study pave the way for understanding how developers react and communicate a potential security threat. Future challenges include understanding the impact and effectiveness of these mechanisms and what factors may influence how the security threat is addressed.