In some ways the most complete solution is to do many thing, not just one thing.
There is the scan for JARs and analysis for reporting (for windows and non-windows)
There is setting the env var to prevent the RCE CVE.
There is replacing JAR files with the newest version to mitigate both CVEs but with potential application problems, but reverting it should just be a matter of swapping back the saved version of the JAR with the replaced one.
There is running a utility like the Logpresso utility that can remove the effected class from existing JAR files, but also unknown JAR files that are using it but under a different name, as well as JAR files embedded within WAR and EAR files.
Technically you might need to do all 3 of these things to be fully mitigated everywhere, yet the env var one is least likely to impact the applications, while the other 2 are the only ways to fully mitigate both CVEs but with a higher likelihood of impacting the application, though it does seem like this is the path that others are going down with positive results.
We have content for scanning and reporting on JAR files that are affected.
We have content for setting the env vars on windows.
We have experimental content for replacing the JAR files on windows.
We are working on extending these solutions to *nix, but the env var option is a bit trickier on *nix and needs to handle some additional use cases.
Looks for these solutions here: Log4j CVE-2021-44228, CVE-2021-45046 Summary Page
and the full discussion and solutions here: Log4j CVE-2021-44228 Detection and Mitigation
