Vulnerability reporting policy
Private reporting of security vulnerabilities is a deal between two (or more) parties. Vendors have policies for how they handle vulnerabilities in their products. So it seems that as a security researcher, I need a vulnerability reporting policy.
What you can expect from me:
- There’s many opinions on what the best way to report vulnerabilities is. I’m more in favor of responsible disclosure than full disclosure. I normally report security vulnerabilities in private first.
- I keep vulnerabilities secret for a reasonable amount of time. What is reasonable depends from case to case. I normally do not make things public sooner than three months after the first report. In any case, after six months all bets are off. These are maximums, deadlines, not guidelines.
- When the vulnerability is public (because you announced it, published a fix, someone re-discovered it,…), I do give out the details on my blog. This usually including an explanation for how it could be exploited, but (unless it is trivial) the ready-to-use exploit code is usually kept private for a while longer.
- I do security vulnerability research in my private time. My research is not paid by, or in any way directly associated to my employer (even when they use the affected product).
What I expect from vendors of affected software:
- Talk to me, and be honest. Tell me when you intend to publish a fix. Telling me how you intend to fix it is also appreciated (and can lead to valuable feedback).
- When the time is there, be open about the vulnerability; don’t try to hide it. Share the fix with everyone affected, and announce it where interested users would expect it (mailing list, forum,…). Preferably also send a mail to the bugtraq and/or full-disclosure mailing lists.
- As is custom in the software security industry, give me credit. Mention my name in the announcement. This acknowledgement is the only thing I get in return for the security research work I did for you for free. A link to my site, where a post about the vulnerability will appear, is also appreciated.
- It’s a good idea to request a CVE and use it in all public communication about the issue.
Anything in this policy can change at any time. If you do not follow these rules, or do not handle security vulnerabilities in a responsible way, you will be added to Santa’s naughty list.