Tracking ecosystems where GitHub Dependency Graph does not work out-of-the-box

[overcat]

Following the recent discussion about dependency graphs and SBOM submissions, I wanted to start a thread to track software ecosystems where GitHub’s Dependency Graph does not work out-of-the-box.

The goal of this discussion is to collect practical findings from contributors so we can document:

• ecosystems with incomplete GitHub support
• repository configurations required for dependency detection
• workarounds used in practice

Instead of putting everything into a single post, it might be clearer if we track one ecosystem per reply.

That way:

• each ecosystem can have its own explanation
• contributors can add findings incrementally
• the PG Atlas team can easily reference specific cases

I'll start with Gradle in the first reply.

If others have encountered similar issues with ecosystems such as Swift Package Manager, .NET, Go modules, etc., please feel free to add them below.

[overcat]

Gradle (Groovy DSL / Kotlin DSL)

While working with Gradle-based Java projects, I encountered two separate limitations in GitHub’s dependency graph support.

---

1. Package detection issue

Problem

GitHub may have difficulty inferring package coordinates directly from Gradle repositories.

In one of my projects, the package:

network.lightsail:stellar-sdk

was not automatically associated with the repository when using Gradle configuration.

Workaround

Adding a minimal pom.xml allowed GitHub to correctly associate the repository with the package.

Example commit: lightsail-network/java-stellar-sdk@2ba274b

After adding the pom.xml, GitHub was able to recognize the package correctly.

This suggests GitHub’s ecosystem detection works more reliably when Maven metadata is present.

---

2. Reverse dependency tracking issue (Dependents)

Experiment

To verify how GitHub tracks reverse dependencies for Gradle projects, I created three minimal Java projects:

• Maven project
• Gradle project (Groovy DSL)
• Gradle project (Kotlin DSL)

Each project depends on the same library: com.google.code.gson:gson.

For all repositories:

• Dependency Graph is enabled
• Automatic dependency submission is enabled

Result

When checking the Dependents page for gson, only the Maven project appears.

Implication

This suggests GitHub’s reverse dependency tracking currently works better for Maven than Gradle.

For ecosystems heavily using Gradle, this can lead to undercounting of dependents and incomplete dependency graphs.

[christian-rogobete]

Swift Package Manager

I maintain the Stellar iOS SDK, which is distributed via Swift Package Manager. I ran into two issues with GitHub's dependency graph support for SPM.

---

1. SPM dependencies not detected in SBOM

Problem

GitHub's Dependency Graph API does not detect Swift Package Manager dependencies declared in Package.swift.

For Soneso/stellar-ios-mac-sdk, the SBOM returned by GET /repos/{owner}/{repo}/dependency-graph/sbom picks up Ruby gems from a build tool (tools/xdr-generator/Gemfile) but zero Swift packages, despite Package.swift being present in the repository root.

For comparison, the same API correctly detects:

• pub.dev packages for the Flutter SDK (pinenacl, crypto, http, dio, etc.)
• Composer packages for the PHP SDK (guzzlehttp/guzzle, phpseclib, phpunit, etc.)

Test: does Package.resolved help?

GitHub's supported package ecosystems page lists Package.resolved as the only recognized file for Swift PM, with both "Static transitive dependencies" and "Automatic dependency submission" marked unsupported.

I created two minimal test repos, both depending on stellar-ios-mac-sdk:

• demo-dependents-spm — with Package.resolved checked in
• demo-dependents-spm-no-resolved — without Package.resolved (only Package.swift)

After 48+ hours with both the dependency graph and automatic dependency submission enabled on both repos, the SBOM API returns zero Swift dependencies for both. Package.resolved makes no difference.

$ gh api repos/christian-rogobete/demo-dependents-spm/dependency-graph/sbom \
    --jq '.sbom.packages[].name'
com.github.christian-rogobete/demo-dependents-spm    # only the repo itself

$ gh api repos/christian-rogobete/demo-dependents-spm-no-resolved/dependency-graph/sbom \
    --jq '.sbom.packages[].name'
