How do you export an SBOM for a GitHub repository, and where does its content come from?

## What GitHub gives you A repository on GitHub can produce an SBOM on demand in SPDX JSON. Two routes, same content: - **UI** — the repository's dependency graph view has an **Export SBOM** control that downloads the document. - **REST** — `GET /repos/{owner}/{repo}/dependency-graph/sbom`, which returns a JSON object with an `sbom` property holding the SPDX document. `gh api` makes this a one-liner and is what you use to sweep many repositories. SPDX is one of the two widely used SBOM document formats; GitHub's export uses it in JSON serialisation. ## What is inside The document names the repository as its subject and lists packages. Each package carries at least a name and a version (`versionInfo`), usually a package-URL external reference identifying it precisely in its ecosystem, and licence fields where GitHub has that information. That structure is what makes it machine-consumable — a downstream tool can match a package URL against an advisory's affected range without guessing at name formats. ## Where the content comes from — the part that matters GitHub does not build your project to produce this. The export is a rendering of the **dependency graph**, which GitHub derives by parsing supported manifest and lock files on the default branch: `package-lock.json`, `go.sum`, `Cargo.lock`, `pom.xml`, `requirements.txt` and their peers. Everything the graph knows, the SBOM contains; everything the graph misses, the SBOM misses too. That has practical consequences a junior candidate is expected to at least gesture at: - **It describes the default branch, not a release.** Export today and you get today's default branch, not the tree that produced last month's tagged artifact. - **It describes declared dependencies, not a built artifact.** Files baked into a container image by other means — a base image's system packages, something fetched by a build script — are not in it. - **Transitive accuracy depends on lock files.** Where a lock file pins the resolved set, the graph is precise. Where only a manifest with ranges exists, it is necessarily less so. - **It must be enabled.** The dependency graph is on by default for public repositories; on private ones it is a setting someone has to switch on, and until then the export has nothing to render. ## When this is the right tool The export shines for *inventory* questions: which of our repositories declare this library, and at what version. Because it is an API call, it scales across an organisation in a shell loop — no builds, no agents, no per-repository setup beyond having the graph enabled. It is the wrong tool when the question is about a specific shipped artifact — "what is inside the image running in production?" There the SBOM you want is generated during the build, from the build's own resolved dependency set, and attached to the artifact. GitHub's repository export cannot answer that, because it never saw the build. ## How it relates to the other GitHub surfaces The same dependency graph feeds vulnerability alerting on the repository and the dependency review of a pull request. So the SBOM export is best understood as "the graph, serialised for someone outside GitHub" — most often a customer's procurement or compliance team who wants a file rather than access to your repository. That is the request that most often triggers this in practice, and it is why the honest caveat matters: hand over a document, and be able to say precisely what it does and does not cover.