[MNG-7359] Dependency-Management insufficient to cope with today's security threats

[jira-importer]

Jörg Hohwiller opened MNG-7359 and commented

Maven is a great and flexible tool. However, today critical CVEs come up every day (see log4j desaster). The idea of maven is that via some parent POM build logic can be reused to manage and maintain bigger projects.
To fix such CVE I tried to update the version of log4j in parent pom and imported the BOM of log4j. However, this does not help and projects derived from that pom still load vulnerable versions of log4j as they get it from transitive dependencies.

What is required in maven is some configuration in dependencyManagement to tell maven "Hey, whenever you choose X as depndency you have to use AT LEAST version Y". However, maven is lacking this feature and hence fixing CVEs is error prone and leads to unexpected results.

Maybe the new maven major version gives the opportunity to address this issue. In case it was already addressed and I missed this somehow, simply cloase as invalid and sorry for the spam.

Side note: Also a maven repo should somehow have the ability to mark releases with critical CVEs so the download is either aborted (maybe unintendet) or at least a FAT WARNING is logged whenever that dependency is pulled.

Maybe in todays world of cyberwar it would even be suitable to have a tool like owasp-dependency-check built into maven natively by default...

---

No further details from MNG-7359

[jira-importer]

Jörg Hohwiller commented

According to my analysis with current maven (3.x) it behaves as following:

• The first declaration in dependencyManagement overrides later declarations - e.g. when importing multiple BOMs
• When I add a dependency or import a BOM in a child it will automatically override anything from the parent POM.

In general this gives me some kind of control so the parent does not "block" me. However, all this behaviour is rather intransparent and I do not know if it is even documented.
Obviously it is kind of complex both for the developer writing POMs as well as for developers crafting maven.
However, I would just like to ask if you can think about some feature in maven (potentially 4.x+) to ensure something like my requirement to say "whenever you choose X as depndency you have to use AT LEAST version Y" in a POM that will then apply for all derived POMs.

Maybe the strategy to how to choose between multiple versions for the same artifact in dependencyManagement should be revisited. Instead of deciding by order (first declaration wins) a decision of "latest is grates" would be more beneficial for CVEs. However, there will always be cases, where I want to have some kind of manual override in my actual POM.
However, my thoughts are:

• In my child POM I always have control by adding an explicit dependency with the version included to override any dependencyManagement.
• When I want to express this "whenever you choose X as depndency you have to use AT LEAST version Y" from a security point of view, it may make sense to add a new way to explicitly express this in dependencyManagement of a new extended model for maven 4.x due to downward compatibility. Making things explicit is also always a good idea. While current dependencyManagement is more something like a "recommendation" the new feature from security PoV is something else: a hard constraint as I want to express "use at least version Y because older versions are insecure".

[jira-importer]

Michael Osipov commented

This is somewhat related to MNG-6772 and friends.

[jira-importer]

Tamas Cservenak commented

Jörg Hohwiller Howdy! I don't quite get the issue you have: if you define depMgt in your project top level ,that should win, irrelevant of "transitive deps" (unless there are some GA coordinate change in play?)

"... tried to update the version of log4j in parent pom .. projects derived from that pom still load vulnerable versions of log4j as they get it from transitive dependencies." – this sounds wrong. If you added a dependencyManagement with "correct" (fixed, non-vulnerable) version of log4j in parent, the downstream projects WILL pick it up, UNLESS they have overriding dependencyManagement section as well. Otherwise it is a bug (but you do not specify how did you "tried to update the version of log4j in parent pom").

It is usually very good practice to have depMgt section to "key" dependencies (true, many times you don't know ahead of time what dependency is "key", see log4j 2.x issue, but then you just add new entry for it and life goes on).

So am still unsure what you did in parent POM that allowed that child transitive "win".

[jira-importer]

Jörg Hohwiller commented

Hi Tamas Cservenak, Sorry for the late response.
Did you also read my first comment?

When I want to express this "whenever you choose X as depndency you have to use AT LEAST version Y" from a security point of view, it may make sense to add a new way to explicitly express this in dependencyManagement of a new extended model for maven 4.x due to downward compatibility. Making things explicit is also always a good idea. While current dependencyManagement is more something like a "recommendation" the new feature from security PoV is something else: a hard constraint as I want to express "use at least version Y because older versions are insecure".

This is currently unsupported and to be honest for an average maven user, dependencyManagement is black-magic that according to my observation most users do not understand what is going on even with great tooling such as m2e. It is just not visible and understandable which version is used why in case of complex POM and BOM hierarchies.

In the end current dependency management only gives a kind of suggestion for maven in case a version is omitted. But if some (transitive) dependency specifies another dependency with a specific version that version may be used regardless of any dependency management. So in some case you can fix a CVE via dependency management and in another you have to duplicate the dependency into your project artifact(s) - and this could be many redundant places - with the secure update version even though your artifact(s) do not really depend on this but just another and maybe only in a specific version and after an update you would not easily know if that is still the case.

So what I want to say is that this is not maintainable in complex projects.
What we actually need in maven5 is a new property minVersion for a dependency in dependencyManagement. Then if maven resolves a dependency in your tree it must use at least this version so in case you get an explicit version from a transitive dependency that is lower it will automatically be replaced with minVersion.

I hope that I managed to make my point more clear now.