Generate the SBOM during your release build, name it after the version, attach it as a release asset, then publish. Use a draft release first so every asset is in place, because repositories with immutable releases will not let you change assets after publishing. GitHub's own export is a separate, repository level inventory.
Steps
- Generate the SBOM in the same job that builds the artifacts, from the same commit.
- Name it clearly, for example myapp-1.5.0.spdx.json or myapp-1.5.0.cdx.json. The extension tells readers the format.
- Create the release as a draft.
- Attach the binaries, the SBOM and any signature or checksum files.
- Check the assets, then publish.
gh release create v1.5.0 --draft dist/myapp dist/myapp-1.5.0.cdx.json
- Link to the SBOM from your release notes.
Why the draft step matters
GitHub documents immutable releases. If your repository has them enabled, assets cannot be changed once a release is published. It recommends creating a draft, attaching everything, then publishing. If you forget the SBOM, you will need a new release version. Title, notes and the pre release or latest flags can still be edited.
Two different SBOMs
| Source | What it describes | Format | Good for |
|---|---|---|---|
| Your release asset | The built artifact for that version | Your choice | Customers and auditors of that release |
| GitHub dependency graph export | The repository's dependencies | SPDX | A quick inventory, or a starting point |
The export, found under Insights, then Dependency graph, then Export SBOM, or through the REST API, inventories your dependencies with versions, identifiers, licenses and transitive paths. It does not include dependents. The API is a two step flow: request generation, then poll until the response changes from 202 to a redirect and download.
The repository export reflects the repo as it stands. It does not know what your build step pulled in, so a release asset generated from the build is a better record of what shipped.
Keep it honest
- Generate after the final build, not before.
- Add a checksum of the SBOM next to the artifact checksums.
- Do not edit an SBOM by hand after generation. If it is wrong, fix the generator.
If your project publishes packages as well as release assets, also publish the SBOM next to the package where your registry supports it, so consumers find it in one place. Keep the release asset as the record, and treat any copy as a convenience. When a customer asks for the SBOM of a past version, you want to point to one fixed file, not regenerate it from memory.
Quick check
Can I replace an SBOM on a published release?
Only if the repository does not use immutable releases. Do not count on it. Use a draft.
Is the GitHub export enough for customers?
It is a useful inventory, but an SBOM generated from your build better reflects what you shipped.
Safeguard's SBOM and dependency scanning ingests SBOMs from your releases, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
