Vulnerability Disclosure Programs: Why Even Small Teams Need One
A vulnerability disclosure program is a public document that tells security researchers how to report issues to you, what they can expect, and what is in scope. It is not a bug bounty. It does not have to pay anyone. It exists so that when a researcher finds a problem in your product, they have a path that does not end in a public tweet. The setup is hours. The protection is real.
What you actually need to know
- A VDP is a policy, not a payment program. It costs nothing to set up.
- The setup is hours: a security.txt file, a short policy page, and a path to triage.
- Without a VDP, researchers have no good way to report issues, and you lose the early warning.
- The basic floor includes scope, safe harbor language, response expectations, and acknowledgments.
- Even teams of three benefit. The cost is minor and the protection is real.
Component
Effort
Value
security.txt file
10 minutes
High; standard discovery path
Public VDP policy page
A few hours
High; sets expectations
Safe harbor language
A few hours
High; encourages reporting
Triage workflow
A day
High; ensures reports get acted on
Public acknowledgments page
A few hours
Moderate; goodwill with researchers
Bug bounty (optional)
Ongoing
Higher engagement, higher cost
The core argument
A vulnerability disclosure program is the cheapest security insurance a startup can buy. It costs hours to set up. It prevents the worst version of every incident: the version where a researcher finds a serious issue, cannot reach anyone, and posts it publicly out of frustration.
Most teams skip it because they have not thought about what they would do if someone reported a vulnerability. The thinking is "we will figure it out if it happens." That is fine for many things and not fine for security reports, because security researchers work on a clock. They give you a window to respond. If you do not, they disclose. The window can be 90 days for a major issue or 24 hours for a minor one, depending on the researcher and the severity.
A VDP solves the cold start problem. It tells researchers where to send reports, what to expect, and that they will not be sued for reporting. The cost is hours. The benefit is that the next time a researcher finds something, they have a path that ends in a fix instead of in a tweet.
The other benefit is institutional. Having a VDP forces the team to think through what happens when a security report arrives. Who triages? Who decides severity? What is the communication plan? These questions need answers anyway. The VDP is a forcing function.
What goes into a basic VDP
security.txt
A small text file at /.well-known/security.txt that points to your reporting contact. Researchers check for it. Adding it takes ten minutes. There is no reason not to have one.
A policy page
A page on your site that describes the program. Scope (which systems are covered), safe harbor (what researchers can do without legal risk), expected response times, and what happens after a report. Keep it short and clear.
Safe harbor language
The language that tells researchers they will not be sued for reporting in good faith. This is critical. Without it, researchers who find issues may hesitate to report because the legal risk feels real. With it, you encourage the reports you actually want to receive.
A triage workflow
What happens when a report arrives. Who reads the email. How severity is decided. Who communicates with the researcher. What the SLA is. The workflow can be lightweight for small teams but needs to exist.
Public acknowledgments (optional)
A page that lists researchers who reported valid issues, with their consent. This is free goodwill. Researchers value recognition. The page makes the program feel real.
How long does it take
Stage
Time
Notes
security.txt
10 minutes
Just add the file
Policy page
A few hours
Use templates from disclose.io
Safe harbor language
An hour
Adapt from public examples
Triage workflow
A day
Decide who and how
Public acknowledgments
A few hours
Optional but valuable
Total to get to baseline
A day
Real protection
What a healthy VDP looks like in operation
- A clear, public policy page that is easy to find.
- A monitored email address with a defined SLA for first response.
- A named owner for triage, even if it is the CTO for the first year.
- A workflow that decides severity quickly.
- Communication with the researcher throughout the resolution.
- An optional acknowledgment page that the researcher can opt into.
Expert opinion
The teams that get into trouble with security disclosures almost never have a VDP. The researcher finds a bug, cannot reach anyone, gives up, and the issue becomes public. Setting up a VDP takes a day. The protection against the worst case is enormous. The fact that more startups do not have one is mostly a failure of awareness, not a real weighing of cost against benefit.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A SaaS company I worked with received an email from a researcher who had found a serious vulnerability. The researcher had spent two days trying to find a way to report it before resorting to a generic support address. The support team had almost dismissed the email as spam.
We set up a VDP that week. A security.txt file, a public policy page, and a dedicated email. Three months later another researcher found a smaller issue and reported it through the new channel. The time from report to fix was four days. The relationship with both researchers stayed positive. No public disclosure was necessary. The total cost of the program had been one engineer's day, and the avoided cost of a public disclosure was hard to even put a number on. The pattern is in the bug bounty decision: when you are ready, when you are not and the broader building a security program from zero.
Common mistakes
- Not having a VDP because "we are too small."
- Burying the security email so deep that researchers cannot find it.
- Promising response times you cannot meet.
- Not including safe harbor language, which discourages reports.
- Treating reports as nuisance instead of as free security testing.
- Failing to acknowledge researchers who reported real issues.
- Confusing a VDP with a bug bounty. The first is free. The second is optional.
A 30 day plan to launch a VDP
- Day one. Add a security.txt file pointing to a dedicated email address.
- Days two to four. Write the policy page. Use the disclose.io template as a starting point. Adapt scope and safe harbor language.
- Day five. Decide who triages reports and what the SLA is.
- Week two. Test the email and the triage workflow with an internal report.
- Week three. Publish the policy and announce the program quietly.
- Ongoing. Treat incoming reports professionally. Acknowledge, triage, fix, communicate. The discipline is small. The reputation effect is large. Combine with audit logs for SaaS for full visibility.
FAQ
Frequently asked
- What is the difference between a VDP and a bug bounty?
- Why does a small team need one?
- What goes into a basic VDP?
- What is security.txt?
- What should the policy promise?
- What if we get reports we cannot fix immediately?
- Will a VDP encourage attackers?
Author
About the author and why it matters
Yashveer Singh wrote this. I run Yashveer Labs out of New Delhi. The work I take on tends to come from founders who have been burned by an agency, a freelancer, or their own ambition. I do not promise miracles. I promise that the system will be online, the code will be readable, and the next engineer who touches it will not curse me. That is rarer than it should be.