com.github.christian-rogobete/demo-dependents-spm-no-resolved    # only the repo itself

Unlike Maven, SPM has no support for automatic dependency submission as a fallback either.

---

2. Reverse dependency tracking (Dependents)

Experiment

horizontalsystems/StellarKit.Swift is a wrapper around stellar-ios-mac-sdk used by Unstoppable Wallet (859 stars), a multi-chain mobile wallet. The dependency on our SDK is declared explicitly in its Package.swift:

.package(url: "https://github.com/Soneso/stellar-ios-mac-sdk.git", .upToNextMajor(from: "3.0.8")),

Result

The Dependents page for stellar-ios-mac-sdk shows 0 repositories and 0 packages. Neither StellarKit.Swift, Unstoppable Wallet, nor the two test repos above appear — even after 48+ hours with dependency graph enabled.

The dependency exists, but GitHub doesn't track it in reverse. Even if it did, PG Atlas would still need to resolve transitive dependencies (Unstoppable Wallet -> StellarKit.Swift -> stellar-ios-mac-sdk) to connect the wallet back to the SDK. With SPM tracking not available, an 859-star wallet with real users shows up nowhere in the dependency graph.

[aolieman]

Thank you both for the thorough testing and experimentation!

I've found a couple of official SBOM generators for these ecosystems, which to me look reliable enough to build upon. Asking for your expert opinion, since I do not have any active Gradle or Swift projects myself.

@overcat would you mind reviewing setup-gradle and reporting back how many of your issues it would address when adopted?

@christian-rogobete the same question but for the new SwiftPM feature.

Since that doesn't include an Action that submits the SBOM to GitHub yet, I'm very curious to learn if an unofficial Action is available and worth using. Or, should we consider bypassing the GitHub dependency graph and support SwiftPM directly in the PG Atlas SBOM Action? Or in a separate precursor action that does submit to GitHub like the Gradle one does, so we can keep the main action simple?

Edit: all the "built-in" Automatic dependency submission is just ecosystem-specific Actions under the hood. There's nothing wrong with adding support, or choosing a better Action than the one GitHub likes to run by default.

[overcat]

It's my understanding that the Automatic dependency submission feature relies on the action found here: https://github.com/actions/gradle-build-tools-actions/tree/main/dependency-submission.

I manually added this to my demo-dependents-gradle-kotlin project. While java-stellar-sdk is visible in the demo project's Dependencies, the reverse isn't true—the demo doesn't appear in the Dependents list for java-stellar-sdk. It seems like we might be looking at a GitHub bug.

[christian-rogobete]

Update: Dependency Submission API works for SPM

I found vapor-community/swift-dependency-submission (v0.2.0, February 2026), a GitHub Action that parses Swift dependencies and submits them via the Dependency Submission API.

I tested it with a third repo: demo-dependents-spm-submission. The workflow ran successfully and the SBOM now includes stellar-ios-mac-sdk:

$ gh api repos/christian-rogobete/demo-dependents-spm-submission/dependency-graph/sbom \
    --jq '.sbom.packages[].name'
github.com/Soneso/stellar-ios-mac-sdk
actions/checkout
vapor-community/swift-dependency-submission
vapor/swiftly-action
com.github.christian-rogobete/demo-dependents-spm-submission

For comparison, the two repos without the action still show zero Swift dependencies.

The Dependents page for stellar-ios-mac-sdk still shows 0 repositories, so the Dependency Submission API does not feed into reverse dependency tracking.

Repo	Method	Forward deps (SBOM)	Reverse deps (Dependents)
demo-dependents-spm	Package.resolved checked in	not detected	not detected
demo-dependents-spm-no-resolved	Package.swift only	not detected	not detected
demo-dependents-spm-submission	Dependency Submission API	detected	not detected

Regarding SE-0509 (native SBOM generation in SwiftPM) — the proposal was accepted in February but the latest SwiftPM release is from October 2025. No release with this feature yet.

