How NOT to Manage Vulnerability Disclosures

Right before the New Year, some reports of security breaches hit the headlines. The Snapchat data breach was particularly noteworthy. Apparently, Snapchat was notified of the weaknesses by security researchers via private communication to the company, and then also publicly. Snapchat wrote a blog post acknowledging — and giving a clue about exploiting — the vulnerability.

The vulnerability in question was rather simple: A username enumeration vulnerability by an authenticated user (i.e., a weakness that allows any authenticated user to query information about other valid users). A few days later, some attackers posted the users’ partial phone numbers, usernames, and geographic locations on a publicly registered domain.

A breach like this is a case study in how not to manage a vulnerability disclosure. From the perspective of a software vendor, there are several ways to botch up the breach disclosure process, including the following:

  1. Not providing a clear, consistent communications process and single point of contact to communicate security vulnerabilities.
  2. Dismissing a security weakness without understanding the range of consequences.
  3. Publicly providing information without understanding the ramifications of disclosure.
  4. Delaying the fix after revealing information about the vulnerability.
  5. Waiting for a breach before implementing the fixes for the vulnerability.
  6. Not giving credit to the right people for helping to identify and resolve the vulnerabilities.
What are your experiences with vulnerability disclosures? If you have other do’s and don’ts, please share them in comments below.


The Networking Exchange Blog Team About NEB Team