JFrog CLI audit does not reflect dependency changes made in subproject build.gradle files

[RichardWinkelmann]

Describe the bug

When running jf audit on an Android Gradle project, dependency changes made in subproject build files (e.g., app/build.gradle) are not reflected in subsequent audit results. The audit continues to show outdated CVE information until the root build.gradle file is modified.
This behavior suggests a caching mechanism or file change detection that only monitors the root build.gradle, but the exact cause is unclear. For Android projects following the standard Gradle multi-project structure, this is problematic as dependencies are typically managed in app/build.gradle rather than the root build file.

Current behavior

• Running jf audit or jf audit --gradle on an Android Gradle project generates a CVE report
• Modifying dependencies in app/build.gradle (e.g., version updates to fix CVEs) does NOT result in updated audit results
• Subsequent jf audit runs continue to show the same CVE list from the initial scan
• Results are ONLY updated when the root build.gradle file is modified with actual content changes
• Updating only the file timestamp (e.g., via touch command on root build.gradle) does NOT update the results

Reproduction steps

1. Set up an Android Gradle project with standard structure:

project-root/
   ├── build.gradle (root-level config)
   ├── app/
   │   └── build.gradle (contains dependencies)
   └── settings.gradle

2. Run jf.exe audit (or jf.exe audit --gradle)
3. Review the CVE report showing vulnerable dependencies
4. Fix CVEs by updating dependency versions in app/build.gradle
5. Run jf.exe audit again
6. Observe: The CVE list remains unchanged despite the dependency updates

Workaround that does work:

• Manually edit root build.gradle (e.g., add a comment // or blank line)
• Run jf.exe audit again
• Observe: Results now reflect the updated dependencies from app/build.gradle

Expected behavior

The audit results should reflect the current state of all project dependencies, regardless of which build.gradle file they are defined in. Possible solutions could include:

Option 1: Detect changes in ALL Gradle build files within the project hierarchy, not just the root build.gradle

Option 2: Provide a --no-cache or --refresh flag to force re-evaluation of all dependencies

Option 3: If file timestamps are used for change detection, consider all relevant build files in the project structure

Option 4: If this is not a caching issue, investigate why subproject dependency changes are not being detected

JFrog CLI version

jf version 2.82.0

Operating system type and version

Windows 11

JFrog Artifactory version

No response

JFrog Xray version

No response