How NOT to respond to vulnerability reports

Reuven Cohen and the guys at Enomaly could write the book on how NOT to respond to vulnerability reports:

1. Don't disavow vulnerabilities in products you've previously taken credit for
2. Don't claim issues are not valid while denying researchers a right of reply
3. Don't claim obvious issues are "unactionably vague" and then ignore them, even after a working exploit is publicly available
4. Don't claim trivial remote root exploits are "theoretically valid but extremely difficult to exploit"
5. Don't claim it's ok to rely on security by obscurity or race conditions
6. Don't turn on moderation because a researcher posts a vulnerability report to your lists
7. Don't subsequently ban a researcher from your lists because they tried to notify your users when you failed to
8. Don't claim that security vulnerabilities are ok because there have been "no reports of any security compromise"
9. Don't claim "other mitigating factors that have been present in the environment from the beginning" when the vulnerability has already been demonstrated
10. Don't ask for private notification of vulnerabilities only to then ignore/dispute them
11. Don't publicly call researchers unethical for opting for full disclosure, especially when they do so because you have been reticent and unresponsive in the past
12. Don't release ineffective fixes, especially when the researcher has told you exactly how to fix it
13. Don't dispute the vulnerability when a clearinghouse like Secunia contacts you to verify it
14. Don't criticise researchers for reviewing your product
15. Don't shoot the messenger
16. Don't downplay critical vulnerabilities as "relatively minor", "random" paths as "pretty hard to guess", etc.
17. Don't send in board members to fight your battles
18. Don't claim new products having "significant new and enhanced functionality" is a valid excuse
19. Don't make security claims like "High Assurance" if you're not going to take security seriously
20. Don't claim that "Enomaly shall be entitled to (i) suspend or de-activate your account without notice, and (ii) retain any remaining funds in your account", and definitely don't actually do it.

After my recent SploitCloud: exploiting cloud brokers for fun and profit article and the follow-up Retro vulnerability of the day: cleartext passwords over the wire you'd have thought the publicly demonstrated vulnerabilities would have been quietly fixed and we'd have moved on. But no — they've decided instead to suspend my Spotcloud account so as I can't find any more holes, keeping funds they were holding in trust for payment to third-party providers as "compensation" — something I'm more inclined to refer to as "theft":

Enomaly have also not only failed to notify Spotcloud buyers and sellers that they are vulnerable themselves, but moderated (e.g. deleted) my notification to them and banned me from the lists in the process:

If I were one of the (apparently few) users of the Spotcloud service then I'd be extremely dissatisfied, to say the least, that this information was being actively concealed from me. At the end of the day you owe it to yourselves and your users to only ever work with providers who take security seriously.