BlogCareersContact Us
< Back to Blog

A Closer Look at Vulnerability Disclosure Policy

Rhett Glauser
 | Oct 17, 2018
 | Vulcan Cyber CMO


While technology companies aim to ensure that their products are watertight, the fact of the matter is that security vulnerabilities are discovered. But how they deal with these discoveries varies considerably.

The question is: should technology vendors keep vulnerabilities quiet or make them known? Delaying publicizing the security flaw gives them time to develop and distribute a fix before attackers know about the exploit. Yet the vulnerability may very well already be known. Joseph Steinberg in Inc magazine discusses how “…criminals and cybersecurity pros are locked in a race, and often reach the same milestones at similar times.”

If you assume that attackers already know about the vulnerability, disclosing them immediately gives customers the opportunity to put security controls in place to compensate for the vulnerability until a patch is developed.

Vulnerability Disclosure

Five Companies – And Five Different Vulnerability Disclosure Policies

There’s no uniform way that tech companies seem to be managing vulnerability disclosures; here’s a brief overview of how five companies are handling it.


Company    Disclosure period

Publishing an advisory



Following a full investigation and when a patch is developed

Published on a dedicated webpage

Before disclosure, to provide solutions.


Following a full investigation and when a patch is developed

An announcement is made privately:

  • On various Apache mailing lists
  • To the vulnerability reporter
  • On the project security mailing list
  • On MITRE

Afterward, an announcement is made publicly on the project’s security page

Before disclosure, to provide solutions.


Within 30 days, or longer if necessary. For Zero Day or imminent attacks, immediately.

Unstated Before disclosure


ASAP if needed

Via Cert/CC Before disclosure, to provide solutions.

Red Hat

Published in a public database Works with third-parties to remediate


According to Apple, their policy is to “not disclose, discuss, or confirm security issues until a full investigation is complete and any necessary patches or releases are available.” This is in keeping with Apple’s known policy of keeping as much as possible in-house and proprietary. Although Apple’s bug-bounty program has some of the most generous payouts, it is only about two years old, which shows how sensitive they are to outsiders testing their products. Apple insists that all security vulnerabilities be reported using PGP encryption.

Apple’s reputation for developing highly secured products has taken a bit of a beating. Within ten days of releasing macOS High Sierra in September 2017, Apple was forced to plug two massive security holes. The first bug enabled third-party applications to steal security credentials, and the password hint for what was thought to be encrypted Apple File Systems volumes revealed passwords in plain text. The second bug found by security researches showed that anyone could gain root access simply by typing the word “root.” Apple pushed out patches immediately to remediate these vulnerabilities.


The Apache Software Foundation has a well-defined vulnerability disclosure policy. Interestingly, despite Apache’s efforts to ensure that the vulnerability is kept secret until the end of the process, they do allow each Apache project to use their own disclosure system as long as they document the process and have it approved ahead of time.

Apache lays out their comprehensive 16-step system on the security page of their website.  Initially, all disclosure is to internal mailing lists, then to the vulnerability reporter, then to the project’s private mailing list, then to MITRE (a not-for-profit organization that maintains the CVE database). At the very end of the process, the vulnerability is added to the project’s public-facing website – this is only after a fix has been developed.

In August 2018, a security researcher disclosed a major remote code execution flaw in Apache Struts, an open source framework for developing web apps in Java. Hacker News reported that the flaw was due to “insufficient validation of user-provided untrusted inputs in the core of the Struts framework under certain configurations.” An updated patched version of Apache Struts was released before the vulnerability was disclosed.


Adobe has a rocky history of severe security issues, including spyware, security flaws in Adobe PhotoShop software in 2012, and a major 2013 data breach in which 150 million user accounts were compromised. In 2015 Adobe announced an initiative to encourage security researchers to submit vulnerabilities found in Adobe online apps to their HackerOne program.

