You're worried about patching the system that you're developing and releasing. Most people aren't doing that. Most people are patching systems they bought from some other guy. Indeed, they're scanning and patching dozens of systems they bought from a dozen other guys, each of whom sourced libraries from other guys, who sourced things from still other guys. Somewhere way down at the bottom of the vendor chain is Log4j.
For example, we operate an information system we bought from a nationwide vendor. The primary application is not vulnerable. The admin interface is not vulnerable. The secondary application is not vulnerable. However, there's a reporting system from a third party that was provided to us. That is vulnerable. Now we have to wait for the third party to patch so that the vendor can patch so that we can patch.
Plus there's all the other things you find that are clearly stupid, but aren't immediately important. Like this:
Plus, older systems may have multiple applications deployed to the same Servlet container (e.g., Tomcat server), even if only one app uses log4j, upgrading it may require updates to transitive shared dependencies that can break "non-affected" apps. Given the prevalence of such Java apps, fixing this is likely to take a long time. Mitigating with firewall rules is a good first step for now.
For example, we operate an information system we bought from a nationwide vendor. The primary application is not vulnerable. The admin interface is not vulnerable. The secondary application is not vulnerable. However, there's a reporting system from a third party that was provided to us. That is vulnerable. Now we have to wait for the third party to patch so that the vendor can patch so that we can patch.
Plus there's all the other things you find that are clearly stupid, but aren't immediately important. Like this: