log4shelldetect VS local-log4j-vuln-scanner

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.

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.