The Adobe disclosure policy encourages “coordinated disclosure.” By default, this is 30 days from the initial bug report, but it can be extended if time is needed to develop a patch. In the case of Zero Day or imminent attacks, Adobe might disclose the vulnerability immediately, especially if a patch is available. Adobe provides a directory for contacting other vendors about security vulnerabilities, but it does not mention where they disclose security vulnerabilities found in Adobe web apps.

While no monetary prizes are awarded to those who find vulnerabilities in most Adobe web apps, the first person to report a previously unknown vulnerability receives credit for it. Ironically, Adobe offers software to application developers to manage their own bug bounty programs.


Microsoft asserts that “In the case that a vulnerability is found after we launch, we address it as quickly as possible and prepare it for deployment the world over.”

In February 2018, Microsoft released 50 patches for Internet Explorer, Microsoft Edge, ChakraCore, Microsoft Windows and Microsoft Office. Their most famous vulnerability was found in Microsoft Outlook Memory.

Microsoft implements Coordinated Vulnerability Disclosure (CVD) policies such as:

  • Reporting vulnerabilities to CERT-CC who coordinate with vendors and interested parties and sets timelines for disclosure and for providing solutions.
  • Disclosing vulnerabilities before an agreed-upon disclosure date if the public is at risk.
  • Finding solutions for vulnerabilities before they are published.
  • Collaborating with vendors to remediate vulnerabilities and to keep users safe during their development.
  • Providing transparent progress on the development of solutions to update interested parties.
  • Testing their solutions with vendors before their release to ensure they work.
  • Coordinating disclosure with vendors when a release is ready.

Red Hat

Although Red Hat acknowledges that fixes to vulnerabilities found in Red Hat services run by third-parties are developed in coordination with them, no further details are forthcoming. One is hard-pressed to find a detailed vulnerability disclosure policy on the Red Hat website, so how long Red Hat keeps security vulnerabilities secret before disclosing them is unclear.  

In July of 2018, the Senior Manager for Security at Red Hat posted a blog apologizing for mishandling disclosing a vulnerability in third-party software. Red Hat disclosed the vulnerability before notifying affected projects (causing them potential security issues), assuring users that they conducted a complete review of their policies regarding the handling of non-public security vulnerability information. But their disclosure policy for vulnerabilities in their own software remains somewhat of a mystery.

Red Hat maintains a public database of security vulnerabilities and advisories that covers all Red Hat products. So it is curious that when a major security flaw in most Linux distributions released over a ten year period was publicly disclosed in late September 2018, Red Hat has been slow to respond. A serious vulnerability was found in the Linux kernel that “could allow an unprivileged user to gain superuser access to the targeted system.” This vulnerability was addressed by most Linux distributions, but Red Hat Enterprise Linux was among the few that did not implement the necessary changes, so it has been left vulnerable to attack. Perhaps Red Hat needs to read the disclosure that is categorized in their own vulnerabilities database as “important.”

Disclosure – More Than One Way

Users and vendors have limited time to patch their systems when a company discloses security vulnerabilities; once the information is public, the speed at which attackers take advantage of security vulnerabilities is truly mind-blowing.

Vulnerability management policies should be well developed from the onset. While there is some overlap in vulnerability disclosure policies for these companies, there are real differences in the ways companies and repositories are treating vulnerability disclosures in terms of providing information about any potential damage, and whether there is live documentation to record progress and evaluate solutions.

About the Author

Rhett Glauser

Rhett has been running corporate marketing and demand generation functions in the enterprise infrastructure and security markets for a really long time. Prior to Vulcan Cyber Rhett spent more than two decades with SaltStack, ServiceNow, Symantec and Altiris.

People also read

The MITRE ATT&CK framework and more – introducing Voyager18

Read More >

9 AWS Security Tools You Should Know About

Read More >

SANS Cloud Security Survey 2022 – highlights

Read More >

How to fix the zero day CVE-2022-22620 vulnerability

Read More >

CIS Benchmarks and system hardening: the ultimate guide

Read More >
< Back to Blog
Did you find this interesting? Share it with others:

Be a Fixer