Responsible Disclosure

What is Responsible Disclosure?

Vulnerability disclosure

Vulnerability disclosure is the habit of reporting security gaps in system software or hardware.

Vulnerabilities may be unveiled directly to the people accountable for the vulnerable systems by security practitioners or by other interested stakeholders, including in-house developers as well as third party developers who work with the vulnerable systems. Typically, vendors or developers wait until a patch, or another mitigation is possible before making the vulnerability public.

Vulnerability disclosure issues

Performing the Vulnerability disclosure is a controversial subject because vendors prefer to retain the vulnerability beneath covers until they have a patch available to distribute to users. Conversely, researchers and security specialists, as well as enterprises whose data or systems may be at risk, prefer that disclosures be made public sooner.

When it comes to vulnerability disclosure, there are various distinct groups of stakeholders, each of which has multiple priorities. Preeminent, there are the vendors, developers or businesses of the vulnerable systems or co-operations who would favour that vulnerabilities be disclosed only to themselves, and made public only after the introduction of the patches.
Users of the unsafe products or solutions form another group of stakeholders; they prefer the patches to the systems as soon as possible. However, if a software or hardware patch for the security gap is not present, then intruders begin exploiting it. Disclosure is favoured as long as there are other ways to mitigate or dismiss the threat.
Finally, there are security researchers who reveal the vulnerabilities. Their preference is that the remediation of the vulnerabilities so they may advertise details of the vulnerabilities they discovered.

A vulnerability disclosure policy (VDP) focusses on presenting outspoken guidelines for proposing security vulnerabilities to companies. A VDP contributes a way for people to report vulnerabilities in a company’s products or services.

Years of Experience

Types of vulnerability disclosure

Responsible disclosure is one approach that numerous vendors and researchers have used for many years. Under an accountable disclosure protocol, researchers tell the system providers about the vulnerability and provide vendors with reasonable timelines to investigate and fix them and then publicly disclose vulnerabilities once they release the patches. Typically responsible disclosure guidelines allow vendors from 60 to 120 days to patch a vulnerability. In many cases, vendors negotiate with researchers to modify the schedule to allow for more time to fix severe flaws.

In 2010, Microsoft attempted to reshape the disclosure aspect by advancing a new notion of coordinated disclosure, also attributed to as coordinated vulnerability disclosure (CVD), following which researchers and vendors work together to recognise and remediate the vulnerabilities and negotiate a reciprocally harmonious amount of time for patching the product and notifying the public.

While high-profile vulnerability disclosures often include a vendor or developer accountable for the vulnerable product and research teams responsible for discovering the vulnerability, there are other disclosure options for vulnerabilities:

  • Self-disclosure: Happens when the manufacturers of products with vulnerabilities find the security gaps and make them public, habitually simultaneously with publishing patches or other fixes.
  • Third-party disclosure: Occurs when the parties reporting the vulnerabilities are not the owners, authors or rights holders of the hardware, software or systems. Generally, Third-party disclosures by security researchers who inform the manufacturers. Still, third-party disclosure may also involve a responsible organization such as the U.S. Computer Emergency Readiness Team (CERT) at Carnegie Mellon University in Pittsburgh.
  • Vendor disclosure Transpires when researchers report vulnerabilities only to the application vendors, which then work to produce patches.
  • Full disclosure: Occurs when a vulnerability is released in full publicly, often as soon as the details of the vulnerability are known.

Vulnerability disclosure policy and guidelines

A vulnerability disclosure policy (VDP) focusses on presenting outspoken guidelines for proposing security vulnerabilities to companies. A VDP contributes a way for people to report vulnerabilities in a company’s products or services.
  • A VDP should comprise the following elements, according to the National Telecommunications and Information Administration:
    • Brand Promise
    • Initial Program and Scope
    • “We Will Take No Legal Action If”
    • Communication Mechanisms and Process
    • Nonbinding Submission Preferences and Prioritizations

In their VDPs, companies can also let finders know when they can publicly talk about vulnerabilities. For example, an organization may state that a spotter cannot publicly disclose the vulnerability:

  • until it’s fixed
  • until a certain length of time has passed since a report was first submitted
  • until the finder has given the organization X days of notice
  • except on a mutually agreed-upon (or negotiated) timeline that may allow the modification as part of the process with the disclosing party
