Re: Need some advice addressing "unfixable" publicly known vulnerabilities
David A. Wheeler
Most Software Compositional Analysis tools / services (e.g., OWASP Dependency Check, BlackDuck, SourceClear, etc.) also flag ESAPI as being vulnerable to CVE-2019-17571 because it uses log4j 1.2.17. However, the ESAPI development team has examined this CVE and the ESAPI source code and do not believe that this CVE is exploitable in the manner that ESAPI is using it because we do not use the affected vulnerable class nor any log4j 1.x class that invokes the vulnerable class. ...For the *badging* application this shouldn't be a big problem. I believe the criteria always talk about "exploitable" vulnerabilities of certain kinds as being unacceptable, not just vulnerabilities. (I think "vulnerability" always implies "exploitable" anyway, but saying things that way makes it clear.) Ignoring the distinction between vulnerabilities *in* the code & vulnerabilities in the code dependencies, let's look at criterion "static_analysis_fixed" as an example:
Notice that this criterion only focus on *exploitable* vulnerabilities. If a tool (like a static analysis tool) finds a purported vulnerability, but it's not actually exploitable, that does *NOT* count as a true (exploitable) vulnerability. Nor should it. No tool is a substitute for thinking; tools are good at warning people about *possible* problems.All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
Even though we believe strongly that ESAPI's use of log4j 1 does not expose our users to this vulnerability, that belief--even if released as some official statement (which we are considering) is unlikely to help all that much. For some more details about some of these concerns, please see https://groups.google.com/a/owasp.org/forum/#!topic/esapi-project-users/XxKBjj3HuSw. (And yes, I know I forgot to erase the SMTP headers of the original poster's email resulting in his privacy not being not maintained; I've already apologized to him.)You should *definitely* do an official write-up. Publicly explain why it's *not* a problem in your case. I understand your skepticism, but it's still the right thing to do.
Looking at it from the other direction, it's perfectly reasonable for the SCA tools to flag ESAPI as vulnerable as long as they lack any other evidence. You need to provide the SCA suppliers with evidence that this should be squelched.
What probably needs to happen, long-term, is for there to be a standard way to report that "no, we're not vulnerable in this case". Then the SCA vendors can use that information in their tool. Here's a rough idea that I've thought about for 5 seconds (so no guarantees this is a *good* idea): There should be a standard directory name like "not-vulnerabilities". Its contents are files with the vulnerability id with a file format extension , e.g., CVE-2019-17571.md for a markdown file. That file includes a justification of WHY the default configuration (at least) is not vulnerable to that CVE, which may include inherited CVEs.
--- David A. Wheeler