Gradle Package Scanner

The Gradle package scanner automatically detects and extracts all third-party dependencies declared in Gradle build files.

What It Does

Default file: build.gradle

When you enable the Gradle scanner during SBOM creation, CAST SBOM Manager will:

• Extract direct dependencies only from build files - not transitive dependencies - including their names and versions
• Process lockfiles to capture exact resolved versions when available, including both direct and transitive dependencies
• Resolve version variables defined in the same build file using Gradle properties
• Support all configuration types including implementation, api, testImplementation, runtimeOnly, and custom configurations

What Gets Detected

The Gradle scanner identifies direct dependencies from build files and both direct and transitive dependencies from lockfiles. Specifically:

Build Files (build.gradle) - Groovy DSL Only

• Direct dependencies only (not transitive)
• Dependencies in string notation: implementation "group:artifact:version"
• Dependencies in map notation: implementation group: 'g', name: 'a', version: 'v'
• All configuration types (implementation, api, compileOnly, runtimeOnly, testImplementation, annotationProcessor, etc.)
• Version properties and variables defined in the same file
• Extension properties using ext blocks
• Map-based version definitions

Note: Kotlin DSL (build.gradle.kts) files are NOT supported - only Groovy DSL.

Lockfiles

• Modern lockfiles - Single gradle.lockfile at project root (Gradle 6.8+)
• Legacy lockfiles - Per-configuration lockfiles like implementation.lockfile, testImplementation.lockfile in gradle/dependency-locks/ directory

Lockfiles provide the exact resolved versions of both direct and transitive dependencies that Gradle selected during resolution.

How It Works

Basic Dependency Extraction

For a standard Gradle project with a build.gradle file, the scanner:

• Reads the file line by line
• Identifies dependency declarations with recognized configuration names
• Extracts group, artifact, and version information
• Handles both Groovy DSL (single and double quotes) and triple-quoted strings

Version Resolution

Gradle projects often define versions using variables and properties. The scanner:

• Collects variable assignments from ext blocks and property definitions
• Resolves version placeholders like ${slf4jVersion} or $version
• Supports dotted property names like ${versions.slf4j}
• Handles map-based version collections like versions = [slf4j: '2.0.13']
• Resolves nested property references

Platform Dependency Handling

Gradle's platform dependencies define version constraints without directly adding dependencies. The scanner:

• Detects platform(...) and enforcedPlatform(...) declarations
• Excludes these from the dependency list (they manage versions but don't add dependencies)
• Does not resolve versions inherited from platforms

Lockfile Processing

When Gradle lockfiles are present, the scanner:

• Reads exact resolved versions for all dependencies
• Processes modern single lockfiles or legacy per-configuration lockfiles
• Provides precise version information including transitive dependencies
• Deduplicates dependencies across configurations

Single-Line Parsing

The scanner handles various single-line Gradle syntax patterns:

• Standard dependency declarations: implementation "group:artifact:version"
• Inline dependencies blocks: dependencies { implementation "group:artifact:version" }
• Multiple statements separated by semicolons: implementation "a:b:1"; api "c:d:2"
• Triple-quoted strings on a single line: implementation """group:artifact:version"""

What It Doesn't Detect

The Gradle scanner focuses on declared and locked dependencies. It does not detect:

• Build files (direct dependencies only):

  • Transitive dependencies (unless present in lockfiles)
  • Version catalog references - Dependencies like implementation libs.slf4j.api are not parsed
  • Project dependencies - References like project(":core") to other modules in the same build
  • File dependencies - Local JAR files added with files(...) or fileTree(...)
  • Dynamic versions - Selectors like latest.release or 1.2.+ are captured as-is, not resolved

• Build file format:

  • Kotlin DSL (build.gradle.kts) files - only Groovy DSL is supported

• General:

  • Libraries manually copied into your project (not declared in build files)
  • Embedded or copy-pasted code from open source projects

For complete open source detection including undeclared components, enable the OSS Knowledge Base scanning option in the Scanners step, which analyzes actual file content to identify all open source usage.

Limitations

• Single-line parsing only - Multi-line dependency declarations that span multiple lines are NOT captured. Triple-quoted strings are supported only when the entire declaration remains on a single line
• Same-file variable resolution - Variables must be defined in the same build file; external property files are not processed
• Unresolved placeholders - If a version contains unresolved $... placeholders, it will be treated as missing