A dependency graph goes blind wherever the dependency is not declared in a file the tool understands: vendored copies, unsupported ecosystems, packages fetched at build or run time, binaries and the operating system layer. Cover those gaps with artifact scanning and a short manual inventory.
What the graph sees
GitHub's documentation says its dependency graph is built from the manifest and lock files stored in a repository, plus any data submitted through the dependency submission API. It shows each dependency's version, license, the manifest that included it and known vulnerabilities, and for ecosystems that support transitive dependencies it can show the path that brought one in. It also states that coverage depends on supported ecosystems and file types.
That is a sensible design, and it defines the edges of what you can learn from it.
Six blind spots
- Vendored code. A library copied into a folder has no manifest entry. Ask the team for a list of vendored directories.
- Unsupported ecosystems. Package managers outside the supported list do not appear. Ask which languages and build tools the product uses and compare them with the tool's list.
- Dynamic fetching. Scripts that download a tool or dataset during build, or a plugin loaded at start, bypass the manifest.
- Binaries and firmware blobs. Compiled components carry no manifest.
- Base images and OS packages. Container layers include packages that no app manifest mentions.
- Front end tags. Scripts loaded from a third party domain at page load are not in any package file.
How to cover each gap
| Blind spot | How to cover it |
|---|---|
| Vendored code | Inventory directories, record origin and version in a file |
| Unsupported ecosystem | Submit dependency data through an API or use another scanner |
| Dynamic fetching | Pin and hash downloads, list them in the build script |
| Binaries | Binary analysis or supplier statements |
| Base images | Scan the built image |
| Front end tags | Tag inventory and content security rules |
What to ask a team
- Does your SBOM come from manifests, or from the built artifact?
- Where does your build download things that are not in a lockfile?
- How do you track code copied into the repository?
- Who checks that the graph is switched on for every repository?
The last one matters. The documentation notes that administrators can enable or disable the graph, so a repository without it shows nothing and may be assumed clean.
Try it yourself
Open the demo and compare the inventory it produces with what a manifest alone would show. Notice the packages that appear only once the full set is analysed.
Click through it at your own pace, or open it full screen.
Safeguard scans containers and projects and generates SBOMs, so a free scan shows how an artifact based view compares with a manifest view.
Quick check
Is the dependency graph an SBOM?
It is a source of data for one. An SBOM also needs the baseline fields, an author and a timestamp.
Does enabling it on every repository fix the gaps?
No. It removes the unscanned repositories, not the blind spots listed above.
Sources
Last reviewed: 19 October 2026.
