Dependencycheck: RetireJS analyzer ?

[stboissdev]

when will the RetireJS analyzer be integrated into a release ?

[jeremylong]

The plan is to integrate retirejs when the license is updated on h3xstream/burp-retire-js code base. See https://github.com/h3xstream/burp-retire-js/issues/29.

[stboissdev]

thank's for your answer

[h3xstream]

@jeremylong License changed.

[stboissdev]

@jeremylong when do you think released with RetireJS ?

[stevespringett]

@stboiss While the license has been changed, a release which is licensed under the Apache 2.0 license has not yet been pushed to Maven Central. Once a new version of the retire-js library has been pushed, we can work on getting that into a Dependency-Check release. The retire-js branch currently works, although it lacks the library inventory functionality. It also needs to be brought up-to-date with some of the refactoring thats occurred with the project.

[jeremylong]

@stevespringett I just rebased the retirejs branch.

[h3xstream]

I finally release the version 3.0.1 to Maven.
https://oss.sonatype.org/content/repositories/staging/com/h3xstream/retirejs/retirejs-root-pom/

The bump to 3.0.1 was needed because the version 3.0.0 was accidentally deployed.

[jeremylong]

Thanks! we will work on finishing the integration soon.

[stboissdev]

@jeremylong did you advance on this topic?

[jeremylong]

Yes - the integration got stalled slightly due to other issues but I just rebased the PR from @stevespringett and I am working on the integration now.

One of the issues I ran into is that if you run the RetireJS Analyzer on a large application with lots of custom JS you end up with a TON of dependencies on JS that are not 3rd party. I am thinking about adding a copyright filter (well - it will be a regex filter) to exclude JS files from analysis so that you could exclude any JS files that contained: copyright (c) 2018 [insert company/author]. All Rights Reserved.

[h3xstream]

Retire.js signature are unlikely to trigger on proprietary JS (false positive) unless files are combined.

For exemple, here are the regex to extract the JQuery version : https://github.com/RetireJS/retire.js/blob/master/repository/jsrepository.json#L110-L117

[jeremylong]

@h3xstream I completely get that. The way dependency-check works (for most dependency-types) is it creates somewhat of a Bill-of-Materials - so it includes in the report all of the JS files scanned. Even those contained in JAR/WAR/EAR files or other archive files. It isn't the noise of FP I'm concerned about; rather including a ton of JS dependencies in the report that are actually custom code that likely do not have publicly known vulnerabilities.

I'm likely going to be adding a copyright filter (so any dependencies with a specific copyright would be skipped) and a configuration that would allow one to filter all JS files from the report that do not have a vulnerability.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.