Vulnerability disclosure policy
  • Brand Promise: Enables a company to illustrate its commitment to security to clients and others probably affected by a vulnerability by ensuring users and the public that safety and security are essential. The company describes what work it has done relevant to vulnerabilities, as well as what it demands to do going forward.
  • Initial Program and Scope: Indicates which systems and capabilities are fair game and which are off-limits to the people and groups that find and report new vulnerabilities. For example, a company may encourage submissions for all sites it owns but explicitly excludes any customer websites hosted on its infrastructure.
  • “We Will Take No Legal Action If”:  Where a company informs researchers about the activities or actions they take and whether they will or won’t result in legal action.
  • Communication Mechanisms and Process: Allows a company to identify how researchers should submit their vulnerability reports (e.g., secure web form or email).
  • Nonbinding Submission Preferences and Prioritizations: Sets expectations for preferences and priorities about how a company will evaluate reports. It also lets researchers know which types of issues are considered necessary. Typically, an organization’s support and engineering team maintain this dynamic document.
Vulnerabilities reported to Carnegie Mellon University Software Engineering Institute’s CERT are forwarded to the affected vendors “as soon as practical after we receive the report.”
Currently, security researchers don’t agree on precisely what constitutes “a reasonable amount of time” to allow a vendor to patch a vulnerability before full public disclosure. Most industry vendors generally agree that a 90-day deadline is acceptable. In 2010 Google recommended a 60-day period to fix a vulnerability before full public disclosure, seven days for critical security vulnerabilities, and fewer than seven days for critical vulnerabilities that are in the phase of active exploitation. However, in 2015 Google extended that deadline to 90 days for its Project Zero program.
Disclosure deadlines can vary among vendors, researchers and other organizations. Vulnerabilities reported to the CERT Coordination Center are disclosed to the public 45 days after they’re first published, whether or not the affected vendors have issued patches or workarounds.
Extenuating circumstances such as “active exploitation, threats of an especially serious (or trivial) nature or situations that require changes to an established standard” can affect CERT’s deadlines. The coordination centre may make an open disclosure of a software vulnerability before or after the 45-day time frame in some cases.

Branded vulnerabilities

Recently, security researchers have increasingly begun to brand their vulnerability disclosures, creating catchy vulnerability names, dedicated websites and social media accounts with information about the vulnerabilities often including academic papers describing the weaknesses and even custom designed logos.

Some prominently branded vulnerabilities of recent years include “ImageTragick,” the name implemented to a set of security gaps in the open-source ImageMagick library for processing images; “Badlock,” a vulnerability that affected almost all variants of Windows; “HTTPoxy,” a set of vulnerabilities in applications that use HTTP proxy and the “KRACK” attack on WPA2 authentication over Wi-Fi.

The cybersecurity community tends to be outspoken on whether such efforts are proper. Some researchers who promote branded vulnerabilities are attempting to excite their research, whether or not the vulnerabilities are dangerous. Others take upshot with branding when a well-supported public relations effort in support of a vulnerability distracts the public from other weaknesses that have been made public without extensive publicity campaigns.

At OMVAPT, we are focussing on the coordinated vulnerability disclosure, and the rewards may be minimal at this point as we are just a startup. 

Vulnerability disclosure process

Although there’s no formal industry standard when it comes to reporting vulnerabilities, disclosures typically follow the same necessary steps:

  • A researcher discovers a security vulnerability and determines its potential impact. The finder then documents the vulnerability’s location via pieces of code or screenshots.
  • The researcher develops a vulnerability advisory report detailing the vulnerability and including supporting evidence as well as a full disclosure timeline. The researcher then securely submits this report to the vendor.
  • The researcher usually allows the vendor a reasonable amount of time to investigate and patch the vulnerability according to the advisory full disclosure timeline.
  • Once a patch is available, or the timeframe for disclosure — and any extensions — has elapsed. The researcher publishes a comprehensive disclosure analysis of the exploit. It includes a detailed explanation of the vulnerability, its impact as well as the resolution.

Rewarding Researchers

Where researchers have identified and reported vulnerabilities outside of a bug bounty program (essentially providing free security testing). Or Who has performed professionally and excellently throughout the vulnerability disclosure process? It is competent to offer them some reward to encourage this kind of positive interaction in future.

benefits of

REsponsible disclosure

  • If monetary rewards are not possible, then several other options should be considered, such as:
    • We offer discounts or credit for services or products provided by the OMVAPT.
    • We may offer online rewards (such as exclusive in-game items, custom avatars, etc.).
    • We provide T-shirts, stickers and other branded items (swag).
    • Credit in a “hall of fame”, or other similar recognition.
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.