Use GitHub's dependency submission API from a workflow that runs when your project is built. The GitHub docs describe it as a way to submit dependencies resolved at build or compile time, and list a pre-made Gradle dependency submission action. The result is a graph based on what your build resolves, not just what the files declare.
The problem it solves
Static reading of a build file sees only declared dependencies. A Gradle build resolves a graph that includes transitive dependencies, platforms, constraints and plugin supplied versions. A tool that guesses from the file can differ from what the build actually pulls in.
GitHub describes the dependency submission API as a method of submitting data to the dependency graph, one that can add dependencies that static analysis does not capture, such as the dependencies resolved when a project is built or compiled.
Static versus build-time
| Approach | Reads | Strength | Weakness |
|---|---|---|---|
| Static parsing of build files | Declared coordinates | Fast, no build needed | Misses resolved and transitive detail |
| Build-time submission | The resolved graph | Matches reality | Needs a working build in CI |
| Lockfile reading | Locked versions | Deterministic | Only where locking is enabled |
Steps
- Pick the workflow that runs a normal Gradle build on your default branch.
- Add the Gradle dependency submission action listed in GitHub's documentation, and read its own README for the current version and permissions.
- Give the job only the permission it needs to write to the dependency graph.
- Run it on pushes to the default branch, so the graph reflects what is merged.
- For multi-project builds, confirm every subproject appears. See scanning Gradle multi-project builds.
- Compare the submitted graph with your own SBOM, and investigate gaps.
What it does not do
A graph is an inventory. It does not tell you which findings are reachable, and it does not stop a bad version from being merged. For that you need a policy gate on the pull request, covered in how to block vulnerable dependencies in a pull request.
Watch for incomplete coverage
Build-time submission only sees the configurations the workflow resolves. If the workflow builds the debug variant of an Android app, release only dependencies may be missing. Choose the configuration deliberately and record which one you used.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare how the list looks with your own graph and check whether transitive components are included.
Safeguard's SBOM and dependency scanning build an inventory from your repository, and the free scan at gold.safeguard.sh/scan is a quick way to compare it with your graph.
Quick check
Does the submission API replace static analysis?
No. GitHub describes it as adding dependencies that static analysis does not capture.
Is there a ready-made Gradle action?
GitHub's documentation lists a Gradle Dependency Submission action among its pre-made actions. Check the action's own page for current usage.
Sources
Last reviewed: 19 October 2026.
