How do you export an SPDX SBOM from GitHub for a data room?

In a GitHub repository, open Insights, then Dependency graph, and use the export option to download an SPDX SBOM. You can also generate one in a workflow. Before it goes into a data room, add a date, a release reference and a one line note on what the file covers.

What the export contains

GitHub says the exported SBOM uses the SPDX format and includes an inventory of the project's dependencies with associated information such as versions, package identifiers, licenses, transitive paths and copyright information. It does not include dependents, meaning other projects that rely on yours.

So it describes what you depend on, not who depends on you. That is the right direction for diligence.

Steps from the interface

1. Go to the main page of the repository.
2. Click Insights.
3. In the left sidebar, click Dependency graph.
4. Use the export SBOM option on the dependency graph page.
5. Save the downloaded file.

If the page shows no dependencies, check that manifests are committed.

Steps from a workflow

GitHub's documentation lists actions that generate SPDX or CycloneDX SBOMs in a workflow and attach them as artifacts. Generating in the build ties the file to a specific commit, which is stronger evidence than a manual export done on a Friday afternoon.

1. Add a workflow step that runs on release or tag.
2. Name the output with the product and version, for example shop-api-5.2.0.spdx.json.
3. Upload it as a release asset or store it somewhere with longer retention than workflow artifacts.

Workflow artifacts are kept for a limited retention period, so copy what you need into a store you control.

Prepare the file for others

• Record the date and commit SHA in your own index, since the file name alone will not say.
• Open the file and spot check five packages against the lock file.
• Check the license fields. Missing entries are normal, but know how many there are.
• Decide who gets it: a data room folder with access logging, not an email attachment.

What the export will not tell the reader

It does not say which vulnerabilities apply, whether code is reachable, or who approved the dependencies. Pair it with a findings summary and any exploitability statements. Also state its boundary: one repository, no container packages, no other repos.

Common mistakes

Exporting from a branch nobody deploys. Exporting before lock files were committed. Sending one SBOM for ten repositories. Forgetting that the graph is a snapshot, so a file from September is stale in November.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at which fields appear for each package, then compare to your own export.

Safeguard generates SBOMs and scans dependencies across ecosystems and containers, so the file can come from the same pipeline as your findings. Try a free scan to see sample output.

Quick check

Sources

• GitHub Docs, Exporting a software bill of materials for your repository

Last reviewed: 19 October 2026.