The log4shell vulnerability requires several things all to go right before it can be exploited. Stop any of those pathways, and the overall exploit chain is prevented, even if you aren’t able to upgrade every log4j instance yet. Mitigating risk means taking that step back and looking for any way to stop the chain, because in the real world, we can’t stop every single point.
Not every application will let you upgrade it, even if your security team raises a significant fuss. It might be a mission critical application that is two years away from receiving the next update, or a contractual obligation to still run a very old system to support key customers. Instead of throwing your hands up in the air, understand the chain of attack and ask yourself what technical and procedural controls can reduce the risk?
Technical controls can be easy or hard. It might include isolating the system behind strict firewalls, but some applications need to be widely accessible in your network so they can’t be firewalled off from the rest of the network. Other defensive controls may exist for a given vulnerability, such as configuration changes to the application or even an underlying system resource. In many CVEs, a mitigation strategy is often outlined. At times, those configuration changes are the preferred solution, such as to the Tomcat AJP file inclusion vulnerability (CVE-2020-1938). While some mitigation methods may be less desirable, even blocking specific DNS requests or types of outbound traffic may disable a specific class of later stage attack necessary to compromise a system. These mitigations may not be preferred, but they can be effective in buying time for other solutions.
As log4shell and Heartbleed both showed, detections of the attack proved to be immediately feasible so that you can say with confidence if someone is targeting the system. Variations on the log4shell issue required a non-default configuration to be vulnerable, so a procedural control of ensuring that configuration was not used addresses the risk, even without updating the software.
Security exists to enhance the business. That means that the methods used to identify and reduce risk must also help the organization move forward. Don’t let security become its own enemy, insisting on a one size fits none approach to every problem.