The list of options is larger than that. There are mitigations that can be quickly applied. See, e.g., https://ma.ttias.be/php-cve-2026-109618-early-mitigation/ and https://aws.amazon.com/blogs/security/using-aws-waf-to-apply...

Meanwhile, WAFs are being continuously updated with detection signatures.

▲

AnthonyMouse 33 minutes ago | parent [-]

Mitigations and patches are in the same category, so now you're applying mitigations without testing. What if your new WAF detection signature has false positives etc.?

▲

otterley 29 minutes ago | parent [-]

The difference is that a mitigation is customer-applied, not vendor-supplied. Like it or not, blame shifts when a vendor supplies a fix that's insufficiently tested. The CrowdStrike BSOD incident from 2024 comes to mind.

As for WAF rules, those can usually be flipped on and off with a single switch.

	▲	AnthonyMouse 2 minutes ago \| parent [-]
		Being able to roll it back isn't really a difference, you can revert to the previous version of a package too. The trouble is if the WAF change e.g. messes up a redirect or turns a success response into an error response or vice versa, which confuses some other system into giving multiple users the same session cookie and gives them access to one another's accounts or writes corrupt entries to the database or whatever it is. You can revert the rule but that doesn't revert the state changes that have already happened. There is inherently a trade off between keeping the system online, keeping the system patched and testing the patch before applying it.