>The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away.

The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software.

Where I work, if our infosec team's scanner detect a critical vulnerability in any software we use, we have 7 days to update it. If we miss that window we're "out of compliance" which triggers a whole process that no one wants to deal with.

The path of least resistance is to update everything as soon as updates are available. Consequences be damned.

▲

tetha 4 hours ago | parent | next [-]

I really dislike that approach. We're by now evaluating high-severity CVEs ASAP in a group to figure out if we are affected, and if mitigations apply. Then there is the choice of crash-patching and/or mitigating in parallel, updating fast, or just prioritizing that update more.

We had like 1 or 2 crash-patches in the past - Log4Shell was one of them, and blocking an API no matter what in a component was another one.

In a lot of other cases, you could easily wait a week or two for directly customer facing things.

▲

BrenBarn 6 hours ago | parent | prev [-]

> The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software.

The solution is to fire those teams.

▲

acdha 4 hours ago | parent | next [-]

This isn’t a serious response. Even if you had the clout to do that, you’d then own having to deal with the underlying pressure which lead them to require that in the first place. It’s rare that this is someone waking up in the morning and deciding to be insufferable, although you can’t rule that out in infosec, but they’re usually responding to requirements added by customers, auditors needed to get some kind of compliance status, etc.

What you should do instead is talk with them about SLAs and validation. For example, commit to patching CRITICAL within x days, HIGH with y, etc. but also have a process where those can be cancelled if the bug can be shown not to be exploitable in your environment. Your CISO should be talking about the risk of supply chain attacks and outages caused by rushed updates, too, since the latter are pretty common.

▲

IcyWindows 4 hours ago | parent | prev | next [-]

Aren't some of these government regulations for cloud, etc.?

▲

bumblehean 5 hours ago | parent | prev [-]

Sure I'll go suggest that to my C-suite lol

	▲	paulddraper 4 hours ago \| parent [-]
		Someone has the authority to fix the problem. Maybe it’s them.