The GitHub dependency graph summarizes the dependencies a repository declares, built by parsing manifest and lock files. Its blind spots follow from that: anything not declared in a supported file, and any ecosystem it does not support, will not appear. Dependabot alerts inherit those blind spots.
What it is
For each dependency the graph shows the version, license, the manifest file that included it, and whether it has known vulnerabilities, with vulnerable packages sorted first. It is available on all GitHub plans, and the same data feeds SBOM export as an SPDX document.
How it is built
GitHub automatically parses the manifest and lock files stored in a repository. You can also submit dependency data yourself through the dependency submission API, which is how builds with resolved dependencies can report what they really contain. The supported ecosystems and manifest types are listed on a separate reference page, so check it for your stack.
Where gaps appear
| Case | Effect |
|---|---|
| Ecosystem not supported | Dependencies do not appear |
| No lock file committed | Resolved versions may be unknown |
| Transitive dependencies | Shown only for ecosystems that support them |
| Vendored or copied code | Not a declared dependency, so not tracked |
| Dependents of private repos | Not reported |
The documentation also says that the Used by section appears only under specific conditions, including that the package is published to a supported ecosystem and has more than 100 dependent repositories. That is about who uses your package, not what you use.
Why it matters for alerts
Dependabot builds its picture from this graph, and the alerts documentation says plainly that alerts cannot catch every security issue. Manifests and lock files must stay current for accurate detection. If a package is missing from the graph, no alert can fire for it.
How to check your own graph
- Open a service, list what you know it uses, and compare with the graph.
- Look for anything shipped but absent: vendored libraries, container base images, build tools.
- Use Show paths on a transitive dependency to see what brought it in.
- Commit lock files for every application.
- If the build resolves things the files do not show, use the submission API.
What to add
Container images and operating system packages are outside a repository graph. Languages or tools outside the supported list need another source of truth, such as an SBOM generated from the built artifact.
Where a dedicated scanner fits
A scanner that builds an inventory from the project and the built output can cross check the graph. Safeguard offers SBOM and dependency scanning with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Find a package several levels deep and note which direct dependency pulled it in.
Quick check
Does the dependency graph include private repository dependents?
No. Dependents are not reported for private repositories.
Why does a missing lock file matter?
The graph is built from manifest and lock files, so without a lock file the exact resolved versions may not be recorded.
Sources
- GitHub Docs: About the dependency graph
- GitHub Docs: About Dependabot alerts
- GitHub Docs: GitHub security features
Last reviewed: 19 October 2026.
