Hacker News Reader

Comment by gwd | Hacker News Reader

FWIW, in my project the main reason we don't issue security advisories for "unsupported" code ("experimenal" or "tech preview") is to reduce the burden for our downstreams: many of our immediate downstreams are expected by their users to apply every single security patch, regardless of whether they even use the affected functionality. For cloud providers doing this across a massive fleet, this is a fair amount of work that's worth avoiding if we can.

On the other hand, since the definition of "supported" is specifically designed to help downstreams, if it were known that some bit of code was widely used in production, we'd be open to declaring it "security supported", regardless of whether we thought it was "finished" or not.

View on HN

Recently I had to support a client who had a "no CVEs in a production deploy, ever" policy.

The stack included Linux, Java, Chromium, and MySQL. It took multiple person-years of playing whack-a-mole with dependencies to get it into production because we'd have to have conversations like:

  Client: there's a CVE in the this module 
  Us: that's not exploitable because it's behind a configuration option that we haven't enabled
  Client: somebody could turn it on
  Us: even if they somehow did and nobody noticed, they would have to stand up a server inside your VPC and connect to that
  Client: well what if they did that?
  Us: then they'd already have root and you are hosed 
  Client: but the CVE
  Us:

So I definitely appreciate any vendor that tries to minimize CVEs.

That's just a braindead policy.

Really, really dumb. Not at all good security, just checking boxes.

I mean, yeah, but if that's the way big bureaucratic organizations get sometimes. Bigger means more likely to have a brain-dead policy like this, but also more money... so, do you give up the money, or do you accommodate their policy while trying to minimize the cost?

Oh, I'll cash their check. I'll tell them, in professional terms, why they should change their policy, but I'll still cash the check.

In their defense, if the latest version of a module has a CVE, then it's either a 0-day, or an unsupported module.

In either case, you should probably do something about it.

Reply on news.ycombinator.com