jfrog / jfrog/jfrog-cli-security
JFrog CLI audit does not reflect dependency changes made in subproject build.gradle files
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13
- Forks
- 50
- Avg merge
- 3d 48m
- Merged PRs (30d)
- 26
Description
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 auditorjf audit --gradleon 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 auditruns continue to show the same CVE list from the initial scan - Results are ONLY updated when the root
build.gradlefile is modified with actual content changes - Updating only the file timestamp (e.g., via
touchcommand on rootbuild.gradle) does NOT update the results
Reproduction steps
- Set up an Android Gradle project with standard structure:
project-root/
├── build.gradle (root-level config)
├── app/
│ └── build.gradle (contains dependencies)
└── settings.gradle
- Run
jf.exe audit(orjf.exe audit --gradle) - Review the CVE report showing vulnerable dependencies
- Fix CVEs by updating dependency versions in
app/build.gradle - Run
jf.exe auditagain - 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 auditagain - 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue with the standard project structure using the root build.gradle, app/build.gradle, and jf audit commands, then inspect how audit results respond to changes in each file. Done means a dependency change in app/build.gradle is reflected in the next audit without modifying the root build.gradle.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android
- Domain
- build-system, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100