Into the Void: Navigating Security Silence

I’ve eluded to this in a few of my previous posts, but I think it’s about time I do a write up on the issues I have with responsible disclosures. Much of the below will be my experience with responsible disclosure, as well as my experiences within the security industry.

So, let’s dig straight into it.

What Is Responsible Disclosure?

Responsible disclosure is the process of reporting discovered vulnerabilities to a company or individual. Simple in principle, but much more nuanced in practice.

Responsible disclosure is a catch all term for this, there’s no defined process or procedure that a tester should follow to report vulnerabilities, nor is there a framework in-place by most companies to receive said reports. It’s down to the tester to report this in a manner that they feel is fitting and for the receiving company or individual to do with that as they wish.

Walking A Fine Line

If you decide to start reporting vulnerabilities, you’ll quickly find that there’s simply no consensus on what is considered “Just” or “correct”. When I began reporting vulnerabilities I did everything I could to pull data from third parties and never interact with any internal data, as I felt that was crossing a line from ethical to unethical.

However after doing this for a while now, my idea of what was the “correct” way of doing this has changed. I’ll still use third party datasets and report wherever possible from this data, however if I need to dig into this and query that data myself, I’ll do that to ensure that the report reaches the right people and with the right information. This digging into the data will still be very light touch, but enough to ensure that the report is detailed enough to be relevant and useful.

This is something I’ll come back to later, but within the United Kingdom what I’m doing is considered legal and within the bounds of the Computer Misuse Act, however this is not the case everywhere.

All Quiet On The Front

So lets start off with my main issue when it comes to reporting, silence. I’ve sent out reports for dozens of issues at this point and for the most part I’ve had zero response to the issues i’ve raised. I’ll admit that some of the issues I’ve raised could be considered Low or Informational findings, however in some cases High or Critical vulnerabilities do come along and I receive the same enthusiastic silence from the companies hosting the data.

This is by far my biggest gripe, idleness and ignorance from companies.

Much of the time I’ll follow the below steps in descending order when trying to report;

• Check for a security.txt file
• Check for a security or IT team email on the website
• Check if they’re signed up to a bug bounty site
• Reach out via contact form or live chat
• Reach out to any available email on their site
• Check to see if usual email addresses exist and ping an email off to them
• Contact via Social Media

After exhausting all of these steps and finally finding a way to contact the company, you’ll still likely receive no response back. The reasons for this ignorance tend to fall into a few different categories;

• The company doesn’t actively check their emails, messages or support tooling
• The company has given your report a cursory glance and decided to ignore you for a specific reason
  • The company believe your report to be false
  • The company don’t understand the significance of the report
• The company are burying their head in the sand and hoping you’ll go away
• The company are preparing to threaten legal action

Generally you won’t be aware of which of these options they’ve taken (until the legal threats come through), but these tend to be the most popular reasons to be ignored in my professional experience.

Mitigating Ignorance

Whilst you can’t outright stop companies being ignorant, you can make your initial high-level report compelling enough that it’s hard to ignore.

When making these reports myself, I make sure to outline some key points that make it clear the report is real, without giving away too much. If, for example, I’d found an exposed database with highly sensitive data, I might state that I’ve found a database related to (x) containing (x) gigabytes of data. This shows the report is tailored to the company, and they can check their own systems to confirm what you’ve stated is accurate.

Furthermore, providing a small snippet of a larger dataset can be a valuable way to prove the vulnerability exists. If you have a large JSON file, for example, a few lines from it can go a long way to proving your legitimacy. Just be aware that sending this data to the wrong people could be damaging.

A few other things help a report land, and help you if things turn sour later:

• Say what happens next. Let them know when you’ll follow up, and whether you plan to write about it once it’s fixed. A clear timeline gives a busy team a reason to move it up the pile.

• Keep samples small and redacted. Mask most of each value (j****@g****.com) and send only enough to prove the point. The less personal data you hold or pass on, the better.

• Put the impact up front. One or two plain sentences on what’s exposed and who it affects, before any technical detail. The person reading it may not be technical, and they need to know why it matters to them.

• Keep a record. Note when you found the issue, what you accessed and every attempt to make contact. If anyone questions your intentions later, a dated paper trail showing you acted in good faith is worth its weight in gold.

Food For Thought

Earlier I said I’d come back to the law, so here it is. In the UK, the Computer Misuse Act 1990 makes it an offence to access a computer without authorisation, and it has no public-interest or good-faith defence. A database being left open to the internet is not the same as you being authorised to query it. In practice, a researcher acting in good faith is relying on the discretion of companies and prosecutors, not on anything written into the law.

That may be about to change, slowly. In December 2025 the Security Minister said the government was looking at a statutory defence for security researchers. In February 2026 a Home Office minister told MPs a limited defence was being developed. In May, the King’s Speech confirmed Computer Misuse Act reform will be part of a new National Security Bill. At the time of writing, though, nothing is law, and nobody outside government knows exactly what the defence will cover.

And the UK is one of the friendlier places to do this. Some countries have no concept of responsible disclosure at all, and the person who reports a problem is treated as the person who caused it.

Which brings me back to silence. The company that ignores your report is often the same one that later reaches for its solicitors, and the law currently gives them plenty to work with. So a few thoughts for both sides.

For companies:

• Publish a security.txt file (RFC 9116). It takes five minutes and tells researchers exactly where to send a report.
• Have a simple vulnerability disclosure policy: what’s in scope, how to report, and a promise not to take legal action against people who follow it in good faith.
• Acknowledge reports, even with an automated reply. Silence helps no-one and may lead to the issue being made public
• Make someone responsible for reading the damn inbox. So many reports are just never read, it’s infuriating

Wrapping Up

Responsible disclosure should be simple: someone finds a problem, tells the people who can fix it, and they fix it. In reality it’s a patchwork of guesswork on both sides, with the researcher carrying most of the risk and companies carrying most of the data.

I’ll keep reporting, because the alternative is leaving people’s data out in the open for someone with worse intentions to find. But it would be nice if, one day, the hardest part of the job was finding the vulnerability rather than finding someone willing to hear about it.