Snyk looks like they have something like that in early access. I’ve seen a similar feature before in Whitesource, though it was fairly clunky. Then there’s the CodeQL queries on GitHub/LGTM which can find effective usage fairly well.
On Fri, Jul 9, 2021 at 11:54 Mark Thomas <[email protected]> wrote: > 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: [email protected] > For additional commands, e-mail: [email protected] > >
