Problem on testNG : CVE-2022-4065

[MustanK57]

Hello,

Microsoft want the migration from ADAL to MSAL, but this migration is blocked by this vulnerability.
This vulnerability will be resolve soon (before the end of June ?).

Thank you

[bgavrilMS]

@Avery-Dunn - I see MSAL Java using testng 7.1 - I assume bumping to testng 7.7 should not be a problem. I see that DependaBot proposed a fix #648 but the PR was closed without comments. Can you please add your reasoning for this?

@MustanK57 - thanks for pointing out, we'll look at this ASAP. Do you know what the attack vector is, since this is a test dependency only?

[MustanK57]

Vulnerability scan detect it on the download, and I need to be sure if it can cause a problem while I use this package.

[bgavrilMS]

Ack, an attack vector in unlikely, but security tools prevent from using latest MSAL. We'll fix this with priority (definitely hopefully before end of June).

[bgavrilMS]

@siddhijain investigated this and can provide a few options. Seems like it's not an easy fix.

[bgavrilMS]

@DidunAyodeji @localden - I believe this may be higher priority than brokers or Managed Identity, as folks will not pick up a package with a CVE label.

[siddhijain]

It is not a simple fix to upgrade the version of this library as the latest secured version of test-ng is on Java 11 and msal java is built using Java 8.

We can transition from TestNG to a different framework, such as JUnit, which is widely recognized as one of the most popular testing frameworks in the Java world. However, it's important to note that the latest version of JUnit (JUnit 5) does not support the mocking framework currently used in MSAL Java (PowerMock). We have two potential approaches: either we can shift to an older version of JUnit (JUnit 4), or we can consider migrating the MSAL Java library to a mocking framework compatible with JUnit 5.

From my research, the rest of the migration from test-ng to JUnit should be simple.

[localden]

@siddhijain @bgavrilMS what is the support expectation around JUnit 4? Want to make sure that we're not taking a dependency on a library that will be deprecated. I see on GitHub that the latest release was in 2021.

I am leaning towards option (2) of upgrading both the testing and mock frameworks, but would also like to understand the cost and timeline implications here.