jfrog / jfrog/jfrog-cli-security

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

Open
#603 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
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 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
  1. Run jf.exe audit (or jf.exe audit --gradle)
  2. Review the CVE report showing vulnerable dependencies
  3. Fix CVEs by updating dependency versions in app/build.gradle
  4. Run jf.exe audit again
  5. 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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.