Open NissesSenap opened 4 months ago
I had a play with a couple of SBOM generators for Rust - the one I had best luck with was spdx-sbom-generator
, which understands several tools including Cargo (which is what I was using). It is "under construction" but produced a plausible looking SPDX document anyway! I am a bit puzzled, though, that they don't seem to tie the SBOM in any way to the generated binary - there's no build happening alongside SBOM creation - but maybe that's expected?
Anyway, it seems like generating the component SBOM would be out of scope for Spin itself, but could be done using an additional command during spin build
. And Spin could presumably aggregate the component SBOMs into an application SBOM handwave handwave, and presumably could then publish that aggregate (OCI image) SBOM. But I'm not sure that this provides any meaningful guarantees that the binary in the image relates to the packages listed in the SBOM.
Adding to @itowlson's comment here — you can already use cosign
to sign and verify Spin applications — https://developer.fermyon.com/spin/v2/distributing-apps#signing-spin-applications-and-verifying-signatures
Hi, thanks for your reply.
@radu-matei the link that you posted is documenting how to sign a container image generated by spin, which is great. But it doesn't generate a SBOM, you are "just" signing your container, thus making it possible to trust the generated image is coming from a legit source.
@itowlson I can see your point that this is the edge of what spin should do. And I understand if the community decides to close this issue.
But my general understanding of the spin project, is that it is trying to make it as easy as possible to get started with WASM, but also solve day 2-3 stuff.
And generating a SBOM as part of the WASM binary generation is for me a big part of day 3 tasks. So I think adding it to spin build
would be a great addition. But this might be better suited in some other part of the WASM related project (as I said, new to the WASM community).
As you point out, you need to also do signing of the SBOM to enable some kind of trust of the generated artifact. And that could be done by using cosign
, just as currently documented for the container image.
As I tried to point out in the issue description, is that one of Kubernetes biggest design flaws is that it's insecure by default, and the community is working hard of integrating different security feature without making breaking changes, that is very hard and in some places impossible. So from my point of view, the more security related stuff that can be done by default, the better for the WASM/spin community in the long run.
@NissesSenap to be clear, I'm not saying we should rule this out of scope and close the issue. I'm just trying to get my head around what roles Spin usefully play, because (from what I understand) SBOM generation has to start at the language level, and Spin has to defer everything at the language level to language toolchains. (spin build
is completely language oblivious, it just blindly invokes whatever command it finds in spin.toml
.)
What it's possible Spin could do is:
spin.toml
) as part of spin build
Hope that clarifies the response.
Hi @itowlson , what you are saying makes a lot of sense. I didn't really think through how the wasi binary was generated. My initial thinking was just
spin is where I now generate my binary, so I would like to generate my SBOM at the same place.
I do see a value with the items you suggested being added in spin.toml
and I think it could be useful in the future.
Thank you for your clarification and your quick responses.
Background
There is a general push for SBOMs in the software community, especially after the executive order back in 2021.
I have very limited knowledge about the WASM community, so I have no idea how hard this would be. But the Kubernetes community is working hard on making tooling around good security defaults better all the time.
If spin could make it easy to generate SBOM for both the generated WASM and the container, I know that will help the WASM community in the long run.
Solution
Preferably, it should be possible to generate SBOMs according to the two existing standards.
This could be a separate issue, but it would also be nice if to use sigstore to sign of the WASM binary, container image and the SBOM could be done easily through spin. This is, for example, something that ko is doing by default.