[deng]

> based on the unquestioned premise that delaying disclosure for the operational convenience of system administrators is a good thing. There are reasons to question that premise!

Care to mention these reasons?

With "convenience of system administrators", I'm guessing you mean that there's a patch available that sysadmins can install, ideally before the vulnerability is disclosed? What else are sysadmins supposed to do, in your opinion? Fix the vulnerability themselves? Or simply shutdown the servers?

With the various copyfails of recent, it at least was possible to block the affected modules. If that were not the case, what would you have done, as a sysadmin?

[Jach]

The best convenience is that by the time of disclosure, the patch was already merged perhaps months prior and so sysadmins following a routine update schedule would have already updated to a version including the patch and thus have nothing to do. This relies on an assumption that a patch or series of patches aren't equivalent to a disclosure, so that a disclosure can be delayed from the patch, which is basically untenable in modern times.

[tptacek]

Choose to take an availability hit rather than risk a breach.

[isityettime]

Presumably you also have positive downstream effects in mind: when "taking the availability hit" feels like more of a live choice, operators feel the pain of running insecure designs more. Do what you describe a couple times, and you'll naturally start thinking things like "dammit, we need to finally get away from shared kernels; this is insane", "maybe we should figure out a way to do this that doesn't involve running software that runs in God mode", or even "we should see what it takes to port our application to a platform that is more secure by design".

When you can't imagine or pretend that when a major vuln is disclosed (a) you've been secure up until the point of disclosure or (b) all you need to do now is apply a patch without thinking too much about what your blast radius just was, you might actually have stronger incentives to think about the design of the overall system so that when similar issues come up, you can avoid having to sweat those outages.

It's interesting that "defense-in-depth" gets cited and repeated all the time but the standard attitude about patching still seems to be "what do you mean?? isn't patching the only thing we can do?". How about designing systems so that you can more quickly and easily throw up other kinds of mitigations when you need to? What about designing systems with robust enough notions of graceful degradation that when something crops up for a certain feature you can "just" say "okay, let's turn only that part off for a couple days"? How about getting really, really good at CI/CD so you can more confidently add and deploy mitigations to your application code, or redeploy with a feature flag that lets you temporarily drop an unpatched-and-vulnerable dependency?

If you can manage to build a system without the assumption that just patching is always on the table, you might simply end up with better software, which would be pretty cool.

[tptacek]

"Taking an availability hit" is also an "in the limit" case that mostly serves to illustrate the falsity of "disclose or patch" as a binary. Much more commonly: a fully disclosed vulnerability arms systems teams with enough information to mitigate; pull kernel modules, change permissions, that sort of thing.

[isityettime]

Maybe some corporations like the "just patch" playbook because it takes less skill to execute or articulate. It might be as much a deprofessionalizarion/commoditization of labor thing as much as anything else.

[deng]

With "availability hit" I'm assuming you mean to simply stop operations until patches are rolled out, so possibly for days? That would at least explain what's happening at GitHub...

[vanviegen]

Many vulnerabities seem to be in code paths for rarely used features. They can often be disabled.