Are there plans to upgrade old dependencies?

[jasonli197]

For some context, at my workplace we leverage Mirth Connect 4.5.0, which is the latest version at the time of this post. Specifically, we leverage the image provided by Nextgen via dockerhub:

https://hub.docker.com/layers/nextgenhealthcare/connect/4.5/images/sha256-88ea431a1da48d1fe3809a76bb60feaca811442a60917cfacb46cc79c9111897?context=explore

Doing due diligence on our side, we scanned the container that Mirth Connect eventually utilizes and unfortunately there are quite a lot of report vulnerabilities reported by Trivvy:

trivvy_mirth_connect_scan_results.json

I've attached the scan results above. This scan was done 2024-05-07 and some of the results were for Derby and Postgres. Examples:
https://nvd.nist.gov/vuln/detail/CVE-2024-1597 (Postgres)
https://nvd.nist.gov/vuln/detail/CVE-2015-1832 (Derby)

I recognize that Derby is not recommended to be used in production, but this is simply some example excerpts from the Trivvy scans.

I have a few questions regarding security:

1. Are there plans to upgrade older dependencies that MIrth Connect uses?
2. If Mirth Connect is not vulnerable to a certain CVE, are there some sort of advisory that could be leveraged?

Thanks!

[jonbartels]

I discussed this problem recently in Slack - https://mirthconnect.slack.com/archives/CJKSCKQMR/p1715978777328309

I had similar failures from an X-Ray scan against MC 4.5.0. The approach I am taking is to monkey patch my container images and swap in newer JARs. Based on my long experience with Mirth, this approach is low risk but not zero risk. Minor releases of libaries should just work, but some of the libraries being updated (notably SSL and crypto libs) can sometimes fail in unexpected ways that are hard to diagnose.

The main reason I am monkey patching is because the Mirth releases tend to be quarterly. This is a relatively long time between a CVE being published and Mirth updating.

Are there plans to upgrade older dependencies that MIrth Connect uses?

The last few releases have addressed routine JAR updates. I do not work for NextGen but I have observed the current Mirth team committing to routine updates and accepting community PRs for library updates. The engineering team under @ARShelleyNextGen and @JackieK5 have demonstrated that they want to keep Mirth up to date and are responsive to the community.

If you are interested in contributing, this PR for JSch updated is a good example of the maintainers accepting a community submission to update libraries. It's kind of funny since one of the failures I'm seeing in my scans is that same JSch library so we have to update it again! LOL

If Mirth Connect is not vulnerable to a certain CVE, are there some sort of advisory that could be leveraged?

I think the answer is "no". In my opinion, I would rather have NextGen, the Mirth team, and the community just updating libraries and releasing patch versions. This effort would be more productive and solve the problem and likely require less time than issuing advisories. The advisory should just be, "we saw the CVE too, here's a tested update, please upgrade to MC 4.x.y+1"

An excellent historical example of such an advisory not going well is the discussion about Log4J from 2021 . The engineers reliably proved that the Log4J vulnerabilities could not affect Mirth. They issued statements and proof and still got roasted because everyones security scanners were failing Mirth. While most responsible users would read and understand such advisories, there will be a noisy minority that will not accept anything less than a perfect security scan. The stress and lack of decorum in that discussion has to have taken up a lot of effort and time that could have been used to fix the issue and update.