fix: evidence source in Retire JS analyzer

[jim-liu]

Description of Change

The Retire JS Analyzer reports evidence with source set to file, which is used by File Name Analyzer. I changed it to RetireJS which seems to be inline with the source of similar analyzers.

Related issues

None that I'm aware of.

Have test cases been added to cover the new functionality?

No.

[chadlwilson]

Is there a particular problem you are trying to solve that this evidence value is causing you?

While I agree the code is confusing and probably should not be using magic strings without linking to the rest of usages, I'm not sure this is appropriate without unintended consequences?

The source for evidence seems to unfortunately have multiple meanings in the code, with different logic driven off it, and it really needs two different dimensions to handle the different logic. Not all of the sources map to an analyzer directly; e.g multiple analyzers/plugins can create evidence with pom source, but in some sense they are different in how they determine a pom.

I believe the source of the evidence is used later to make decisions on its reliability and how the version should be parsed, seemingly in both the VersionFilterAnalyzer and perhaps the FalsePositiveAnalzyer which is where the possible unintended consequences may come from.

As to the appropriate value here, internally the RetireJS analyzer tries to determine versions based on matches to URIs --> filenames --> content hashes, and thus in some sense I believe its "source" for the data could be considered a javascript file even though RetireJS rules for matching (rather than ODC logic) is used to evaluate which file is which library.

I am not sure if that was the original intent of using file, but broadly speaking - the source of the content is just a JS file itself I think - not package metadata or anything like that - so maybe it's appropriate?

Having said that - it does set the confidence level to HIGH, so I don't know. I don't think the JsLibraryResults have a way for us to determine different confidence levels of sources for which rule the library was matched via.

[jim-liu]

Not trying to solve a particular issue - I noticed this when I was trying to track down which analyzer reported a certain dependency.

I did briefly check the analyzers in org.owasp.dependencycheck.analyzer and all seem to report a different source. That's why I thought this might have been an oversight when the RetireJS analyzer was created. But if that's not the case, then this PR can definitely be closed.

[chadlwilson]

They seem to use it rather differently; but it generally represents the source of the information locally, not the remote source or the tool used. Sometimes even the specific file name for some analyzers.

RetireJS is a bit different since it uses fuzzy matching logic which is maintained remotely, while acting on a local file.

Will see if others with more experience of how this is used have an opinion.

[jeremylong]

My only concern is the hint analyzer. However, the base hints only have a single source="file" entry, which appears to be for a Java dependency, so this change would have no effect for the core ODC. Users may have set up their own hint file (this would be fairly rare).

[jeremylong]

LGTM

[jeremylong]

after reviewing a bit more code - I'm good with this PR.