An engineering lead wants to automate exporting an SBOM for a repository on every release so the artefact can be attached to the published build. They prefer to call GitHub directly rather than parse the web interface. Which approach lets them retrieve the repository's SBOM programmatically in the same SPDX format the dependency graph produces?
- AClone the repository and run the SPDX command-line tool against the working tree, because GitHub does not expose the SBOM through any API and only renders it in the browser.
- BEnable Dependabot version updates, since the resulting pull requests include the SPDX SBOM as an attachment that the workflow can extract on each release.
- CCall the GraphQL dependency submission mutation, which both uploads build-time dependencies and returns the assembled SPDX SBOM in its response payload.
- DQuery the dependency graph SBOM REST API endpoint for the repository, which returns the SBOM as an SPDX JSON document that the release workflow can save as an artefact. Correct
Why A is wrong: GitHub does expose the SBOM through a REST API, so claiming the only path is a local SPDX tool is incorrect. A locally generated document would also not reflect the dependency graph that GitHub has detected on the server.
Why B is wrong: Dependabot version updates raise pull requests to bump dependency versions and do not attach an SBOM to those pull requests. This conflates an update mechanism with the SBOM export and provides no programmatic SBOM retrieval.
Why C is wrong: The dependency submission interface is for pushing build-time dependency data into the graph, not for returning an SBOM export. It is the wrong direction of data flow, so it does not retrieve the SPDX document the lead wants.
Why D is correct: GitHub exposes a REST API endpoint that returns the repository's dependency graph SBOM as an SPDX JSON document. A release workflow can call this endpoint and persist the response, giving the same standardised export available in the user interface but driven by automation.