The GitHub dependency graph lists what it can parse from supported manifest and lock files. It can miss dependencies that are resolved at build time, declared in files it does not parse well, or kept outside the repository. Check those gaps before you hand an exported SBOM to an investor or buyer.
What the graph is
GitHub describes the dependency graph as a summary of the manifest and lock files in a repository, and it can show each dependency with its version, license information and the manifest that included it. For ecosystems with transitive dependencies, you can view the path that brought a package in. GitHub can export the current state of that graph as an SPDX SBOM.
That is a useful starting point. It is not the same as a complete inventory of what you ship.
Four common gaps
Build-time resolution. Some projects resolve dependencies just when they are built. GitHub offers a dependency submission API for dependencies that static analysis does not capture, such as those resolved during a build. If your project works this way and you have not submitted anything, the graph may be thin.
Loosely declared Python dependencies. GitHub's documentation notes that if you list Python dependencies inside a setup.py file, it may not be able to parse and list every dependency. A requirements file or a lock file is more reliable.
Containers and operating system packages. A manifest in the repository says nothing about the packages inside your base image. A container scan covers that part.
Other repositories. Shared libraries, infrastructure code and mobile apps often sit in separate repositories. An export from one repository describes one repository.
A quick audit
- Pick one product and list every place its code lives.
- For each repository, open the dependency graph and count manifests.
- Compare to the build: does the production image or package contain things not listed?
- Check lock files are committed for every application.
- Where the graph is thin, use the submission API or generate an SBOM in the build instead.
If you can do one thing, compare the SBOM against the artifact you actually deploy. Whatever differs is a blind spot.
How to describe the limits
A data room note can say plainly: "This SBOM was exported from the repository dependency graph on 19 October 2026. It covers manifests in repositories A and B. It does not cover base image packages, which are in the attached container SBOM." That is honest, and buyers tend to trust a stated boundary more than a claim of completeness.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how direct and transitive packages are listed together, and how an inventory is organised by project.
Safeguard offers SBOM generation and dependency scanning across repositories and containers, with asset discovery to find repositories nobody listed. A free scan shows what one repository looks like.
Quick check
Is the dependency graph export a valid SBOM?
GitHub exports it in the SPDX format. Whether it is enough depends on what the reader needs, which is why stating its coverage matters.
Do lock files matter for this?
Yes. A lock file records the resolved versions, which makes the inventory more precise than a manifest with version ranges.
Sources
- GitHub Docs, About the dependency graph
- GitHub Docs, Dependency graph supported package ecosystems
- GitHub Docs, Using the dependency submission API
- GitHub Docs, Exporting a software bill of materials for your repository
Last reviewed: 19 October 2026.
