+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

When a stranger emails to say you have a bug

Security By Mits Engineering Team 2 min read
When a stranger emails to say you have a bug

One day an email arrives from someone you have never heard of saying they found a security flaw in your product. What happens in the next few hours determines a great deal: whether you learn about your other flaws from researchers or from attackers, and whether this particular person works with you or writes it up publicly. Most companies handle this badly, and the worst version — responding with a legal threat — reliably converts a helpful stranger into a hostile one with an audience.

The first fix is having somewhere for the email to go. A security contact published on your website, and a security.txt file at the standard location, means a finder does not have to guess. Reports sent to a general support inbox get triaged as customer queries, sit for days, and occasionally get closed as not reproducible by someone who did not understand them. That delay is what pushes researchers toward publishing.

Publish a short policy alongside it, because the finder's main worry is legal risk. Say what testing is permitted, what is out of bounds — no accessing other people's data, no denial of service, no social engineering of staff — and commit that you will not pursue legal action against anyone who follows it. That safe harbour statement is the single thing that most increases the quality of reports you receive, because serious researchers avoid companies that have not made it.

Then respond like a professional even when the report is weak. Acknowledge within a day. Say whether you could reproduce it. Give a rough timeline for the fix and tell them when it ships. Many reports will be duplicates, out of scope, or non-issues — a scanner output pasted into an email, a missing header that is not exploitable — and a courteous explanation of why costs five minutes and keeps the channel open. Silence, or a dismissive reply, closes it permanently.

Distinguish a disclosure policy from a bug bounty. A policy costs nothing but attention and is appropriate for almost every company. A paid bounty attracts far more volume, including a great deal of low-quality submission, and needs someone to triage it and a budget that does not run out mid-quarter. Running a bounty badly — slow payment, disputed severity, moved goalposts — damages your reputation among exactly the community you were trying to engage. Start with a policy and add money only when you can handle the traffic.

Fix and credit. The fastest way to build a reputation as a company worth reporting to is to ship the fix promptly and publicly thank the finder, with their permission. Researchers talk to each other, and a company known to respond well gets told about problems early and quietly. A company known to ignore or threaten gets told about them at the same time as everyone else.

Need help with this? Explore our Cybersecurity & Compliance services. Learn more Back to all news

Keep reading

More on Security