TL;DR
Get privacy and security gear delivered free — and shop member deals
- Fast, free delivery on millions of items
- Access to Prime Big Deal Days deals on October 6–7
- Prime Video, Amazon Music and more included
A responsible disclosure inbox is a dedicated, published channel (usually security@example.com plus a /.well-known/security.txt file) where outside researchers can send vulnerability reports. Building one takes a week: pick an address, write a one-page policy, set up triage, and commit to response times. The hard part isn’t the inbox — it’s responding quickly, saying thank you, and not threatening the people helping you.
On a quiet Saturday morning in 2021, a Norwegian fitness app discovered that everything its users had ever logged — workouts, weight, sleep, mental health notes — was exposed in an unsecured database. The outsider who found it had tried to warn the company. He just couldn’t find anyone to tell. No email alias, no contact page, no security.txt file. The data sat open for days while he searched.
That’s the failure a responsible disclosure inbox prevents. It’s not fancy security tooling. It’s a published address — security@yourcompany.com — plus a short policy and a process for reading what arrives. Big companies have formal programs with bounties and platforms. You don’t need any of that to start. You need a mailbox someone actually checks.
In this guide, you’ll learn how to build the whole thing: the address, the policy, the RFC 9116 security.txt file that helps researchers find you, how to triage reports without panic, and how to respond so researchers come back instead of going public out of frustration.
Publish a dedicated alias (security@yourdomain.com) backed by a one-page good-faith policy — this is the entire minimum viable disclosure program, buildable in…
Add an RFC 9116 security.txt file at /.well-known/security.txt so automated tools and researchers can discover your contact without hunting through your footer.
Acknowledge every report within 72 hours even before you’ve assessed it — silence is the number one driver of premature public disclosure.
Triage with a simple severity table (critical/high/medium/not-a-bug) and track everything in a shared log so repeat issues have history.
Test your own inbox quarterly with a fake report; a dead alias is worse than no program because it signals you don’t care.
Security field guide · 01
How to Build a Responsible Disclosure Inbox
A practical, one-week guide to giving security researchers a clear way to reach you, a fair policy to work within, and a timely response when they do.
Five habits that make reporting work
A small, reliable program makes it easier for someone who finds a flaw to help you fix it before it becomes an incident.
Set up security@yourdomain.com and back it with a short good-faith policy.
Add /.well-known/security.txt and link a security page from your site.
Reply within 72 hours, even when you still need time to investigate.
Use a simple severity scale and log reports in a shared tracker.
Send a quarterly test report. A broken alias leaves researchers without a route.
A clear front door changes the outcome
A disclosure inbox is a published email address for people outside your organization to report vulnerabilities, supported by a policy that explains what happens next.
In 2021, a Norwegian fitness app’s unsecured database exposed users’ workouts, weight, sleep, and mental health notes. An outsider tried to warn the company, but could not find a security contact. The data remained exposed while he searched.
A security alias gives researchers a direct route. A policy tells them which systems are in scope, how to report safely, and what response to expect. For a small team, that is enough to begin.
Big-company bounty platforms and tracking software can come later. The essential resource is a mailbox that someone checks and a team that responds with care.
The five building blocks
Complete these steps in a working week. None requires a dedicated platform or a bounty budget.
Create the alias
Use security@yourdomain.com. Route it to at least two people so one absence does not silence it.
Write the policy
Name covered domains, apps, and APIs. Explain exclusions such as physical attacks, social engineering, and denial-of-service testing.
Publish security.txt
Place the plain-text file at /.well-known/security.txt with your contact and policy URL.
Link it clearly
Add the contact to your footer, contact page, and a simple /security page.
Set response times
Commit to acknowledging every report within 72 hours, even if investigation is still underway.
Promise a safe, good-faith process
Keep the policy to one page. State what is in scope, what is excluded, how to report, and how you will respond. Plain language earns trust.
Include the essentials
- Scope: the domains, apps, APIs, or products covered.
- Safe testing: avoid accessing, changing, or deleting other people’s data.
- Exclusions: name prohibited or out-of-scope testing clearly.
- Good faith: commit not to pursue legal action for compliant research.
- Expectations: give a 72-hour acknowledgment target and update cadence.
Security.txt starter
Sort the report before you solve it
Triage means checking validity, severity, and ownership. Acknowledge receipt first, then investigate and share a realistic next step.
| Severity | Example | Response target | First action |
|---|---|---|---|
| Critical | Authentication bypass, exposed database, remote code execution | Same-day acknowledgment | Start incident handling and urgent mitigation |
| High | Stored XSS, IDOR exposing other users’ data | Acknowledge within 72 hours; aim to fix within 2 weeks | Assign an owner and update the reporter |
| Medium / Low | Reflected XSS, verbose errors, missing headers | Acknowledge within 72 hours | Schedule through normal work |
| Not a bug | Scanner output or out-of-scope findings | Reply politely | Explain the decision and thank the reporter |
Record report date, reporter, summary, severity, status, owner, and resolution date. A spreadsheet is enough to start.
Do not argue severity in the first reply. Confirm receipt, give a realistic timeline, and keep the researcher informed.
The first 48 hours set the tone
For a serious report, quick communication and clear ownership can turn a stressful discovery into a focused fix.
Reply promptly
Thank the researcher, confirm you received the report, and tell them when they can expect the next update.
Assign an owner
Verify the issue safely, assess affected systems and data, and involve the right engineering or incident lead.
Share progress
Set a realistic fix plan. Keep the reporter informed, then thank them again when the issue is resolved.
From hidden flaw to safer product
A good disclosure process gives both sides a clear next step at every stage.
What a Responsible Disclosure Inbox Actually Is (And Why You Need One)
A responsible disclosure inbox is a single, published email address that accepts security vulnerability reports from anyone outside your organization, backed by a short policy promising you won’t sue or ban the people who use it. That’s the whole machine. Everything else — bug bounty platforms, tracking software, SLA dashboards — is an upgrade, not a requirement.
Think about what happens without one. A researcher finds a flaw in your login flow at 11 p.m. They check your website’s footer. Nothing. They try info@, support@, the contact form. The form rejects their message because it contains code snippets that look “suspicious.” Three days later, they post to a public mailing list, or worse, they shrug and move on — and the flaw stays live.
The inbox flips that dynamic. When researchers know where to report and what happens next, the overwhelming majority behave responsibly. vultrade.com’s experience tracking vulnerability disclosures aligns with industry patterns: most independent researchers simply want acknowledgment and a fix — payment is a bonus, not the price of cooperation.
And size doesn’t matter. A two-person SaaS startup has the same exposure as an enterprise — sometimes more, because attackers know small teams skip security basics. Your inbox is a smoke detector. Cheap, boring, and priceless the one day you need it.
The 5 Building Blocks: How to Set Up Your Inbox in a Week
Setting up a responsible disclosure inbox takes five steps, and you can reasonably finish them all within one working week. None of them require buying anything.
- Create a dedicated alias — security@yourdomain.com. Route it to at least two people so a single vacation doesn’t silence the channel for two weeks.
- Write a one-page policy — what’s in scope (your domains, apps, APIs), what’s out (physical attacks, social engineering, DDOS testing), and what reporters can expect from you.
- Publish a security.txt file at
/.well-known/security.txtper RFC 9116, pointing to your contact and policy URL. - Link it visibly — footer, contact page, and a /security page on your main site. Discoverability is the entire game.
- Set a response commitment — acknowledge every report within 72 hours, even if the answer is just “received, we’re looking.”
Here’s a concrete scenario. Imagine you run an e-commerce platform and a researcher notices your password reset token appears in the URL, leaking into analytics logs. With no inbox, that report dies. With your new setup, it lands in security@, gets acknowledged Monday morning, and your team rotates the token scheme by Friday. Total cost: one developer-day. The alternative — a leaked credential incident — costs far more in money and trust.
The security.txt file deserves special attention. It’s four lines of plain text, standardized in RFC 9116 (April 2022), and tools that crawl for security contacts now read it automatically. Skip it and you’re hiding your front door behind a hedge.
How to Triage Incoming Reports Without Panic
Triage means sorting each report by severity and validity within 72 hours — nothing more. You’re not fixing anything yet. You’re deciding what it is, how bad it is, and who owns it.
Expect your inbox to contain a mixed bag. Roughly speaking, most inbound reports to small programs fall into three buckets: genuine vulnerabilities, low-value noise (missing headers, “self-XSS” that requires the victim to paste code into their own browser), and the occasional automated scanner dump. The noise is annoying but harmless. The gems are why the inbox exists.
Use a simple severity frame when you read each message:
| Severity | Example | Target response |
|---|---|---|
| Critical | Authentication bypass, exposed database, RCE | Acknowledge same day, begin fix immediately |
| High | Stored XSS, IDOR exposing other users’ data | Acknowledge in 72h, fix within 2 weeks |
| Medium/Low | Reflected XSS, verbose errors, missing headers | Acknowledge in 72h, schedule normally |
| Not a bug | Scanner output, out-of-scope findings | Polite close-out, thank them anyway |
One habit worth building: never argue severity in the first reply. Acknowledge, confirm receipt, give a realistic timeline. A researcher who reported an exposed S3 bucket once waited nine days for a reply that said only “we’ll look into it” — and that nine-day silence was what pushed him to publish. The bug was fixed in an hour once work started. The gap wasn’t technical. It was communicative.
Keep a shared tracker — even a spreadsheet — with the report date, reporter, summary, severity, status, and resolution date. When the second report about the same subsystem arrives in six months, you’ll want the history.
Write a Policy That Protects Both You and the Researcher
Your disclosure policy is a promise: report in good faith, stay in scope, and we won’t take legal action against you. That single sentence does more to protect your organization than any firewall rule, because it converts potential adversaries into unpaid auditors.
Keep it to one page. Researchers won’t read page four of a terms-of-service-style document, and legal teams that write ten-page policies often smuggle in language that scares reporters away entirely. A good policy answers four questions: what’s in scope, how to report, what you promise, and what you ask in return.
What you ask in return is usually three things: give us reasonable time to fix before publishing (90 days is the widely used norm), don’t access or exfiltrate other users’ data, and don’t run destructive tests against production. Be explicit that finding a bug is welcome while downloading a customer list to prove it is not.
A policy that threatens legal action for “unauthorized access” without a good-faith exception doesn’t reduce your risk — it just moves the vulnerability reports from your inbox to a public forum.
A real-world pattern makes this concrete. Companies with hostile or absent policies show up repeatedly in disclosure dramas where a researcher publishes after being ignored or threatened. Companies with clear good-faith protections quietly fix dozens of issues nobody ever hears about. The quiet outcomes are the wins. Aim for boring.
If you want to reward reporters, you don’t need a formal bounty program. Swag, public thank-yous (with permission — many researchers prefer anonymity), or donations to a charity of their choice all work. What they remember most, anecdotally, is whether you answered.
What to Do When a Serious Report Lands
When a critical report arrives, your first 48 hours decide whether this becomes a footnote or an incident. The sequence is simple: verify, contain, fix, communicate, credit.
First, verify. Reproduce the issue in a staging environment if you can. If the researcher included steps, follow them exactly. A surprising number of “critical” reports turn out to be the researcher’s own misconfiguration — and a polite correction saves everyone embarrassment. But verify before you discount, never after.
Then contain. If customer data is exposed, that’s a different track entirely — you may have breach-notification obligations under GDPR (72-hour regulator notification), or state laws in the US. Involve legal counsel early for anything touching personal data. This is exactly why the disclosure inbox routes to at least two people: one technical, one who can pull the alarm on process.
Fix, and when you deploy the fix, tell the reporter it’s live. Then, after your agreed window, publish something — a changelog entry, a blog post, a CVE if the issue warrants one. An anonymized researcher who reported an authentication flaw to a mid-size fintech described the most satisfying moment of the exchange not as the bounty, but as seeing the fix announced publicly with his handle credited. Recognition is currency.
Finally, do a short retrospective. Why did the flaw exist? What would have caught it? One question per incident, answered honestly, compounds into a genuinely harder-to-break system within a year.
Common Mistakes That Quietly Kill Disclosure Programs
Most disclosure programs don’t fail loudly — they rot. Reports go to an alias nobody monitors because the one person who owned it left the company 18 months ago. The security.txt file points to a dead email. The policy page still promises 24-hour responses the team hasn’t met since launch.
The fix is maintenance, and maintenance is calendar-based. Every quarter, send a test report to your own alias and confirm it arrives and gets acknowledged. Once a year, reread your policy and response-time promises and adjust them to reality. A promise you can’t keep is worse than a modest one you can.
A few failure patterns to watch for:
- The single-owner inbox — one departure creates total silence. Always route to two or more people.
- Legal-first responses — replying with an NDA before saying “thanks, we got it” reads as hostility and burns goodwill instantly.
- Ghosting after the fix — fixing the bug but never telling the reporter leaves them unsure whether to publish, and uncertainty breeds premature disclosure.
- Scope creep in reverse — demanding researchers test only on a staging server that’s six months behind production, which finds nothing real.
The last one deserves emphasis. If your staging environment doesn’t reflect production, in-scope testing there is theater. Researchers will figure that out and quietly stop bothering. Give them real targets with clear boundaries, or don’t bother inviting them at all.
Frequently Asked Questions
Do I need a bug bounty platform like HackerOne to accept vulnerability reports?
No. Platforms add structure, researcher pools, and payment handling, but they’re an upgrade rather than a prerequisite. A dedicated email alias, a one-page policy, and an RFC 9116 security.txt file form a complete minimum viable program. Many organizations run on exactly that for years before considering a paid platform.
What is a security.txt file and where does it go?
It’s a small plain-text file standardized in RFC 9116 (April 2022) that tells researchers how to contact you about security issues. Place it at https://yourdomain.com/.well-known/security.txt. It typically contains a Contact field (your security@ email or URL), an Expires date, and optionally a link to your policy and preferred languages.
How fast do I need to respond to a vulnerability report?
Acknowledge within 72 hours — even a two-line “received, we’re investigating” counts. Actual fixes can reasonably take 30–90 days depending on severity, and 90 days is the community norm for the window before a researcher may publish. Silence, not slowness, is what pushes reporters to go public.
Should I pay researchers who report vulnerabilities?
Payment is optional at the program level. Most independent researchers are motivated by acknowledgment, a real fix, and (with permission) public credit. If you do pay, you don’t need formal bounty tiers on day one — gift cards, swag, or donations work for small programs. Consistency matters more than amount.
Can I get in legal trouble for running a disclosure program?
The risk runs the other direction: a policy without a good-faith safe harbor can expose researchers to computer-misuse laws, which discourages reporting and pushes findings public. Your policy should explicitly promise no legal action against good-faith, in-scope research. Have counsel review the wording — but the absence of a policy is the riskier position, not its presence.
Conclusion
If you do one thing after reading this, do this: create the alias, publish the four-line security.txt file, and tell two people they own it. That’s under an hour of work, and it converts your organization from invisible-and-unreachable to findable-and-responsive — the single biggest variable in whether an outside researcher helps you or routes around you.
The database that leaked in Norway didn’t leak because the flaw was sophisticated. It leaked because the person who found it knocked on a door that wasn’t there. Build the door. Answer it. Everything else is refinement.
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
