How to Deal with Incoming Security Reports

Sometimes developers and security researchers find bugs accidentally or when intentionally testing software security. If they are ethical, they would then report these security issues to the software vendor so that they could fix them.

Even during the past weeks, we’ve seen friction between researchers and vendors where vulnerability reports don’t get enough attention and where communication is lacking. I think it’s a great opportunity to look into how this could be done better.

Let’s imagine you received a security report that indicates a vulnerability in your website or software.

What should be the first steps, how should you react, and how quickly should you address the issue?

Validate the report first

Some reports are valid, others are not. We also see reports which we separately categorise as “beg bounty” – these are security reports which often over-dramatise individual configuration choices (such as not using all possible security headers) as severe security vulnerabilities and then ask for a bounty payment before providing full details.

Unfortunately, the volume of such reports is quite high, so if you want to save time without the risk of missing the very important vulnerability reports, consider using a third-party managed vulnerability disclosure program provider, who does such validations for you.

Also, make sure that you know where your security reports are. Many companies still don’t have a clear contact on the website for security reports, so the reports are sent to support and other emails, where it does not get in front of the right person and may become ignored completely.

Have an open communication with the researcher

If the report is valid, respond to the reporter immediately and let them know that you’ve received the report and will be doing a more in-depth analysis within the next few work days to come up with a timeline for the patch.

Consider that some of the security researchers are less patient than others, so to avoid any misunderstandings that could result in the vulnerability becoming disclosed before it’s fixed, provide the researcher regular updates about your process.

Also, keep in mind that the researchers don’t owe you anything, so demanding that they go through your process might not have a lot of success and could even cause friction that ends with pre-patch disclosure.

One great way to incentivise the security researcher to follow your timeline and stay patient is by rewarding them with bug bounties.

Researchers always prefer money as the reward, but it’s common to also send merch and other goodies as a gesture of appreciation.

Stay transparent and build trust

Your users should hear about the patch from you first and not from anyone else.

Consider releasing security fixes in a separate update (not combined with other bug fixes and features). Communicating it as a “security update” makes it very easy for users to understand and to prioritise.

Being transparent on your changelog is essential, but security updates should also be covered in a blog post and sent to users via email.

Keep in mind that this is also an opportunity for the vendor to show a professional approach to security and build trust with its users and customers.

Conclusion

It’s best to see security researchers as contributors to open-source software. They help to improve and secure the code.

Security reports should be handled with top priority, regardless of the severity, because it provides an opportunity to exercise the incident response process and make sure it’s well organised for the possible future critical security reports.

Such a professional approach is what users also want to see from the vendors they’ve chosen to trust.