Support automatically uploading SBOMs

[yoshuawuyts]

bytecodealliance/wasm-tools#2082 has added support for extracting SBOM data encoded in custom sections in Wasm binaries (.dep-v0). When uploading components to OCI registries, it would be neat if we could automatically look for the presence of this metadata and upload it to the registry as an attachment if present.

I'm not too picky on what the format of the attachment should be, we might even want to enable users to configure it. But I propose that at least initially we encode this as the CycloneDX format, since the cargo-auditable project already provides a crate to do that.

The end-to-end flow I'm envisioning here is to have tools such as cargo-component and jco encode dependency info by default as part of their build. Enable tools such as wasm-metadata to read this metadata and display it to users. And have tools such as wkg handle this metadata during packaging, convert it to the right formats for ingestion, and upload it to the registry.

I hope this makes sense, thanks!

cc/ @Shnatsel and @pchickey for awareness

[Shnatsel]

FWIW https://github.com/aquasecurity/trivy already supports scanning containers, and can export to both CycloneDX and SPDX. https://github.com/google/osv-scalibr is another off-the-shelf tool that can do the same.

Both of those are written in Go. There is no turn-key option in Rust that can scan an OCI container as far as I'm aware, but you could probably combine fd-find with auditable2cdx to get the job done. I haven't tested auditable2cdx for interoperability with other tools all that much, and CycloneDX is a rather loosely defined format, so I'm not sure how widely compatible that would be.

[Shnatsel]

Oh, if you're uploading a single WASM file to an OCI registry as opposed to an entire container, the task is far simpler and any of the tools listed above will do. Although the caveat about auditable2cdx not being widely tested for interop still applies.

[thomastaylor312]

Huge fan of this

[yoshuawuyts]

Oh, if you're uploading a single WASM file to an OCI registry as opposed to an entire container, the task is far simpler and any of the tools listed above will do. Although the caveat about auditable2cdx not being widely tested for interop still applies.

@Shnatsel hah yeah, that was exactly what I was thinking here. The Wasm OCI layout spec describes how to upload .wasm files as to OCI registries, and the tools in this repo exist to implement that. This is also what makes cargo-auditable's approach so appealing for us: it provides a way for language-aware compiler tooling to get the dependency data from the various language ecosystems. Which they can then encode using a fixed format in a known location, which can then be post-processed using language-agnostic tooling from that point onwards. If we do it right, components should become fully self-describing in a way that containers will struggle to.

The only hiccup I've found is that as I was filing bytecodealliance/sample-wasi-http-rust#54 I realized that if we want to also sign the SBOM after publishing, the cosign tool expects to be the one uploading it. Skimming through their issue tracker surfaced something about doing it that way to prevent TOCTOU attacks. Though perhaps there is a way to sign SBOMS after they've been published that I haven't found yet.