How to Disclose, Report and Patch a Software Vulnerability

Finding a software vulnerability before hackers do is hugely important to helping protect the digital landscape. However, it can be difficult to know what to do next or who to contact.

It is important to report a vulnerability in your own software or a third-party’s software but the process isn’t always clear.

According to the Open Web Application Security Project (OWASP), the vulnerability disclosure process “is an area where collaboration is extremely important, but that can often result in conflict between the two parties.”

Infosecurity has outlined the fundamental steps ethical hackers, independent researchers and other cybersecurity professionals need to take to responsibly disclose and report a vulnerability, as well as how patching processes work.

When a security researcher finds a vulnerability in another organization’s software, they follow different types of disclosure models, from the most secretive (private disclosure) to the most transparent (full disclosure).

Private Disclosures

Private disclosures, or vendor disclosures, involve the researcher reporting the vulnerability to the product owner only. Once made aware, the vendor may choose to publish the details of the vulnerabilities, but this is done at the discretion of the organization, not the researcher.

Most bug bounty programmes require that the researcher follows this model.

Responsible Disclosure

When the vulnerability hunter chooses to perform a responsible disclosure, they make the initial report privately but ensure that the key details of the vulnerability will be made public in the future once mitigation measures or patches are released.

In many cases, the researcher provides a deadline for the organization to respond to the report or to provide a patch. Once this deadline has passed, they typically publish vulnerability details in part or as a whole.

Coordinated Disclosure

In 2010, Microsoft introduced the coordinated disclosure model, referred to as coordinated vulnerability disclosure (CVD). It is like the responsible disclosure model, although CVD emphasizes that the deadline and the disclosure method should be negotiated between both parties.

The US Cybersecurity and Infrastructure Security Agency (CISA) and Google’s Project Zero have since adopted CVD.

Sometimes, computer emergency readiness teams (CERTs) and computer security incident response teams (CSIRTs) can act as an intermediary between both parties.

Clients, customers, suppliers and partners typically perform private or coordinated disclosures.

Full Disclosure

A full disclosure is when the full details of the vulnerability, sometimes including exploit code, are made public as soon as they are identified.

“The full disclosure approach is primarily used in response or organizations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix,” OWASP explained.

To help security researchers know what to do, it is recommended that software owners follow vulnerability disclosure policy guidelines.

Ideally, these should at least include the following elements:

• Vulnerability reporting process
• Communication mechanisms and processes
• Nonbinding submission preferences and prioritizations
• Scope of what would result in legal action

Similarly, companies running bug bounty or penetration testing programs should establish a safe harbour to indicate where and how far researchers can and cannot go.

OWASP recommends rewarding researchers who reported a vulnerability in a responsible way to encourage this kind of positive interaction in the future.

If monetary rewards are not possible, then several other options should be considered, such as:

• Discounts or credit for services or products offered by the organization
• Virtual or material swag, gifts or freebies
• Credit in a ‘hall of fame’ or other similar acknowledgment.

Software owners can also perform self-reporting when they find vulnerabilities in their own products. 

Initial Report

Once the product owner has been made aware of the vulnerability, it should quickly start assessing it. To help them with the process, the person who identified the vulnerability can send them an initial report.

According to OWASP, an initial report should include the following elements:

• Sufficient details of the vulnerability to allow it to be understood and reproduced
• HTTP requests and responses, HTML snippets, screenshots or any other supporting evidence
• Proof of concept code (if available)
• An assessment of the impact of the vulnerability

Publish a Vulnerability: CVEs, CNAs and the NVD

This initial report will help inform the vendor’s public security advisory if it publishes one.

One of the most common ways of publishing vulnerability disclosures is through the Common Vulnerabilities and Exposures (CVE) programme, which provides standard identifiers for publicly known cybersecurity vulnerabilities.

The CVE programme is run by the MITRE Corporation, a US-based non-profit. This common enumeration makes it possible to share data across separate vulnerability capabilities (cybersecurity tools, repositories, and services).

The use of CVE records ensures that two or more parties can confidently refer to a CVE Identifier (CVE ID) when discussing or sharing information about a unique vulnerability. In this way, CVE is fundamental to the vulnerability management infrastructure.

To publish a CVE, product owners need to contact a vetted organization known as a CVE Numbering Authority (CNA).

Currently, 370 CNAs (368 CNAs and two last-resort CNAs, or CAN-LRs) from 40 countries are participating in the CVE Program.

CVEs are listed on the US National Vulnerability Database (NVD), the world-biggest vulnerability repository.

The NVD programme is run by the US National Institute of Standards and Technology (NIST). Although many US and non-US organizations use the CVE and NVD programs, some companies, industry associations and even countries have their own vulnerability reporting processes.

Enrichment and Updates: CPE, CVSS

CVEs listed on the NVD are usually enriched with metadata indicating details about the vulnerabilities.

Those include their nature (e.g. Common Platform Enumerations, or CPEs), severity (Common Vulnerability Scoring System, or CVSS), a technical analysis, evidence of exploitation and a timeline of the disclosure and the patches, if applicable.

However, the future of the NVD program has recently been questioned after NIST started facing resource and financial challenges that led to a halt in vulnerability enrichment.

Read more: NIST Unveils New Consortium to Operate National Vulnerability Database

ADVERTISEMENT

When a vulnerability is discovered, different approaches can be taken to address it.

Before a vulnerability is fixed – or if it cannot be fixed - product owners can add mitigation measures in their security advisory.

Mitigation measures don't directly address the vulnerability itself but make it harder to exploit. They can involve measures like changing configurations, disabling features, or implementing additional security controls.

Sometimes, the developer can deploy hotfixes. These are minor fixes designed to address a critical vulnerability immediately but can be vulnerable to some exploit approaches. Hotfixes are often deployed on live systems to minimize downtime or security risks. They are generally a temporary solution until a full patch can be developed.

Finally, a patch is a comprehensive fix for the vulnerability. It addresses the root cause of the problem and permanently eliminates the security hole. Patches usually undergo testing before being released. They may require system downtime to be installed.

Enjoyed this article? Make sure to share it!

Looking for something else?