3 ms·

Does anyone have context for why "best practice" would be to disclose before there's a fix available? This is news to me (most of the time I see CVEs it's right

• cp9 3y ago
  my understanding matches yours. I don't think this article is particularly clear about why rapid7 would threaten to disclose a vulnerability before a patch is ready and then subsequently get angry that jetbrains put out a patch to fix the issue
  • ziddoap 3y ago
    >angry that jetbrains put out a patch to fix the issue They are angry that it was a _silent_ patch. The whole issue revolves around the _silent_ part. More on why Rapid7 doesn't like silent patching here: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
• throw0101d 3y ago
  > Does anyone have context for why "best practice" would be to disclose before there's a fix available? If it is already being exploited is one reason. A fix may not be available, but if folks know there's an attack going on, they can make a more informed choice in still whether to allow the code to run: in some cases a loss of service would be better than a compromise. If the code is externally-facing, then they bring it down; if it is internal-only, then it may be judged that the risk is low(er) and things to be continue to be run (and a maintenance window can be pre-planned for when the fix comes out).
• codexb 3y ago
  There's always a way to prevent or mitigate harm. You can suspend or degrade service temporarily until a fix is applied.