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

4/22/2021
01:00 PM
Bas Alberts
Bas Alberts
Commentary
50%
50%

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
Slideshows
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
Commentary
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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
CVE-2020-35519
PUBLISHED: 2021-05-06
An out-of-bounds (OOB) memory access flaw was found in x25_bind in net/x25/af_x25.c in the Linux kernel version v5.12-rc5. A bounds check failure allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a leak of internal kernel i...
CVE-2021-20204
PUBLISHED: 2021-05-06
A heap memory corruption problem (use after free) can be triggered in libgetdata v0.10.0 when processing maliciously crafted dirfile databases. This degrades the confidentiality, integrity and availability of third-party software that uses libgetdata as a library. This vulnerability may lead to arbi...
CVE-2021-30473
PUBLISHED: 2021-05-06
aom_image.c in libaom in AOMedia before 2021-04-07 frees memory that is not located on the heap.
CVE-2021-32030
PUBLISHED: 2021-05-06
The administrator application on ASUS GT-AC2900 devices before 3.0.0.4.386.42643 allows authentication bypass when processing remote input from an unauthenticated user, leading to unauthorized access to the administrator interface. This relates to handle_request in router/httpd/httpd.c and auth_chec...
CVE-2021-22209
PUBLISHED: 2021-05-06
An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.8. GitLab was not properly validating authorisation tokens which resulted in GraphQL mutation being executed.