What do you call that thing when your vendor gets hacked?

  • Third party security
  • CVEs

2 minute read

The thing that bugged me the most in the past week about the Salesloft Drift incident and the npm Chalk/Debug packages issue isn’t how disruptive they were — we really did get lucky with npm — but that we still don’t have a standardized way to talk about these situations. (Also, when you go to the Salesloft website, the banner is about a merger and not the security incident. Why did you think you were getting all this traffic?)

When software or hardware has a vulnerability, it gets a CVE. You can reference it, check if you’re patched, and customers immediately know what you’re talking about. Everyone is speaking the same language.

But vendor breaches don’t get CVEs. Salesloft won’t get assigned one — you don’t care what version of Salesloft you’re running (disclaimer: I mean I assume not? I have no idea how Salesloft is deployed), you care about whether your data (or your vendor’s data) was exposed as a result of the breach. Just like when Snowflake’s customer environments were breached in 2024, or Okta’s support tickets in 2023, or SolarWinds in 2020. If I’m a customer of any of these companies, I need a way to communicate with my customers about potential impact. Welcome to the reality of *aaS: your security posture now depends on a vendor three layers deep that you’ve never heard of.

Two simple things would help:

  • A unique reference identifier, like COMPANY-2025-007. It’s not unreasonable that we’ll get two of these incidents from the same company in a year, so “Company 202X” won’t cut it and isn’t easy to search for. I worked on GKE where we added our own reference numbers to security bulletins and copied that idea at Tailscale — even if just to give our customers a way to consistently reference these. (I would highly recommend doing this.) Ugly, but it works.
  • Machine-readable security bulletins, like an RSS feed with incident details that organizations can ingest automatically (some trust center updates are getting closer to this), or even better, something I can poll for this incident identifier. These should be separate from regular security bulletins because they’re informational updates, not necessarily actionable alerts. Your subprocessor list is hopefully public, and if a company on that list has a major incident — or if it’s just a big enough deal — you’re going to need to publish something anyway, even if it’s just “we’re not affected”. (We also suffer from not doing this for black swan events like log4j.) People ask, so just give them what they want.

We already have the concepts! We just haven’t applied them to vendor breaches yet.