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
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
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-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file