What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, de

What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, deploy and bobs your uncle you are good. But some projects are little more interesting in that they include libs like this, or include libs that include it. It is part of their foundation/framework. So you can still put in override and ignore what the lib wants. But now when it comes time to upgrade that top lib maybe there are 6 newer versions of the one problematic lib you were concerned about today, but now it is a year later and you forgot about it. What is the mental context to say 'oh yeah go back and check that'. You may have got used to ignoring the 'hey you are overriding that jar file'. Are you going to do that for all of the libs/jars this top level framework drags in? It is not just java that has this sort of issue. NPM (though you can float the versions at least), nuget, rust, C++ containers, etc. A lot of projects out there have taken on this maven central style building. Which is a huge productivity boon. But in many ways has not helped us with dependency hell, and in some cases has made it wildly worse. I see simple projects pulling in 150+ items in some cases. What is the mental context of actually managing that? And have real fun if your project depends on a 'dead' project where there are little to no updates. This one is at least high profile enough that many people are revisiting old build chains that have long ago been forgotten and updating them. That will kill out many other vulins that have been lurking. But many will just do that one jar set and call it a day. But you are probably right we are going to get see a few of these style of attacks.