Hi David Thank you for summarizing the problem, let me explain some details: 1. "The business application is not exposed" - true 2. "The maven build environment might (can’t confirm at this point) download a transitive dependency on log4j 1.x" - this is true, build environment and maven-dependency-plugin in particular is downloading log4j 1.2.12. It is true that runtime is not affected, but it will be definitely better in log4j 1.2.12 dependency is completely removed. I changed the previous example to show that maven-dependency-plugin is indeed affected.
https://github.com/jveverka/mvn-dependency-log4j/commit/ac87977c19bb2ee2564d15fa87f255d621a4706d Can you send me the list of affected projects? I will try to prepare pull requests to remove log4j 1.2.12. Thanks On Thu, Mar 3, 2022 at 11:31 AM Jaladi, Venumadhav < jaladi.venumad...@verizon.com> wrote: > Hi David, > > Thanks for the summary and the suggestion. Sure, we will look at how best > we can handle this with our Security team. > > Thanks, > Venu > > > On Thu, Mar 3, 2022 at 4:20 AM David Milet <david.mi...@gmail.com> wrote: > >> Hey guys >> Let’s be courteous and civil. >> >> As part of vulnerability management, an assessment has to be made about >> the potential security impact of a vulnerability in software. >> >> New vulnerabilities are found every day on older components and it is not >> practical nor feasible to chase down every rabbit. >> >> What I read from this chain is >> 1. The business application is not exposed to any log4j vulnerability - >> that’s the most important >> 2. The maven build environment might (can’t confirm at this point) >> download a transitive dependency on log4j 1.x which has a newly found >> vulnerability. IMHO the impact is low. it’s a build environment, not actual >> business application and you surely don’t (and shouldn’t) build on your >> production systems. The probability of occurrence of an attack on this is >> probably null, knowing that attack vectors on log4j involve tricking the >> exposed application into logging something malicious, and a build >> environment does not expose logging to outside like a web app would. >> Based on this, I’d flag those occurrences at the scanner as assessed and >> ignored and move on. >> >> As a best practice, clean up your build environment after each build. Or >> use ephemeral containerized build environments. >> >> >> >> > On Mar 3, 2022, at 02:53, Thomas Matthijs <li...@selckin.be> wrote: >> > >> > That was just to demonstrate how i got the dependency chain, that file >> > was there, but if you're going to be this hostile, i'm not interested >> > anymore, muting thread >> > >> >> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło <piotr.zygi...@gmail.com> >> wrote: >> >> >> >>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs <li...@selckin.be> >> wrote: >> >>> >> >>> Can confirm this project downloads log4j 1.12.12 for me >> >> >> >> As I see it - you confirm something else. >> >> >> >>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12: >> >> >> >> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12: >> >> _artifact descriptor_ >> >> >> >> -- >> >> Piotrek >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> > -- Best Regards -- Juraj Veverka <https://github.com/jveverka> | Solution Design Architect M +421 917 521 285 www.globallogic.sk <https://www.globallogic.com/sk/> <https://www.facebook.com/GlobalLogicSlovakia> [image: GLTwitter] <https://twitter.com/GlobalLogic_SR> <https://www.linkedin.com/company/9409064/admin/> <https://www.youtube.com/channel/UClazQeLF6Oas1ZVs-Iaq2Bg> <https://www.instagram.com/globallogic_slovakia/> http://www.globallogic.com/Disclaimer.htm
