[
https://issues.apache.org/jira/browse/MNG-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537150#comment-17537150
]
Jörg Hohwiller commented on MNG-7359:
-------------------------------------
Hi [~cstamas], Sorry for the late response.
Did you also read my first comment?
{quote}
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".
{quote}
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.
> Dependency-Management insufficient to cope with todays security threads
> -----------------------------------------------------------------------
>
> Key: MNG-7359
> URL: https://issues.apache.org/jira/browse/MNG-7359
> Project: Maven
> Issue Type: Improvement
> Reporter: Jörg Hohwiller
> Priority: Major
>
> 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...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
