A customer security questionnaire lands in your inbox on a Tuesday afternoon: "Please provide an SBOM for this repository in SPDX or CycloneDX format." Your engineering lead points you to a button they noticed in GitHub's UI a while back — Insights, then Dependency graph, then "Export SBOM." Two clicks later you have a JSON file. It looks official. It has a timestamp, a repo name, a list of packages. You attach it to the email and move on.
Six weeks later, during a deeper vendor review, the customer's security team asks why the SBOM doesn't list the base image your container runs on, why a known-vulnerable transitive dependency pulled in at build time isn't present, and why there's no vulnerability data attached at all. This is the most common failure mode we see teams run into with GitHub's native SBOM export, and it's worth understanding exactly what the feature does, what it doesn't, and where GitHub Advanced Security fits before you rely on it for a compliance deadline.
What is GitHub's SBOM export feature and when did it launch?
GitHub's SBOM export generates a static SPDX 2.3 JSON document from a repository's dependency graph, and it has been generally available since November 2022. You can trigger it from a repo's Insights → Dependency graph → Export SBOM button, or programmatically via GET /repos/{owner}/{repo}/dependency-graph/sbom. The output conforms to the SPDX specification (not CycloneDX, which some downstream compliance tools expect), listing each detected package name, version, and package URL (purl), along with basic relationship data tying dependencies back to the repository. For a single-manifest project — say, a Python service with one requirements.txt — this takes seconds and produces a clean, spec-valid file. GitHub explicitly built this to answer the "give me an SBOM" ask cheaply, and for that narrow ask it works.
What does GitHub's SBOM actually include, and what does it leave out?
GitHub's SBOM export only includes what the dependency graph itself can parse from manifest and lockfiles, which means anything introduced outside that pipeline is invisible. The dependency graph reads package manifests — package-lock.json, Gemfile.lock, pom.xml, go.sum, and similar files across roughly 15 supported ecosystems — and reports the packages declared there. It does not scan container images, so a Docker build that layers in Alpine packages, OS-level libraries, or a base image with its own hundred-plus package inventory contributes nothing to the exported SBOM. It does not capture build-time dependencies pulled in by a CI script, artifacts fetched from an internal registry, or code vendored directly into the repo without a manifest entry. It also does not include license text, cryptographic hashes of build artifacts, or any indication of whether a package was actually reachable in the compiled binary versus merely declared. For a monorepo with multiple services and multiple manifest files, you also have to export per-repository, not per-service, which means untangling which components actually shipped in which deployable artifact is left entirely to you.
Do you need GitHub Advanced Security to export an SBOM?
No — SBOM export itself is a free feature tied to the dependency graph, available on public repositories and on private repositories with GitHub Advanced Security or Dependabot enabled, but the vulnerability context around it is not free. As of GitHub's 2024 pricing changes, Dependabot alerts are included for public repos and for private repos on paid plans, but Advanced Security features — secret scanning with push protection, code scanning via CodeQL, and dependency review at pull-request time — are billed per active committer (historically around $49/committer/month before GitHub moved to consumption-based Advanced Security pricing in 2024). This matters because the plain SBOM export contains no vulnerability, exploitability, or severity data at all; it is inventory only. To know whether any package in that SPDX file has a known CVE, you need Dependabot alerts running separately, and to catch a vulnerable dependency before merge rather than after, you need GHAS's dependency review, which is where the real cost sits.
How does GitHub's SPDX export compare to a real supply chain SBOM?
GitHub's export is a source-manifest snapshot, while a supply-chain-grade SBOM needs to reflect what was actually built, packaged, and shipped, and those are frequently different lists. Consider a Node.js service with 40 direct dependencies in package.json: the resolved package-lock.json might pull in 600–900 transitive packages, and GitHub's dependency graph does capture that resolved tree reasonably well for JavaScript. But the moment that service is containerized with a node:20-slim base image, you inherit roughly 90–120 Debian packages that never appear in any export, because GitHub's graph stops at the application manifest layer. Industry frameworks like NIST SSDF and the CISA SBOM minimum elements call for build-time provenance and component hashes; GitHub's export includes neither. A generated-at-build SBOM from a container scanning tool, by contrast, inspects the actual filesystem layers of the shipped image and typically surfaces 3–5x more components than the manifest-only export for a typical containerized service.
Can GitHub's SBOM satisfy customer and regulatory compliance requirements?
Partially, and usually only as a starting point, not an end state. Executive Order 14028 and the NTIA's minimum elements for an SBOM (July 2021) call for supplier name, component name, version, dependency relationships, unique identifiers, and a timestamp — GitHub's SPDX export technically checks those boxes at the field level. But procurement teams at regulated customers — banks, healthcare vendors, federal contractors — increasingly ask follow-up questions the export can't answer: Was this SBOM generated from the artifact that actually shipped, or from source at some arbitrary point in time? Does it cover container base layers? Is there a VEX (Vulnerability Exploitability eXchange) statement attached so we know which listed CVEs are actually exploitable in this context? A November 2022 manifest-based export answers none of these, which is why teams that hand over a bare GitHub SBOM to a Fortune 500 security review often get bounced back with a request for "a complete SBOM including runtime and container components" — the exact gap that turns a two-click export into a multi-week scramble.
How Safeguard Helps
Safeguard closes the gap between "we exported a file" and "we can prove our software supply chain." Rather than reading only the top-level manifest GitHub's dependency graph sees, Safeguard generates SBOMs from the actual built artifacts — container images, compiled binaries, and deployment packages — so the base OS packages, transitive build dependencies, and vendored code that GitHub's export misses are captured in the same document. Every component comes attached to live vulnerability and exploitability data rather than a separate Dependabot feed you have to reconcile by hand, and Safeguard emits both SPDX and CycloneDX so you're not stuck reformatting for whichever standard a given customer's intake tool expects. For teams that already rely on GitHub's dependency graph and GHAS for day-to-day development, Safeguard doesn't replace that workflow — it sits alongside it, ingesting GitHub's data where it's useful and filling in build-time and container-layer visibility where it isn't, so the SBOM you hand to a customer or auditor reflects what actually shipped, not just what was declared in a manifest six weeks before the release.