Request: Add Gradle build-script dependency detection using the Gradle dependency engine

Problem

Component Detection currently supports Gradle only when dependency lockfiles are
already present. The Gradle detector does not evaluate build.gradle or
build.gradle.kts, execute Gradle, or generate a dependency graph from the
resolved build.

This creates a significant gap for Gradle projects:

• Many Gradle projects do not use dependency locking.
• A normal Gradle build does not necessarily produce gradle.lockfile.
• Enabling dependency locking requires build configuration changes or additional
  CI-specific setup.
• Static parsing of Gradle build files cannot reliably determine the resolved
  dependency graph, selected versions, variants, exclusions, or transitive
  dependencies.
• Projects using convention plugins, version catalogs, included builds, custom
  configurations, or dynamically computed dependencies may be difficult or
  impossible to analyze statically.
• Users must add a separate workflow step to generate lockfiles or use another
  dependency-submission mechanism before Component Detection can identify the
  complete Gradle dependency set.

Requested feature

Add support for detecting Gradle dependencies by using the Gradle dependency
resolution engine against projects containing either:

• build.gradle
• build.gradle.kts

The implementation should resolve dependencies through Gradle rather than
reimplementing Gradle's dependency semantics in Component Detection.

The implementation could potentially use an injected Gradle init script or a
temporary Gradle plugin/task, so that users do not need to modify their project
build files or commit generated lockfiles.

Relevant prior art

GitHub's Gradle dependency-submission action uses the Gradle dependency graph
plugin and executes Gradle to resolve dependencies. Its documentation states
that dependencies resolved during the execution are included in the generated
dependency graph.

• Gradle dependency-submission action
• Dependency-submission documentation
• GitHub Dependency Graph Gradle Plugin
• GitHub Dependency Submission API

The Gradle plugin also demonstrates applying dependency graph functionality
through an init script and running a dependency-resolution task without
requiring changes to the project's build.gradle or build.gradle.kts.

Implementation considerations

It may be possible to integrate with the existing
GitHub Dependency Graph Gradle Plugin,
reuse its approach, or collaborate with Gradle on a supported output format or
integration point.

This request does not necessarily require Component Detection to generate
or submit a GitHub-specific SBOM. The primary requirement is to obtain an
accurate resolved Gradle dependency graph in a format that Component Detection
can consume and map into its existing component model.

Potential implementation approaches include:

1. Invoke Gradle with a Component Detection-provided init script.
2. Apply a temporary plugin that observes resolved configurations.
3. Reuse or extend the Gradle dependency graph plugin.
4. Define a neutral intermediate dependency-graph format shared between the
   Gradle integration and Component Detection.

Requirements

• Support both Groovy and Kotlin Gradle DSL projects.
• Support Gradle Wrapper-based projects.
• Support multi-project builds.
• Include transitive dependencies and parent-child relationships.
• Respect Gradle's version conflict resolution, exclusions, variants, and
  dependency substitutions.
• Avoid requiring users to commit gradle.lockfile.
• Avoid permanently modifying project files.
• Provide controls for the Gradle command, project directory, configurations,
  timeout, and network access.
• Preserve the existing lockfile-based detector as a fallback.
• Produce useful diagnostics when Gradle cannot be executed or dependency
  resolution fails.
• Document security implications because evaluating a Gradle build may execute
  arbitrary build logic and may require access to private repositories.

Open questions

• Should Component Detection invoke the Gradle Wrapper automatically?
• Should this be opt-in initially because Gradle execution can run arbitrary
  project code?
• Should the implementation depend on the GitHub Dependency Graph Gradle Plugin,
  or should Component Detection maintain its own integration?
• Is there an existing Gradle-supported API or report format that should be used
  instead?
• Can Gradle provide guidance or partnership for exposing a stable resolved
  dependency graph specifically for scanners and SBOM tools?
• Should the generated graph be kept in memory or written to a temporary report
  that Component Detection consumes?

Expected result

A Gradle project without dependency locking should be able to run Component
Detection and receive an accurate dependency inventory, including transitive
dependencies, based on the dependencies actually resolved by Gradle.

The existing behavior should remain available for environments where executing
Gradle is not permitted or where only static lockfile scanning is desired.

Start by reading the existing lockfile-based detector, then review Gradle projects through build.gradle and build.gradle.kts and the Gradle Wrapper. Compare the dependency-submission action and Gradle dependency graph plugin approaches before choosing an integration path. Done means resolved direct and transitive dependencies work for Groovy, Kotlin, wrapper-based, and multi-project builds without modifying project files, while preserving lockfile fallback and reporting failures.