Make Reporting Bugs Easy

Two weeks ago, the Privileged Access Manager (PAM) company, Delinea, reported (https://www.securityweek.com/delinea-scrambles-to-patch-critical-flaw-after-failed-responsible-disclosure-attempt/) a new vulnerability and emergency patch for one of their products. Along with the news, they had to embarrassingly admit that the previously intended responsible bug reporter had been trying to report the bug since February without success.

There is a beloved reporting concept known as responsible disclosure, in which the bug finder/reporter conveys the found bug to the involved vendor and gives them a reasonable amount of time (usually measured in months) before publicly reporting. This gives the vendor time to access the bug, and if the vendor agrees it’s something that they need to patch, they then create, test, and make available a patch to best protect their customers. The responsible disclosure bug reporter usually gets a favorable mention in the vendor’s vulnerability disclosure, some positive press, and sometimes monetary compensation. ?

The opposite of responsible disclosure is a bug finder simply releasing the bug and related exploit code to the general public (and malicious hackers) without first giving the vendor time to assess and respond. Most of us in the cybersecurity world like the idea of responsible disclosure. A minority likes the idea of immediate public disclosure because they believe it forces the vendor to deliver better, more secure code faster than responsible disclosure.

I’ve always been a big responsible disclosure fan because publicly releasing the details of an exploitable bug without allowing impacted customers to simultaneously download a patch simply causes more overall harm than responsible disclosure. Vendors can’t eradicate every bug. There will always be exploitable bugs, without or without immediate public disclosure. So, I default to protecting customers with readily downloadable patches whenever possible.

In Delinea’s case, and in thousands of other prior similar exploitable vulnerability instances, the bug finder/reporter was trying to do the right thing (i.e., responsible disclosure), but either they could not find a way to do so or were blown off by the vendor when they initially reported it. In frustration, many of these well-intentioned bug reporters decided to release the details of the bug in order to better protect impacted customers instead of letting the world be blind to the bug and only be exploited by malicious actors who also knew of the bug.

I don’t want to blame Delinea alone. I bet more companies than not don’t have easy ways to see bug reporting pathways. It’s not required and it’s not easy to see what you need when you’re heads down developing products. Nearly every big development vendor in the world, including Microsoft, had similar problems early on when they were young companies. Making it easy for people to report possible bugs seems to be a common learning curve along the maturation process for development firms.

But to be clear, all companies providing software, firmware, or services, need to make it very easy and broadly visible using multiple channels for bug reporters to contact them to report bugs.

How?

Every way you can.

Here are some ideas:

Create a “security@” email address in your domain where anyone can report a suspected bug. That email address should be actively monitored and every report responded to by a real person (and not just an auto-reply). The bug reporter should “feel heard” and listened to. They should understand what the reporting process will look like along with estimated timelines. This assumes the vendor also has a written and communicated bug reporting policy that the company has agreed to support.

All development vendors should have an easy-to-find web page dedicated to bug reporting. If agreeable, it should be a page linkedfrom the main web page or at least easily discoverable in the list of links at the bottom (along with Contact Us and Our Company).

Every development company should offer an in-house or use a public bug bounty program, like Bugcrowd.com or Hackerone.com. You want bug finders who want to be paid for finding bugs given an easy way to do so. Google paid $10M in bug bounties last year (https://www.infosecurity-magazine.com/news/google-paid-10m-bug-bounties), and you haven’t read about a lot of bad Google bugs being widely exploited in the wild. It’s not accidental.

Development companies should actively monitor common sites where users might follow your product and report bugs, like user communities, CVE-MITRE, CERT, and CISA. Not everyone knows how to find a vendor’s security web page, even if it exists. So, monitor the places they may end up reporting bugs to.

Another suggestion, don’t attack or dismiss bug reporters. I know, as a development vendor, it can be hard at times. I know that 90% of the “bugs” that are reported to you aren’t really bugs, can’t be reproduced, or lack effective documentation. I know that some bug reporters seem more like malicious hackers and extorters than responsible disclosure advocates. There are buttheads in every group.

Teach your bug monitoring team to treat all bug reporters with the utmost care. I know of dozens of initially well-meaning bug reporters who were turned into immediate, hostile disclosure types by being prematurely dismissed or even insulted. Even if you suspect their bug isn’t really a bug, work with them gently to help them understand that. It's all about tone.

On top of that, I know of a hundred bug reports that the vendor initially and somewhat forcefully blew off as “not a bug” or determined was functioning “as designed”, who later, after the bug was publicly disclosed in the press, had to do a mea culpa! Even if you think the reported bug isn’t a bug (or can’t confirm it), don’t disrespect the reporter. The best bug reporting programs understand that they are partly goodwill ambassadors for the company. Don’t let a team member turn a responsible disclosure reporter into a hacker that wants to see the downfall of your company and product.

In general, don’t let poor planning, visibility, and policy turn a good-natured bug reporter into a potential adversary. Make it easy for them to report bugs and handle them like the well-meaning cooperators that they usually are.