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
Newest First  |  Oldest 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
The Promise and Reality of Cloud Security
Cloud security has been part of the cybersecurity conversation for years but has been on the sidelines for most enterprises. The shift to remote work during the COVID-19 pandemic and digital transformation projects have moved cloud infrastructure front-and-center as enterprises address the associated security risks. This report - a compilation of cutting-edge Black Hat research, in-depth Omdia analysis, and comprehensive Dark Reading reporting - explores how cloud security is rapidly evolving.
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: 2023-01-31
Versions of the package nemo-appium before 0.0.9 are vulnerable to Command Injection due to improper input sanitization in the 'module.exports.setup' function. **Note:** In order to exploit this vulnerability appium-running 0.1.3 has to be installed as one of nemo-appium dependencies.
PUBLISHED: 2023-01-31
This affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.
PUBLISHED: 2023-01-31
Versions of the package jsuites before 5.0.1 are vulnerable to Cross-site Scripting (XSS) due to improper user-input sanitization in the Editor() function.
PUBLISHED: 2023-01-31
In affected versions of Octopus Server the help sidebar can be customized to include a Cross-Site Scripting payload in the support link. This was initially resolved in advisory 2022-07 however it was identified that the fix could be bypassed in certain circumstances. A different approach was taken t...
PUBLISHED: 2023-01-31
Incorrect Privilege Assignment vulnerability in Hitachi Storage Plug-in for VMware vCenter allows remote authenticated users to cause privilege escalation. This issue affects Hitachi Storage Plug-in for VMware vCenter: from 04.8.0 before 04.9.1.