Why use this over SBOM?

[MPV]

Anyone who's delved into/compared using this action versus uploading an SBOM to the dependency submission API?

I'm referring to things like these:

• https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api#generating-and-submitting-a-software-bill-of-materials-sbom
• https://github.com/marketplace/actions/spdx-dependency-submission-action

[adpi2]

This Github action submits the snapshot of all the dependencies downloaded by the build: the compile dependencies, the test dependencies, the scala tools (compiler and scaladoc), and their transitive dependencies, for all Scala versions and platforms. It's configurable, if you want to exclude some configuration or project.

I never used any sbt BOM generation plugin and I don't know how to configure such plugin to extract all the dependencies, including the transitive ones.

[raboof]

Anyone who's delved into/compared using this action versus uploading an SBOM to the dependency submission API?

To be able to upload an SBOM, you'll first have to create it. The most promising project for that appears to be sbt-sbom, which we recently brought under the sbt organization and are working on at https://github.com/sbt/sbt-sbom . I think GitHub requires SPDX rather than CycloneDX, that's not supported yet (sbt/sbt-sbom#89), and it might be less flexible than sbt-dependency-submission in the selection of configurations.

Of course if you squint there's some overlap between sbt-sbom and sbt-dependency-submission - I could see them converge in the future, but for now it seems to make sense to have them evolve independently.