How to write a coordinated vulnerability disclosure policy
What a CVD policy has to contain, the two sentences that matter most, a timeline you can keep, and why security.txt is worth nine lines.
A coordinated vulnerability disclosure policy is a short public document that answers one question for a stranger who has found a hole in your product: what happens if I tell you. Without an answer, the rational move for that stranger is to tell somebody else.
What it has to contain
- Where to send a report. One address, monitored, that does not depend on a single person being at work.
- What you want in the report: affected product and version, reproduction steps, impact.
- What the reporter gets back and when: an acknowledgement within a stated time, and updates at a stated cadence.
- The disclosure timeline you propose, and what happens when it runs out.
- A safe harbour statement: research done in good faith within the policy will not be met with legal action.
- Scope: which products and which endpoints are in, and what is explicitly out.
The two sentences that matter most
The acknowledgement commitment and the safe harbour clause do more work than the rest of the document combined. A researcher deciding between reporting to you and publishing has to weigh silence and legal risk against the effort of writing to you. Remove both and reporting becomes the easy path.
Do not promise a bounty you have not budgeted. An unpaid promise is worse than no programme: it converts a helpful stranger into an aggrieved one, in public.
Publish security.txt as well
RFC 9116 defines a plain text file at a well-known path that tells automated tooling and human researchers where to report. It costs nine lines and it is the first place anybody with a finding will look.
- Serve it at /.well-known/security.txt over HTTPS.
- Include a Contact line and an Expires line. An expired file reads as an abandoned process, so pick a renewal you will actually do.
- Link the Policy line to the full policy page.
- Add Preferred-Languages so a reporter knows whether to write in their own language.
A timeline you can keep
| Stage | A defensible commitment | Why this number |
|---|---|---|
| Acknowledgement | Within 3 working days | Long enough to survive a holiday, short enough that the reporter does not assume you are ignoring them. |
| Initial assessment | Within 10 working days | Time to reproduce and decide severity without promising a fix date you cannot know yet. |
| Fix or mitigation | Stated per severity, not per report | A single number for all severities is either impossible for the worst or wasteful for the least. |
| Public disclosure | 90 days from report, or on fix release | The industry norm. Deviating is fine; deviating silently is not. |
Commit to what your smallest month can deliver. A policy promising a one-day acknowledgement, written by a team of three, will be broken in August, and the breach will be visible to the one person you most wanted to keep on side.
The part people forget
A policy is a process, not a page. Before you publish it, check that the address in it reaches a human, that somebody is responsible for it while its owner is away, and that a report arriving on a Friday afternoon will be seen. Publishing a contact address that bounces is worse than publishing none, because it converts a report into a public post about how nobody answered.
Test it the way you would test a smoke alarm. Send a report to your own address from outside the company and see how long it takes to reach the person who would have to act on it.