Unable to scan library in Web-INF/ Lib

[tech-surajrk]

@stevespringett - Is there a way to scan the legacy libraries which are present in Web-INF/Lib but not part of build.gradle.

Currently when I use cyclonedx, it generates bom for all the libraries defined in build.gradle but if there is any library not part of build.gradle, it excludes those libraries from BOM

So I want to know if there is any way to define a path in build.grqdle so that cyclonedx will generate bom with libraries that is present in that path? Or is there any other solution that you can recommend?

[stevespringett]

I don't think that's possible today with the gradle plugin. @prabhu, does cdxgen support this?

[prabhu]

@stevespringett Yes, cdxgen supports -t jar mode. However, it is not possible to combine this with java, so needs some enhancement and testing.

https://github.com/CycloneDX/cdxgen/blob/ef453ca771c4481b771f5dcd8db9aaef44025abe/index.js#L897

[tech-surajrk]

@stevespringett Yes, cdxgen supports -t jar mode. However, it is not possible to combine this with java, so needs some enhancement and testing.

https://github.com/CycloneDX/cdxgen/blob/ef453ca771c4481b771f5dcd8db9aaef44025abe/index.js#L897

@prabhu My requirement is only to scan jar libraries from build.gradle + the jar libraries which are present in specific path which is not part of build.gradle.

I tried using cdxgen also but still it is also not scanning any jar library outside build.gradle. I dont know if I am missing any settings that I have to add in build.gradle to scan jar libraries from a path

[prabhu]

@tech-surajrk Could you share the cdxgen command used? Did you specify -t jar?

[tech-surajrk]

@tech-surajrk Could you share the cdxgen command used? Did you specify -t jar?

@prabhu using '-t jar ' - I am able to generate bom but the group name for each component is coming as undefined or blank. Hence Dependency Track is not able to map any cve against the component Is there any way to generate correct group name for each component?

[prabhu]

@tech-surajrk What you're describing is a problem that is a bit more complex to solve. Essentially we need a mechanism to match an artifact to its identifier. There are a few techniques.

• Parse the META-INF/MANIFEST.MF in the jar file and try. This is the current cdxgen approach which is quite imprecise and doesn't work for legacy jars
• Have a hash of all jars in the world and compare to find all the properties. This approach is taken by trivy and a few commercial tools. It might work, but not fool-proof
• Have a semantic fingerprint of all jars in the world and try to predict the closest match. Theoretical and coming to cdxgen this year if all goes well

So at this point, trivy is your best bet.

[Eiim]

I'd like to mention syfts' approach, which uses the filename as well as MANIFEST.MF. It's not perfect but it seems much more accurate than cdxgen, as most jars use the name-version.jar convention. I also strongly suspect that cdxgen's manifest parsing logic could be much improved, although vendors do lots of weird, out-of-spec things with manifest files so I don't necessarily blame cdxgen for having issue parsing these.

[prabhu]

@Eiim cdxgen also uses the filename as a fallback. Could you file a ticket on cdxgen about the parsing logic improvements? Happy to take it up.