[Bug]: OWASP Security Scan of the 6.0.0 branch

[Johnsd11]

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

[Johnsd11]

Please share your report on vulnerable items! We are using a couple of tools but they are definitely not uncovering so much information. I want ctakes 6.0.0 to be as hardened as possible, so having this in hand couldn't hurt - as daunting as it may be. I like the fact that it has a separate column for ctakes as-a-dependency issues.

There are several ways to do this, but I have no idea which would be best for everybody. I think that If you have a fork of ctakes you can share a pull request with the main ctakes repo. I haven't done it myself, so I can't attest to the facility of such a workflow. You could also create and share a gist containing proposed changes. The easiest thing to do might be to simply open a topic on the ctakes 'issues' page and attach files or paste segments of code. These are just options - there might be better ways to do this.