The researcher who can't find your front door

Somewhere right now a security researcher, a curious customer, or a well-meaning stranger has noticed something wrong with your product — an exposed endpoint, a leaking token, a misconfigured bucket — and is trying to figure out how to tell you. If you have not made that easy, one of three things happens, and two of them are bad. They give up and the bug stays live. They post it publicly out of frustration and you learn about it the same moment your customers do. Or, in the lucky case, they dig until they find an email and report it — and then discover nobody is watching that inbox.

A vulnerability disclosure program (VDP) is the fix, and it is one of the highest-leverage things a lean team can stand up in an afternoon. It is not a bug bounty — you are not promising to pay — it is simply a published, honest answer to one question: if you find a security issue in our product, here is how to tell us, here is what we promise, and here is what we ask of you. That single channel converts unsolicited goodwill into a tracked finding with an owner and a clock, instead of a surprise.

The three pieces, and none of them are expensive

A working VDP has three parts, and a small software business can put all of them in place without a dedicated security hire.

  • A reachable intake. A monitored address — security@ your domain — or a simple web form. The cardinal sin is a channel nobody reads; an unwatched intake is worse than no intake because it manufactures the impression that you ignored a warning.
  • A published policy. A short page that sets expectations: what is in scope, what you ask researchers not to do (no data exfiltration, no service disruption, no testing other people's accounts), how fast you will acknowledge, and your commitment not to pursue legal action against good-faith research. This safe-harbor language is what makes serious researchers willing to engage.
  • A security.txt file. A tiny, standardized text file served at /.well-known/security.txt that points researchers to your contact and policy. It is the machine-readable signpost that says "report here," and it is the difference between a researcher finding your front door in five seconds versus giving up. Pair it with the rest of your public-facing posture story on your trust center page.

That is the whole apparatus. Intake, policy, signpost. The hard part was never the setup — it is the discipline of actually handling what comes in.

A report is a finding, not an email to admire

The moment a report lands, the clock starts, and the worst outcome is a thoughtful disclosure that decays in an inbox. Treat every inbound report as a finding the instant it arrives: acknowledge it, assign an owner, and set a severity based on what the issue actually exposes — the same exposure-first triage you apply to your scanner output.

  • Acknowledge fast, even before you have answers. A same-day "we got this, we're looking" reply is what keeps a researcher from going public out of silence. The acknowledgement is a commitment you should be able to meet every time.
  • Triage by impact, not by who reported it. An auth bypass from an anonymous tip outranks a low-severity header issue from a famous researcher. Rank by what the bug reaches, with the same prioritization logic — CVSS for the base impact, real-world exploitability on top — that governs the rest of your queue.
  • Route it into the workflow you already run. A disclosed bug is not a special category; it is a finding with an owner, a severity, and a remediation SLA. The only thing different is the source. Folding it in means it inherits the same tracking and the same proof-of-closure as everything else.
  • Close the loop with the reporter. Tell them when it is fixed. Researchers remember who treated them well, and that reputation is what brings you the next report instead of the next public dump.

How it fits the program you already have

A VDP is not a bolt-on — it is an inbound feed for the attack-surface work you are already doing. Your scanners and penetration tests find what you thought to look at; outside researchers find the thing you did not. The reports that come through a disclosure channel are some of the highest-signal findings you will ever get, precisely because they come from someone motivated enough to look where you did not.

That inbound stream also feeds the rest of the loop. A serious disclosed vulnerability may trip your incident response plan if it turns out to have been exploited. The pattern of what gets reported is a real input to your posture score. And "do you have a vulnerability disclosure process?" is increasingly a line item on the security questionnaires your enterprise prospects send — having a published VDP is a clean, evidence-backed yes.

It feeds the framework review, too. Assessors and customers ask how external parties report security issues to you — SOC 2's communication and monitoring criteria, ISO 27001's vulnerability and incident-management controls. Your published policy, your acknowledgement timestamps, and the disclosed findings you have closed are exactly the evidence they look for, folded into the same continuous-evidence loop as the rest of your program.

One honest caveat: a platform can help you intake disclosed reports as findings, route them to owners, track them to closure on an SLA, and keep that evidence current for an auditor or a customer questionnaire — it organizes, tracks, and proves the work. It does not write your disclosure policy, monitor your intake for you, decide your safe-harbor terms, make you compliant, or grant or guarantee any certification; the policy, the legal commitments, and the actual fixes are operational and legal decisions your team and your counsel own.

A stranger trying to warn you is a gift, and most teams fumble it by having no door to knock on. Publish a security.txt, write a short honest policy with safe-harbor language, watch the inbox, and treat every report as a finding with an owner and a clock. You will catch the bugs your own tools missed — and turn would-be public dumps into quiet, tracked fixes.