[gav]

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.

[Reelix]

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.

[MZMegaZone]

That's just a braindead policy.

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

[gwd]

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?

[MZMegaZone]

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.