[Bug]: OWASP Security Scan of the 6.0.0 branch

Review the OWASP report by module and pom to separate vulnerabilities in custom code from those in the cTAKES distribution. Start with the proposed Java 8-to-17 upgrade and the poms for Guava, JDOM/JAXB/StAX, and Log4j; done means addressing the reported vulnerabilities while checking compatibility, tests, and regressions.

What happened?

reported 1417 vulnerabilities

Essentially, there were 41 unique packages which have a host of security vulnerabilities. Module wise, if I remove Smoking Status, User Resources, GUI, Tiny REST, and FHIR modules, I end up with 1190 vulnerabilities ( 227 less from 1417).

There were 13 "packages" libraries with 732 (135 Critical, 250 High, 0 Low) vulnerabilities where I deemed these a lower level of effort, because their higher library versions provide backward compatibility and they are able to run with Java 6 or later, or wont have any issues running with Java 17. For these, I will simply specify their later versions in the pom, and re-build. There were another 9 libraries which I labeled medium which have 77 (46 Critical, 20 High, 10 Medium, 1 Low), due to likely having some potential breaking changes, which will require code changes, testing, & regressions. Finally, there were 19 libraries with 381 vulnerabilities (10 Critical, 178 High, 157 Medium, 36 Low) where either there was no higher version, requiring an alternative library and requiring code changes, or there were higher versions which offer no backward compatibility with breaking changes.

However, its important to point out that the security report does include a column reflecting which module/pom each package / vulnerability is being reported so that 1) I can assess if this is with our custom code, or 2) with cTakes distro, and 3) with my knowledge of our code, what of #2 our module has co-dependence on - this will likely lead to some discovery of where we rely on less than actually what we build with, to further reduce effort, but there will still be the fact that there are issues which were reported under #2.

If I shared this report, is there some concerted effort I or we together could help to address these? At present, we have a raised exception which we have extended to now, and likely will have some leniency due to where I can in the interim perform the Java 8 to Java 17 upgrade, address the 732 vulnerabilities with low LOE - updating poms with higher versions with minimal risk of breaking changes, and possibly address some of the mediums, and now only have the subset of vulnerabilities left - 381.

Relevant log output

- Examples: guava 10 to 32, if any @beta APIs were used, and/or methods which were used are overloaded in the later v32, we will have work cut out for us in refactoring. 
- Domj 1.61 is EOL, thus JDOM, JAXB, StAX should be considered, but now require refactoring
-log4j 1.2.17 is EOL - Log4J2 or SLF4J should be considered, requiring refactoring

cTAKES.error.log contents

Version

7.0.0-SNAPSHOT

What operating system are you seeing the problem on?

No response

Contact Details

No response