6 ms·
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 multip
by gav 3y ago
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 3y agoIn 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 3y agoThat's just a braindead policy. Really, really dumb. Not at all good security, just checking boxes.
- gwd 3y agoI 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 3y agoOh, 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.