local-log4j-vuln-scanner VS log4shelldetect

The last scanner type is looking for the classes. Carnegie Mellon’s CERTCC released one that is referenced by CISA: https://github.com/CERTCC/CVE-2021-44228_scanner that look for class names and some fingerprints. Then there is a scanner written in Go that checks for the vulnerable class files and their hashes (inside JARs, WARs,EARs, and zips). https://github.com/hillu/local-log4j-vuln-scanner

I have been scanning with https://github.com/hillu/local-log4j-vuln-scanner and that problem was resolved in there.

If you want to scan your system for vulnerable log4j instances, https://github.com/hillu/local-log4j-vuln-scanner has binaries and is constantly updated

We are using this local log4j scanner: https://github.com/hillu/local-log4j-vuln-scanner/

https://github.com/hillu/local-log4j-vuln-scanner - Nope

Log4j may be included in other jars, so a recursive ps scan like https://github.com/hillu/local-log4j-vuln-scanner may come to rescue

The scanner provided by https://github.com/hillu/local-log4j-vuln-scanner gives us the following output when using "/opt/qradar/" as directory.

I'm not sure what you mean. You can deploy a built binary over your network and run it on all your servers. For example: curl -sSL https://github.com/1lann/log4shelldetect/releases/download/v0.0.2/log4shelldetect_0.0.2_Linux_x86_64.tar.gz | tar -C /tmp/ -zxf - log4shelldetect && /tmp/log4shelldetect -mode list /path/to/scan 2>/dev/null would download and extract the prebuilt binary to /tmp, and run it scanning at /path/to/scan, only outputting paths to potentially vulnerable .jars and ignoring warnings. You can replace the URL with your own build or distribute your own build as you wish.