[aolieman]

Thank you, this Action looks good enough for now. Let's not wait for SE-0509 to be released. I see that swift-dependency-submission will start relying on it anyway: # TODO: When SE-0509 is implemented, replace this with that.

I'd like to assist in providing your iOS SDK dependents with a workflow that combines SBOM generation (with GitHub upload) and submission to PG Atlas. I don't know if the Lobstr app is a private repo on GitHub. The two I do know about, are:

• https://github.com/horizontalsystems/unstoppable-wallet-ios
• https://github.com/Lobstrco/Vault-iOS

How would you like to approach this?

If you want, I could draft the workflow, do some testing (e.g. on GitHub dependency submission latency), and open PRs with the two public repo dependents. The only problem with that plan is that I cannot find the time to do this in the near future.

[aolieman]

Native Git Dependencies

An observation: GitHub's Automatic dependency submission excludes declared dependencies on git URLs. So do all the snapshot generators for the Dependency Submission API (/repos/owner/repo/dependency-graph/snapshots) that I've seen. Their SBOMs do not include any dependencies using e.g. the pkg:github/ PURL namespace; only the root repo is declared as such.

I want to point this out as (yet another) known systematic coverage gap. Found while investigating if an SBOM ingestion fallback could be removed.

The dependencies in question

Many ecosystems and their package managers natively clone, build, and resolve dependencies directly from Git repositories and record exact Git commit hashes in their lockfiles. This is of course done to depend on code that's not published as a package, but I've done it for other reasons, targeting a fork, an unreleased fix commit, or a specific branch.

Ecosystem	Package Managers	Declaration	Lockfile
JavaScript / TypeScript	npm, yarn, pnpm, bun	✓	✓
Python	pip, poetry, uv, pipenv	✓	✓
Rust	cargo	✓	✓
Go	go modules	✓	✓
Ruby	bundler / gem	✓	✓
Swift	Swift Package Manager (SPM)	✓	✓
PHP	composer	✓	✓
Elixir / Erlang	mix / hex	✓	✓
Dart / Flutter	pub	✓	✓
JVM (Java, Kotlin, Scala)	Maven, Gradle, SBT	✕	✕
.NET (C#, F#)	NuGet (dotnet)	✕	✕
C / C++	vcpkg, Conan (Registry-based)	✕	✕
C / C++	CMake (Build system via FetchContent)	✓	✕

These native git dependencies are first-class citizens, and I'd think they should be included in any general-purpose SBOM. The examples I could quickly find that have pkg:github/ dependencies, were all tagged with "Organization: NXP", which does not tell me much about the generator that was used. Tools like Syft and Trivy are capable of outputting native git dependencies, but in the case of Python with a uv.lock they always use the pkg:pypi/ namespace, even for packages that aren't published on PyPI. They probably do the same for other ecosystems.

Dependency Submission API

What about the submission paths that go through the Dependency Submission API? Well, in theory it's possible to submit git dependencies with e.g. the pkg:github/ namespace. I've made the ingestion support for this explicit in the PG Atlas backend. But I don't expect to see this in practice, even with SBOM submissions coming from custom workflows.

Syft and Trivy prefer using the package registry PURLs, even when this is less accurate than the actual declared dependency. That at least preserves some reference, but loses the nuance of dependency on a fork or an unreleased commit — it uses the version kept in the git source. For Python (sorry I have not tested everything), GitHub's Automatic dependency submission simply drops any git dependencies. A custom Action for uv.lock files also ignores any git = sources, and only includes registry = in the output.

I suspect the reason is the security-orientation: the most important use case of GitHub's Dependency Graph is Dependabot, and it is definitely oriented towards published packages. Although it's possible to publish a security advisory for specific commits and commit ranges (without any version tags), I'm not sure how complete the tooling support actually is. I'll leave that demo for another day.

For now, the gap to be aware of: we should expect any declared dependencies on git repos to be missing from the SBOM that PG Atlas ingests.