Last updated at Wed, 28 Dec 2022 17:03:39 GMT

As 2023 comes hurtling towards us like some kind of maniacal arctic train full of disturbingly realistic AI-generated people, I wanted to take a moment on the blog here to announce that we here at Rapid7, Inc. have refreshed our coordinated vulnerability disclosure (CVD) policy and philosophy. If you just want the precise details, you can head on over to the refreshed CVD page. Otherwise, read on if you want some more explanation of why we're updating our CVD policy.

A Cohesive Philosophy

Rapid7, as you might expect, is chock full of security researchers—part time, full time, hobbyists, and professionals alike—and so, we frequently come across software vulnerabilities that we'd like to see fixed. These bugs might exist in specialized environments, in the cloud, in the hands of end-users, or in enterprise data centers. The vulnerabilities themselves might be widely exploited in the wild or they might be hard to trigger. Sometimes, the vulnerability itself might be technically a violation of security principles, but the practical effect of its exploitation will be kind of "meh."

And on and on. It turns out, our old "one size fits all" style of CVD just wasn't cutting it, as we ran into more and more edge cases when it came to the kinds of vulnerabilities we learn about. Recognizing that, we thought it would be helpful to come up with some broad strokes of what we intend to accomplish and offer up what we expect to do in most cases. From there, we could enumerate all the edge cases we could think of (and have experienced) and document how those cases are different from the usual flow of vulnerability disclosure.

So, far starters, we put together this (fairly pithy) reasoning of why we participate in coordinated vulnerability disclosure in the first place:

  1. We believe in strengthening defense by democratizing access to attacker tooling and knowledge. One of Rapid7’s unique strengths is our deep knowledge of how attackers work. Our vulnerability research and Metasploit teams strive to make attacker capabilities, that would otherwise be used primarily by criminals, accessible to all.  This enables defenders to understand and prioritize critical vulnerabilities, develop detections and mitigations, and test security controls. Releasing public exploit code and novel research is core to our mission to close the security achievement gap.
  2. Public disclosure of vulnerabilities is a critical component of a healthy cybersecurity ecosystem. Rapid7 advocates for, and practices, timely public disclosure of vulnerabilities across both third-party products and our own systems and solutions. This includes vulnerabilities we independently discover in our customers’ tech stacks. Through transparent, open, and timely vulnerability disclosures, Rapid7 is able to assist  the entire internet in protecting and defending those assets and services critical to modern civilization.
  3. Organizations need timely information about risk in order to make educated choices about protecting their networks—especially during active attacks. Our vulnerability disclosure policy includes specific provisions for expediting public disclosure in cases where exploitation has been observed in the wild. Vendors often (understandably) act to protect their own businesses and reputations when there are security issues in their products that introduce risk into their downstream customers’ environments. When we know about exploitation in the wild, or when we believe that threat actors may be covertly weaponizing non-public vulnerabilities, our priority is to alert customers and the community so they may take action to protect their organizations.

The Basic CVD

Building from that, we've updated and articulated what is "normal" in vulnerability disclosure, in the form of a five-point guide to what everyone should expect from Rapid7. You can read the exact wording at https://www.rapid7.com/security/disclosure (it may change slightly over time), but to summarize, our basic, standard approach will be to:

  • Keep things confidential at first;
  • Reserve a CVE ID;
  • Tell CERT/CC after 15 days;
  • Publish about it after 60 days; and
  • Encourage the release of a fix

Rapid7 will also:

  • Offer extensions on disclosure timelines (within reason)
  • Publish if the software maintainer publishes, and
  • Not hold things up if there are duplicate reports

That all seems pretty normal in cybersecurity, and reflects industry standards as promulgated by the likes of ISO 29147 and ISO 30111. Internally, we've been calling this the "potato case," since it's the basis of all sorts of variations and permutations. And, like a potato—which you might dice, slice, pan-fry, bake, mash, pressure cook, season, gravy, butter, and on and on—we can take this base policy and tweak it just a little to get where we need to be for all the edge cases in CVD.

Edge Cases (edginess not guaranteed)

Okay, enough potato talk. Getting hungry.

Vulnerabilities cause unintended conditions and undefined behaviors, and so our CVD should anticipate curve-balls and weird circumstances. We break out six classes of vulnerabilities (and a meta-classification of "more than one") and slightly alter the standard case per circumstance:

  • Exploited in the Wild: When vulnerabilities are being actively exploited, time is of the essence so that defenders can ramp up and start defending, right now. It would be pretty irresponsible to sit on our hands for 60 days in this case, so expect a bulletin inside a couple of days instead of two months.
  • Patch Bypasses: If a patch doesn't do the job and a bypass is discovered, we will want to move a little faster, and also, make sure there's a new CVE ID to describe it. Recycling CVE IDs causes vulnerability management systems all kinds of headaches.
  • Cloud/Hosted Vulnerabilities: The cloud remains special, in that a fix to a SaaS product tends to mean that's the end of it, and there's sometimes little value in disclosure after the fact. However, it remains a possibility that there are some cases in which the learnings from a particular cloud vuln are worth talking about and raising awareness of (namely, for IOCs and logging artifacts to check to see if you've already been compromised).
  • Kinetic Vulnerabilities: These vulnerabilities are special since they have direct effect on life and limb; think of specialized medtech, vehicle safety systems, and the like. In these cases, we want to allow plenty of time for patches to get out there before we openly discuss all of the technical details.
  • Low-Impact Vulnerabilities: While every bug is sacred and special, some are, well, less special than others. In these cases, we wouldn't bother with coordinating with CERT/CC (they have plenty of work to do), and we may not even publicly disclose them at all (beyond the private disclosure to the responsible organization).
  • Vulnerabilities with No Responsible Organizations: Sometimes, there are bugs in systems that nobody maintains anymore—abandonware and the like. In these cases, we will move a little faster on disclosure, in coordination with CERT/CC, mainly because we're not waiting for a fix to be developed.
  • Multi-Faceted Vulnerabilities: If a bug checks more than one of the above boxes, a shorter timeline will apply. So, for example, if there's some abandoned software that's also being exploited right now, we'll publish in just a couple days, rather than a month and a half.

Right now, those are all the cases we can think of, and they hit every vulnerability disclosure I've been a part of at Rapid7 over the last decade. Every time we've strayed from our (old) policy, it was due to one or more of these conditions. I expect that going forward, the way we approach CVD will be much more predictable and comfortable for everyone involved. Well, except for the criminals and spies that are using these vulns for evil, sorry, not sorry.

Patches Accepted

If you have any thoughts or feedback on this policy, hit us up at cve@rapid7.com and we'd be happy to hear it. Or, toot at me and/or Caitlin directly on Mastodon. Do note that we'll be sticking to the much more precise language on our CVD page, since this blog post is *not* the greatest CVD in the world, it's just a tribute.

As always, If you have a vulnerability to report on something that Rapid7 is responsible for, check our security.txt for contact details.
Incidentally, do you have a security.txt file? Should you? They're easy and fun to write and publish—see RFC 9116 for the details there; publishing a note of where to contact you sure makes the job of hearing about vulnerabilities in your products and services a whole lot easier.