Gradle task :dependencyCheckAnalyze gives different result depending on version of AGP

[Pururun]

Describe the bug
Running the :dependencyCheckAnalyze gradle task gives different result depending on which version of the android gradle plugin is used. This is despite the dependencies that generate the CVE errors have not changed.

Version of dependency-check used
Using org.owasp:dependency-check-gradle:9.2.0
Also seen this behaviour on 9.0.9

Log file
https://gist.github.com/Pururun/89199a37e9794bac5969193f2a5ed685

To Reproduce
Update to AGP 8.4 or 8.5

Expected behavior
Consistent behaviour regardless of AGP version.

Additional context
Here is our configuration if gradle:

global gradle

allprojects {
   configure<org.owasp.dependencycheck.gradle.extension.DependencyCheckExtension> {
        failBuildOnCVSS = 0F // All severity levels
        suppressionFile = "${rootProject.projectDir}/config/dependency-check-suppression.xml"
    }
}

test gradle

configure<org.owasp.dependencycheck.gradle.extension.DependencyCheckExtension> {
    // Skip the lintClassPath configuration, which relies on many dependencies that has been flagged
    // to have CVEs, as it's related to the lint tooling rather than the project's compilation class
    // path. The alternative would be to suppress specific CVEs, however that could potentially
    // result in suppressed CVEs in project compilation class path.
    skipConfigurations = listOf("lintClassPath")
    suppressionFile = "$projectDir/../test-suppression.xml"
}

Here is the suppress file for the app:
https://github.com/mullvad/mullvadvpn-app/blob/main/android/config/dependency-check-suppression.xml

Suppression file for tests:
https://github.com/mullvad/mullvadvpn-app/blob/main/android/test/test-suppression.xml

[chadlwilson]

This is more likely an issue for https://github.com/dependency-check/dependency-check-gradle than here.

All of the "new" CVEs are because the new android-gradle-plugin version is dynamically adding a whole lot of new Gradle configurations such as app:_internal-unified-test-platform-android-test-plugin-result-listener-gradle from the unified-test-platform which have vulnerable dependencies and are now being detected and scanned by default (where they were not in earlier versions). I suspect they changed something about the way the plugin works.

These configurations dont exist in the ODC report for earlier versions. You can see them in the HTML report for a new version.

I tried to quickly configure these configurations to be skipped, but it doesn't seem to work, probably due to the time within the Gradle lifecycle at which that plugin creates the configurations.

    afterEvaluate {
        configure<org.owasp.dependencycheck.gradle.extension.DependencyCheckExtension> {
            skipConfigurations = configurations.filter { !it.name.contains("unified-test-platform") }.map { it.name }
        }
    }

If you understand AGP better than I, you might want to try what happens if you ensure that AGP is configured prior to the ODC plugin (normally order is dependent in plugins { } blocks, but you folks seem to use a mixture of this and buildscript dependencies, so not sure.

If you think that the plugin should have an obvious way to detect and exclude these special configurations or shouldn't be looking at them, it might be something similar to dependency-check/dependency-check-gradle#239 however I am not sure :-) Generally speaking, all configurations are valid to scan unless configured otherwise, I believe.

[Pururun]

Thank you for your help and sorry for the late response.

I tested some ways to change the ordering of the plugins but unforunately this did not help.

I have posted a new issue in the correct project.

Thanks again.

[chadlwilson]

Yeah but did you actually try the skipConfigurations approaches? You haven't documented what you tried.

The problem is not that the plugin is inconsistent between AGP versions as you describe nor that there are vulnerabilities detected. Thats because they changed something and started dynamically generating new configurations which is outside of ODCs direct control including a dependency on a vulnerable component. ODC probably cant know what all these configurations mean and which are important vs not important sinxce they are context dependent.

The real issue seems to me if you can't find an approach to skip them if you don't care about them as the vulnerabilities are totally valid (to some). Root cause for that may be ODC or the way the AGP works but hard to tell.