The CERT Guide to Coordinated Vulnerability Disclosure lists seven principles: reduce harm, presume benevolence, avoid surprise, incentivize desired behavior, ethical considerations, process improvement, and the idea that disclosure is a wicked problem. Each one maps to a habit a product team can adopt without extra budget.
The principles and a habit for each
| Principle | What the guide says (paraphrased) | A habit |
|---|---|---|
| Reduce harm | Balance letting defenders act against giving attackers an advantage | Share details with fewer people before the fix, more after |
| Presume benevolence | People who contact you likely mean well | Open every first reply with thanks, not a legal warning |
| Avoid surprise | Unexpected moves in a tense, multi-party case raise the risk of a bad outcome | Tell the reporter before you publish |
| Incentivize desired behavior | Reward good behavior rather than punish bad | Credit finders publicly, as they prefer |
| Ethical considerations | Professional codes of ethics have some application | Decide in advance what you will not do, such as pursue good faith testers |
| Process improvement | Capture what worked and what failed | Hold a short review after each case |
| Wicked problem | Requirements are incomplete, contradictory and changing | Expect to revise your policy yearly |
Presume benevolence, tested
This is the principle teams find hardest. A report arrives with blunt language and a deadline. The guide's position is to assume the sender wants less risk. Start from that and you keep the channel open. If the evidence later shows bad faith, you can change course, and you will have lost nothing.
Avoid surprise, tested
Surprises come from timing. A fix released early, an advisory with unfamiliar credit, a researcher whose deadline you did not know. Prevent them with a short message: here is our fix date, here is what we will publish, tell us if anything is wrong. Our post on what to promise researchers covers dates you can keep.
Process improvement, tested
After every case, write five lines: what came in, how long each step took, what leaked or nearly did, what the reporter said, one change you will make. Store them with the case. A year later you will have a real basis for revising your policy.
Where to go next
If you do not yet have a policy, start with the vulnerability disclosure policy checklist, then read what safe harbor means.
Quick check
What does presume benevolence mean?
Assume that people who contact you about an issue likely mean well and want to reduce risk.
How do I avoid surprising a reporter?
Tell them your fix date and what you will publish before you publish it.
Safeguard's policies and compliance evidence automation can keep your disclosure process documented, and a free scan shows your current dependency exposure.
Sources
Last reviewed: 19 October 2026.
