Many open-source projects lack a clear way to report security problems

Friday, June 21, 2019

The following excerpt is from “GitHub Releases New Tools to Report Vulnerabilities,” an article by Rina Diane Caballar published on June 21, 2019 in IEEE Spectrum, the magazine and website of the Institute of Electrical and Electronics Engineers.

The article reports recent research conducted by Mei Nagappan, an assistant professor in the Cheriton School of Computer Science, and his colleagues on the lack of security vulnerability reporting processes in open-source software projects. 


For most software developers, importing code from third-party libraries is an easy way to add new functionalities to a program without building those features from scratch. But relying on open-source libraries can be risky, as hackers often target security vulnerabilities within them.

Given all this, it’s important for users of any library to be able to report potential security issues to the project’s owners, so such problems can be fixed before they’re exploited. But until recently, many projects on the online repository GitHub lacked a clear way for users to submit security reports.

photo of Mei Nagappan

Cheriton School of Computer Science Professor Mei Nagappan, coauthor of the study, conducts "big data" empirical software engineering by mining ultra large repositories of software to identify patterns and relationships in large ecosystems. 

“I think reporting is the first step needed,” says Cheriton School of Computer Science Assistant Professor Mei Nagappan. But, adds University of Michigan professor Atul Prakash, “if the reporting process isn't simple and straightforward, that can discourage or delay security reporting. And that can have consequences.”

While working on another project in 2018, Nagappan and his team found it difficult to report a vulnerable version of Apache Struts, the open-source library hackers exploited to breach Equifax in 2017. They tried informing other GitHub projects with the same dependency through a combination of emailing project owners, opening issues, and submitting pull requests.

But a team member’s GitHub account was flagged as spam for opening 15 issues and 15 pull requests. “We did let [GitHub] know that this wasn’t an automated process of any kind. We manually created the issues and pull requests,” Nagappan says. “We were open with GitHub. We told them, we’re a research team and this is what we’re doing.”

The experience prompted the team, which included Nagappan, Prakash, and collaborators at the University of Illinois at Urbana-Champaign, to do a study (published May 23, 2019) to investigate the prevalence of vulnerable dependencies and the difficulties in reporting them.

They analyzed 600 open-source Java projects on GitHub and found that 64 percent (385 of 600 projects) used at least one vulnerable library. Moreover, only 19 projects (3 percent) had some kind of reporting process — be it a “bug bounty” program, an email address to contact regarding security vulnerabilities, or a web form for submitting security issues.

To address the lack of a standardized method to report security vulnerabilities in GitHub projects, the team recommended adding a SECURITY.md file which contains contact information and the disclosure policy of a project. The team also suggested support for submitting pull requests or issues visible only to project owners (also called maintainers) as a way to privately disclose potential security problems.

  • Read the full article at IEEE Spectrum
  • Read Open Source Vulnerability Notification, the research paper on which the article is based
    Citation: Carlson B., Leach K., Marinov D., Nagappan M., Prakash A. (2019) Open Source Vulnerability Notification. In: Bordeleau F., Sillitti A., Meirelles P., Lenarduzzi V. (eds) Open Source Systems. OSS 2019. IFIP Advances in Information and Communication Technology, vol 556. Springer, Cham
  1. 2024 (22)
    1. March (13)
    2. February (1)
    3. January (8)
  2. 2023 (70)
    1. December (6)
    2. November (7)
    3. October (7)
    4. September (2)
    5. August (3)
    6. July (7)
    7. June (8)
    8. May (9)
    9. April (6)
    10. March (7)
    11. February (4)
    12. January (4)
  3. 2022 (63)
    1. December (2)
    2. November (7)
    3. October (6)
    4. September (6)
    5. August (1)
    6. July (3)
    7. June (7)
    8. May (8)
    9. April (7)
    10. March (6)
    11. February (6)
    12. January (4)
  4. 2021 (64)
  5. 2020 (73)
  6. 2019 (90)
  7. 2018 (82)
  8. 2017 (50)
  9. 2016 (27)
  10. 2015 (41)
  11. 2014 (32)
  12. 2013 (46)
  13. 2012 (17)
  14. 2011 (20)