On 09/07/2021 15:49, Daniel Wille wrote:
That is good to know, and I appreciate that info.
I know that making updates to libraries for reasons like this is
frowned upon by developers whose time is better spent fixing actual
problems. It does mean however that many users will be in a situation
where a corporate tool will detect the CVE, requiring the developer to
investigate so they can either explain why the CVE is a non-issue, or
force them to override the dependency in their build (which I did,
because that's the easiest course).
I'd strongly recommend pushing for better tools.
For example, the ASF automatically rejects any vulnerability report that
is just the verbatim output of a security scanner. We will only accept
issues from such reports when backed either by a PoC or manual analysis
that demonstrates a genuine security issue.
There are scanners available that don't just check dependencies but
check the code used so they only flag the dependencies where the
problematic code path is used. You'll still get some false positives but
the valid / invalid ratio will be a lot better.
We did a trial with one such tool at the ASF. I liked it. I don't recall
the name of the tool. I can try and look it up if there is interest
although I think it may have gone through a rebrand since we tested it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
