Hi François, thanks for the quick response!
The problem is that SBOM tools have no realistic chance to gather that information if all they have is a final artifact and the POMs that were published as is the case here. And as you say: In an ideal world SBOMs would be published along the way but that is hard for e.g. libraries as well because they don't know how they are going to be used: Are any of their libraries going to be overwritten? Shaded? Something else. It is a hard problem. You're just confirming what I feared :) "keepDependenciesWithProvidedScope" seems like a good idea but then we'd need to make sure to have this set _everywhere_ across the supply chain. This topic is going to keep a lot of us awake in the next few years with Cyber Resilience Act and similar regulation. Cheers, Lars On Mon, May 13, 2024 at 5:37 PM Francois Marot <francois.ma...@gmail.com> wrote: > > Hello Lars, > > ignoring your second email, I felt like it is normal for the pom to ignore > the shaded dependencies. This is how Maven works. > For me, it should be the job of a SBOM (CycloneDX format or SPDX for > exemple) to keep the information of what the shaded jar contains. > This is the role of SBOMs. So in an ideal world, the shade plugin would > produce an SBOM to keep track of what is included in the shaded jar. > In an ideal world, SBOMs would also be kept for each Maven jars in the > repositories so they coule be aggregated by the shade plugins. > > After reading your second mail, "keepDependenciesWithProvidedScope" may be > the best easy option you have right now, in a not-ideal world. > > François > > Le lun. 13 mai 2024 à 17:07, Lars Francke <lars.fran...@gmail.com> a écrit : > > > To add to my question I just found that the shade plugin has an option > > called "keepDependenciesWithProvidedScope"[1] which might have helped > > here. > > > > [1] < > > https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#keepDependenciesWithProvidedScope > > > > > > > > > On Mon, May 13, 2024 at 4:50 PM Lars Francke <lars.fran...@gmail.com> > > wrote: > > > > > > Hi, > > > > > > we're hunting vulnerabilities in our dependency tree and I have a > > > question that came up while doing so. > > > > > > We are using HBase (I'm a committer there as well) and HBase has (had) > > > a dependency on the now retired HTrace: > > > > > > <dependency> > > > <groupId>org.apache.htrace</groupId> > > > <artifactId>htrace-core4</artifactId> > > > </dependency> > > > > > > HTrace in version 4.2.0-incubating has a dependency on > > > jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to > > > relocate all of its dependencies[3]. > > > The published POM of HTrace contains no trace of these dependencies[4]. > > > > > > A vulnerability scanner like Trivy[5] does find the code via the > > > META-INF/maven/ files but if HTrace is included via various levels > > > (e.g. Phoenix -> HBase -> HTrace) it is very hard to follow along and > > > find the actual place a dependency comes from. > > > > > > I also tried the Maven CycloneDX generator and that also does not list > > > jackson-databind as a dependency. > > > > > > My question: Is this expected? How can I build an accurate dependency > > > tree that includes all dependencies? > > > > > > I feel like I must be doing something obvious wrong. > > > > > > Thank you for your help. > > > > > > Cheers, > > > Lars > > > > > > > > > [1] < > > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/pom.xml#L308-L312 > > > > > > > > > [2] < > > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L98-L101 > > > > > > > > > [3] < > > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L52-L59 > > > > > > > > > [4] < > > https://repo1.maven.org/maven2/org/apache/htrace/htrace-core4/4.2.0-incubating/htrace-core4-4.2.0-incubating.pom > > > > > > > > > [5] <https://github.com/aquasecurity/trivy> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
