Support SBOM as a submission format

[davidkarlsen]

See discussion in https://github.com/orgs/github-community/discussions/18918 - it would be great if the toolkit could support SBOM standards out of the box, as this would enable a bridge from existing tooling into the github dependency submission api.
By leveraging existing standards you have a short way from existing standards into the new github features.

[lseppala]

Definitely agree with the usefulness of the toolkit supporting conversion from an SBOM file to a submission to the API. (We originally considered using one of the SBOM standard formats, but for a handful of reasons, chose instead to provide our own, more minimal format.)

Adding this functionality to the toolkit isn't our near-term roadmap, but would welcome any contributions. We would gladly help support PRs to add functionality to this repo, or we may be able to help promote projects that use the toolkit to develop an Action that converts SBOM files and submit.

Leaving this issue open until this is addressed. Thanks for raising!

[davidkarlsen]

We have a "bridge" in https://github.com/evryfs/sbom-dependency-submission-action - it will take an sbom and post it to gh using your SDK.
Currently in development by @kjetiloen but we expect to release a minimal 1st version this week.

[captn3m0]

Just started working on this, but the code here looks pretty much what I was writing, so will just use that instead. Thanks @davidkarlsen 💯!

[davidkarlsen]

@captn3m0 You can try v0.0.1 now - it's released to the marketplace: https://github.com/marketplace/actions/sbom-submission-action

[davidkarlsen]

Adding this functionality to the toolkit isn't our near-term roadmap, but would welcome any contributions. We would gladly help support PRs to add functionality to this repo, or we may be able to help promote projects that use the toolkit to develop an Action that converts SBOM files and submit.

Maybe we can collab on https://github.com/evryfs/sbom-dependency-submission-action - we just recently released it.
But we see one snag, when submitting several sbom's only one of them show up in the dependencies pane:

vs submission: https://github.com/evryfs/sbom-dependency-submission-action/actions/runs/2590287090

[lseppala]

But we see one snag, when submitting several sbom's only one of them show up in the dependencies pane

@davidkarlsen I'll take a look. A common issue is that the job.correlator and job.name must be unique when multiple snapshots are submitted. I'd check to see if this is the case first. From the API documentation page under the job object

Correlator provides a key that is used to group snapshots submitted over time. Only the "latest" submitted snapshot for a given combination of job.correlator and detector.name will be considered when calculating a repository's current dependencies. Correlator should be as unique as it takes to distinguish all detection runs for a given "wave" of CI workflow you run. If you're using GitHub Actions, a good default value for this could be the environment variables GITHUB_WORKFLOW and GITHUB_JOB concatenated together. If you're using a build matrix, then you'll also need to add additional key(s) to distinguish between each submission inside a matrix variation.

[davidkarlsen]

But we see one snag, when submitting several sbom's only one of them show up in the dependencies pane

@davidkarlsen I'll take a look. A common issue is that the job.correlator and job.name must be unique when multiple snapshots are submitted. I'd check to see if this is the case first. From the API documentation page under the job object

Correlator provides a key that is used to group snapshots submitted over time. Only the "latest" submitted snapshot for a given combination of job.correlator and detector.name will be considered when calculating a repository's current dependencies. Correlator should be as unique as it takes to distinguish all detection runs for a given "wave" of CI workflow you run. If you're using GitHub Actions, a good default value for this could be the environment variables GITHUB_WORKFLOW and GITHUB_JOB concatenated together. If you're using a build matrix, then you'll also need to add additional key(s) to distinguish between each submission inside a matrix variation.

As you see from the job logs the filename is part of the correlator and thus unique

[stevespringett]

@davidkarlsen Thanks for the submission and work on the sbom-submission-action. It's been added to the CycloneDX Tool Center.