> https://github.com/jveverka/mvn-dependency-log4j/commit/ac87977c19bb2ee2564d15fa87f255d621a4706d
https://github.com/pzygielo/mvn-dependency-log4j/runs/5425284512?check_suite_focus=true#step:5:1
No log4j:1.2.12:jar is downloaded in that reproducer.
log4j/log4j is excluded by commons-logging
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
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 wrote:
> Hey guys
> Let’s be courteous and civil.
>
> As part of vulnerability management, an assessment has
Adding Juraj back in the chain as I see that he is removed.
Juraj,
Can you please look at the below 6 emails in this chain?
Thanks,
Venu
On Thu, Mar 3, 2022 at 3:07 AM John Patrick wrote:
> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata
Just to add my 2 cents:
Many security scanning tools are not smart enough to detect the context, or
in other words, they will mark as an issue a dependency that's only used
with "test" scope even if it's not used in the final jar, and in the same
line, there are some dependencies that can be
