[DPE-2137] Add SBOM generation

[dragomirp]

Issue

Need to generate SBOM manifest for future security auditing

Solution

Add a workflow to generate the manifest

[dragomirp]

An example of the expected end result can be seen here. There's a charmed-mysql_8.0.33-22.04_edge_amd64.rock.spdx.json artefact in the summary.

[carlcsaposs-canonical]

https://chat.canonical.com/canonical/pl/r69c46rs1fbuuji3eus1ciafae

[paulomach]

great. Should this be on data-platform-workflows though?

[shayancanonical]

lgtm! i defer to alex on security concers

[taurus-forever]

@dragomirp after some internal discussions, please replace here "main" with "v0.85.0", it should be safe enough to merge it AS IS, until we have a final SBOM Canonical vision. Tnx!

Suggested change

	curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
	curl -sSfL https://raw.githubusercontent.com/anchore/syft/v0.85.0/install.sh | sh -s -- -b /usr/local/bin

[carlcsaposs-canonical]

@taurus-forever That doesn't address security concerns—the tag can be moved. Suggest pinning to a commit hash instead

[dragomirp]

@carlcsaposs-canonical I intend to move this to check the image from the registry, so it wouldn't matter if the artefact is potentially changed, but I can't promise it would be this pulse.

[carlcsaposs-canonical]

My point is that main and v0.85.0 are essentially the same from a security perspective—in the short term, I think we should either stay with main or move to a commit hash

[dragomirp]

Yes. Running syft at the end against the registry instead of the artefact would address this, since at that point the artefact is already published.

[carlcsaposs-canonical]

but I can't promise it would be this pulse

For the commit hash, I'm only referring to short-term (i.e. this PR)