Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

// // //
01:00 PM
Bas Alberts
Bas Alberts

Improving the Vulnerability Reporting Process With 5 Steps

Follow these tips for an effective and positive experience for both the maintainer and external vulnerability reporter.

Vulnerability reports come at open source project maintainers from all directions with varying levels of quality and detail — from public project issues to emailed reports, and sometimes even through social media. This presents a considerable challenge for open source software (OSS) maintainers. How do you ingest, track, and triage external vulnerability reports in a consistent manner, especially when most OSS is run by volunteers in their spare time? 

Related Content:

SolarWinds: A Catalyst for Change & a Cry for Collaboration

Special Report: How Data Breaches Affect the Enterprise

New From The Edge: How to Create an Incident Response Plan From the Ground Up

The vulnerability research ecosystem contains many different actors, all with different motivations, ranging from commercial to altruistic to everything in between. 

Effectively and consistently interacting with the security community can prove challenging. Through the GitHub Security Lab (disclosure: I am a GitHub employee), we've observed many different approaches to receiving and triaging vulnerability reports, ranging from casual email interactions to fully ticketed bug tracking systems.

I'll break down the vulnerability report pipeline into five major steps that make for an effective and positive experience for both the maintainer and external vulnerability reporter: Receive, Acknowledge, Verify, Triage, and Publish.

Receiving Vulnerability Reports
Clearly indicate how and where you want to receive vulnerability reports, regardless of available resources, to help avoid friction, lost reports, or the publication of unresolved reports.

Setting a security policy will help standardize and normalize how vulnerability reports are delivered and how you want to track them further. By setting a policy, or otherwise making reporting instructions available (for example, in your project's ReadMe), you can take ownership of the process from the beginning. You'll also find that most external vulnerability reporters are more than happy to take direction when explicitly provided.  

Acknowledging Vulnerability Reports
Once a vulnerability report is received, either publicly or privately, it's important to acknowledge the receipt as quickly as possible. Even if no immediate resources are available for additional investigation, this initial acknowledgment allows vulnerability reporters to queue the status of the report on their end. Depending on the style of disclosure (full vs. coordinated), the reporter may start a clock on the publication deadline for the vulnerability details. 

The GitHub Security Lab follows a coordinated disclosure process in which maintainers get 90 days to privately triage a vulnerability report, after which full details of the issue are published in a public advisory. Rapid acknowledgment of a received report indicates to the reporter that you're quick to respond and act, and it sets a positive tone for the rest of the interaction.

Verifying Vulnerability Reports
Involve the vulnerability reporter when verifying the impact and veracity of the report. Chances are, they have already spent significant time considering the vulnerability in a variety of scenarios, some of which you may not have considered.

Ask for additional context on how they think a vulnerability could manifest in your project and any proof-of-concept or configuration details to determine whether the reported issue is indeed something with a security impact on your project. Sometimes you will disagree on whether or not something is a vulnerability or whose responsibility the vulnerability is. The most productive way to approach these scenarios is through dispassionate technical debate. 

Remember, while external vulnerability reports can feel like attacks on code quality, vulnerability reporters are often handling large volumes of reports concurrently, and they are unlikely to have personal investment in your specific project. You both share a common goal to first establish whether an issue is in fact a vulnerability, and if so, to get that issue resolved. Treating the reporter as a contributor, as opposed to an external critic, sets an effective tone for the interaction.

Triaging Vulnerability Reports
After verifying the report and reaching a consensus on its impact, it's time to discuss remediation. You and the reporter may also have differing opinions on the approach, so you should correct the issue in a way that you see fit while taking the reporter's concerns into careful consideration. The reporter will often have knowledge of corner cases and remediation bypasses that are easy to miss without a security research background. Once you believe an issue is fixed, have the reporter review your proposed remediation in case there are additional insights that can result in a stronger fix.

Publishing Vulnerability Reports
An important yet sometimes missed step in the disclosure pipeline is to ensure the wider ecosystem becomes aware of the issue and its remediation. It is not uncommon for projects to fix a recognized security issue in the current development branch but then not explicitly designate the commit or subsequent release as a security fix or release. This can lead to issues, as consumers of your project and any downstream dependencies might only update based on available security updates. Assuming that downstream consumers will always run the latest version of your project can lead to unnecessary proliferation of vulnerable code.

The reporter will often publish their own advisory, but you can take ownership of this process too. Commonly, a Common Vulnerabilities and Exposures (CVE) number will be requested and assigned by either the vulnerability reporter or yourself in the verification phase. 

On GitHub, you can publish a GitHub Security Advisory (GHSA) for your project, and since GitHub is a CVE Numbering Authority (CNA), the process is made easy. Publishing a GHSA makes your advisory available to the GitHub Advisory ecosystem and the wider OSS security ecosystem through its CVE. The assignment of the CVE, and details provided within, helps ensure there is ecosystem awareness of the security fixes available for any downstream consumers. 

Security vulnerabilities often go undetected for more than four years before being disclosed. Improving how you interact with vulnerability reports and reporters can help ensure that issues don't remain unresolved for longer than they need to. While effectively triaging external vulnerability reports may seem daunting, even projects and maintainers with limited resources can create a standardized pipeline for receiving, acknowledging, verifying, triaging, and publishing vulnerability reports. By removing ambiguity from the process, you can turn vulnerability reporting into a positive and collaborative experience, benefiting both the vulnerability research and developer communities and ultimately, OSS security.

Bas Alberts is a principal security researcher on GitHub's Security Lab team with a background in offense-focused information security. View Full Bio
Comment  | 
Print  | 
More Insights
Oldest First  |  Newest First  |  Threaded View
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
Creating an Effective Incident Response Plan
Security teams are realizing their organizations will experience a cyber incident at some point. An effective incident response plan that takes into account their specific requirements and has been tested is critical. This issue of Tech Insights also includes: -a look at the newly signed cyber-incident law, -how organizations can apply behavioral psychology to incident response, -and an overview of the Open Cybersecurity Schema Framework.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2022-11-30
A vulnerability was found in Sapido BR270n, BRC76n, GR297 and RB1732 and classified as critical. Affected by this issue is some unknown functionality of the file ip/syscmd.htm. The manipulation leads to os command injection. The attack may be launched remotely. The exploit has been disclosed to the ...
PUBLISHED: 2022-11-30
In Zkteco BioTime < 8.5.3 Build:20200816.447, an employee can hijack an administrator session and cookies using blind cross-site scripting.
PUBLISHED: 2022-11-30
Zkteco BioTime < 8.5.3 Build:20200816.447 is vulnerable to Incorrect Access Control via resign, private message, manual log, time interval, attshift, and holiday. An authenticated administrator can read local files by exploiting XSS into a pdf generator when exporting data as a PDF
PUBLISHED: 2022-11-30
Zkteco BioTime < 8.5.3 Build:20200816.447 is vulnerable to Incorrect Access Control via Leave, overtime, Manual log. An authenticated employee can read local files by exploiting XSS into a pdf generator when exporting data as a PDF
PUBLISHED: 2022-11-30
Unauth. Race Condition vulnerability in WP ULike Plugin <= 4.6.4 on WordPress allows attackers to increase/decrease rating scores.