Empty report after update to 10.0.4

[holubec-petr]

Hi,

we are using the dependency check Gradle plugin to scan our multi-module Kotlin project.

Everything worked as expected until version 10.0.3 (included) but after the update to version 10.0.4 the result of the dependencyCheckAggregate task is an empty XML report (the list of dependencies is always empty).

The dependency check Gradle plugin is configured as follows:

dependencyCheck {
    format = XML.toString()
    scanProjects = listOf(":application")
    scanConfigurations = listOf("runtimeClasspath")
    skipGroups = listOf("com.example")
    nvd.datafeedUrl = "https://example.com/scan/api/v1/nvdcache"
    nvd.datafeedUser = "user"
    nvd.datafeedPassword = "secret"
}

When I comment out the scanProjects parameter the report contains a lot of dependencies but also dependencies of our testing modules which we want to exclude from the scan.

Is the configuration somehow wrong or what happened between these 2 latest releases that can cause such a behavior? I went through the latest commits but nothing suspicious for me.

I tested this behavior with Gradle 8.8 and 8.10.1.

Thank you for any help, Petr

[toplac]

We are having the same issue

[jeremylong]

The only changes impactful changes to the plugin since 10.0.3 are:

• https://github.com/dependency-check/dependency-check-gradle/pull/407 - very unlikely source of the problem
• https://github.com/dependency-check/dependency-check-gradle/pull/403 - very unlikely source of the problem
• https://github.com/dependency-check/dependency-check-gradle/pull/404 - most likely the source of the problem

See https://github.com/dependency-check/dependency-check-gradle/issues/187

[jeremylong]

My guess is due to the change in #404 we need to update the documentation.

[holubec-petr]

I inspected the #404 changes but I cannot see anything that could break my configuration. It only adds some new methods.

[toplac]

My guess is due to the change in #404 we need to update the documentation.

What exactly needs to be changed?

[jpicton]

We're seeing a similar issue. Using Gradle 8.10.2 and Dependency Check 10.0.4, we get the followng report contents for the following config (note tests="0"):

<?xml version="1.0" encoding="UTF-8"?><testsuites failures="0" name="dependency-check" tests="0"></testsuites>

dependencyCheck {
    analyzers {
        assemblyEnabled = false
        nodeAudit {
            enabled = false
        }
        nodeEnabled = false
        ossIndex {
            username = project.properties.ossIndexUsername
            password = project.properties.ossIndexPassword
        }
        retirejs {
            enabled = false
        }
    }
    nvd {
        apiKey = project.properties.nvdApiKey
    }
    formats = ['CSV', 'JUNIT', 'HTML']
    scanConfigurations = ['runtimeClasspath']
    suppressionFile = project.file('config/dependency-check/suppressions.xml').absolutePath
}

After rolling back to 10.0.3, the report contents are correctly populated (using the same config as above):

<?xml version="1.0" encoding="UTF-8"?><testsuites failures="0" name="dependency-check" tests="177"><!-- redacted --></testsuites>

Note tests="177", and all the individual test suites are included in the reports (I've redacted the details here).

Does the dependencyCheck Gradle configuration need to be changed? I note that IntelliJ highlights analyzers as a deprecated method because of the use of a closure. However, I wouldn't have expected a deprecation to impact the resultant report.

[jeremylong]

@Vampire do you have any thoughts on this?

[Vampire]

I would wonder if #404 is related, as OP does not even use any of the affected methods, neither the Closure ones, nor the Action ones.

And the deprecation @jpicton sees is also unrelated, it is more a false-positive. In Groovy DSL the Closure variant is chosen, but if you delete the Closure variants of the methods, it will still continue to work properly as the Groovy DSL then just uses the Action variants with exactly the same syntax on the consumer side. The effect of using the Closure variants and the Action variants also is identical if I did not add a bug, but as I said, OP is using neither of those methods anyway.

Even though you said #403 is very unlikely the problem, this would more have been my suspicion. skipTestGroups by default is true and that is what this PR is fixing. Behaviour did indeed change to be more like 9.1.0 again which broke in 9.2.0 and was corrected with 10.0.4.

So it seems something in configuration.hierarchy is a test configuration and thus the configuration in question is skipped.

In 9.1.0 this was hard-coded to only match if in configuration.hierarchy is either testCompile, androidTestCompile, or testImplementation.

In 9.2.0 you intended to also here use the improved regex matching for test, test..., ..._test, ..._test..., ...Test, and ...Test.... You just had a bug in there that caused it to almost always not match and that is what was fixed in #404.

So the question might be which configuration in the hierarchy is causing this detection to trigger and an MCVE might be necessary to decide how or whether at all to fix this properly.

As a work-around you could set skipTestGroups to false and instead manually configure the configurations to be skipped.

Btw. the v10.0.4 tag is missing in the repository.

[holubec-petr]

I can confirm that setting skipTestGroups to false makes the analysis to work again.

May be worth to note that we are heavily using java-test-fixtures plugin (https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures).

[Vampire]

Then it is probably appropriate and intended that skipTestGroups skips that configuration. That fix should maybe have been handled like the breaking change it is, though. What I wonder is, why your production runtimeClasspath configuration extends a test fixtures configuration though.

[holubec-petr]

I tried to print my configuration hierarchy and finally found the problem.

It is configuration called testAndDevelopmentOnly added by Spring Boot plugin (implemented in this issue: https://github.com/spring-projects/spring-boot/issues/35436).

The question is whether this configuration should be in runtimeClasspath configuration hierarchy but it is done by the Spring Boot plugin.

[Vampire]

Sounds to me like a spring boot plugin bug then, especially as that linked issue says that testRuntimeClasspath should extend from it which sounds correct, not runtimeClasspath.