inject artificial dependencies (conditional on existing ones)

[mirabilos]

Is your feature request related to a problem? Please describe.

I discovered… things… during a licence review of our project’s dependencies. For example, byte-buddy and Lombok both contain embedded code copies of ASM. Spring also does, but its is contained in its sources, but it also contains embedded code copies (shaded at compile time) of cglib and objenesis. It’s not impossible to discover the precise versions used.

I’m pretty sure that these recursive dependencies^W^Wembedded code copies are not scanned correctly.

Describe the solution you'd like

I would like to have it possible to declare to-be-injected dependencies. I’m already using this in my “create a PKZIP archive containing all sources.jars of all dependencies, recursively” script, which has an additional input file (backslash+newline and comment lines ignored), in which Maven groupId:artifactId:version vectors are listed, the first one is the “trigger”, the other ones on the line are the ones to be added. For example:

~/Misc/Vendor/VerA.web $ cat release/ckdep.ins
# shaded into byte-buddy
net.bytebuddy:byte-buddy:1.10.3 \
        org.ow2.asm:asm:7.2 \
        org.ow2.asm:asm-commons:7.2

This line makes it add asm and asm-commons 7.2 and their recursive dependencies asm-analysis and asm-tree to the list of sources to pull.

This could also be useful for the OWASP dependency check plugin. I’d most likely add Spring’s ASM copy to it, as to catch security issues in it more easily.

Describe alternatives you've considered

I’ve looked at (generating from the list above) dependency-hint XML files but don’t think they are powerful enough to express “when artifact foo.bar:baz:1.2 exists, add bla.meow:foo:3.4 to the list of dependencies present in the project”.

[mprins]

note that projects using shading generally on "shade-in" what they need. It would be much preferable to check if a vulnerability actually exists and then create an update at NIST for that CVE for the lib that you use

[mirabilos]

Mark Prins dixit:

note that projects using shading generally on "shade-in" what they need.

Yes, two entire other JARs…

It would be much preferable to check if a vulnerability actually exists and then create an update at NIST for that CVE for the lib that you use

I don’t understand what that even is, and something NIST/CVE/whatever is not something I, as end user, can do. I just want to make able to flag vulnerabilities in, say, asm, if a project doesn’t use it directly but only via, for example, Spring or Lombok or byte-buddy.

[aikebah]

don’t understand what that even is, and something NIST/CVE/whatever is not something I, as end user, can do

Maybe over time you learned already, but nevertheless wanted to elaborate on it for you, or others passing by this ticket: It is something you as an end-user can do (it's highly appreciated by the NIST NVD team (https://nvd.nist.gov) to get corrections to their listings from the community). It is however something that will typically take a few business days to process and take effect.

For a quick local scan on what to report you can scan the actual thirdparty dependency that you know to be shaded-in to see which vulnerabilities are reported for the library, but not for your dependency that shaded-in the library.

At the NIST NVD website there is a contact form currently hosted at https://nvd.nist.gov/info/contact-form that you can use among other for CPE URIs missing which I think is the item most appropriate for those reports. Another option is the Are we missing a CPE here? Please let us know. link at the bottom of the NVD vulnerability page in the affected configurations section for the CVE (which is present as a reference in your dependencycheck report when scanning the actual thirdparty library)

You would tell them for which vulnerability (identified by a CVE-yyyy-nnnnn identifier) you are missing what software in the Known Affected Software Configurations and provide them with some further details on how you determined that the shaded-in library is indeed shading the vulnerability into that other software.

They do expect you to provide information on why that vulnerability would also apply to the library that is shading in the project and the analysis you do before submitting should include at least asserting that the vulnerable code is indeed included.

As an example I recently reported to them (as a result of my investigation on #4316) that certain reload4j versions are also known to be affected for a some log4j v1 CVEs (which they list on there homepage as fixed in releases beyond the initial release) as well as that apparently a vulnerability listed only for log4jv2 in the NVD should be extended to log4jv1, because it's listed on the reload4j page that they patched it in their fork of log4j v1. With references to the reload4j page that listed their history of fixed CVEs and the versions in which they were fixed. As a result the NVD was able to update those listings and extend the Known Affected Software Configurations for the CVEs.

The advantage of sharing your information with NVD is that all users of DependencyCheck, as well as users using NIST NVD in other ways, will benefit from your analysis and get the vulnerability properly listed (and you get it for all you projects without a need to explicitly re-specify the additional dependencies in a dependencycheck configuration file).