You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cargo-auditable tool makes it possible to embed SBOM (dependency) data inside binary custom sections, including Wasm Components. The way this works is that they create a custom section called .dep-v0, and encode package information in there as gzipped JSON.
While this section is not "standard" in a formal sense, it is being used in the wild and is supported by other SBOM tools such as Syft as well. I believe it would be good if we could teach wasm-metadata about possible SBOM embeddings, and allow it to surface that data.
I think in terms of the data model, we should try and associate each dependency with its respective module or component. That way we can show dependency info alongside the producer data. For this to be practical and not result in an overwhelming of output I think something like #1923 would probably be helpful to implement first.
The cargo-auditable tool makes it possible to embed SBOM (dependency) data inside binary custom sections, including Wasm Components. The way this works is that they create a custom section called
.dep-v0
, and encode package information in there as gzipped JSON.While this section is not "standard" in a formal sense, it is being used in the wild and is supported by other SBOM tools such as Syft as well. I believe it would be good if we could teach
wasm-metadata
about possible SBOM embeddings, and allow it to surface that data.I think in terms of the data model, we should try and associate each dependency with its respective module or component. That way we can show dependency info alongside the producer data. For this to be practical and not result in an overwhelming of output I think something like #1923 would probably be helpful to implement first.
cc/ @Shnatsel
The text was updated successfully, but these errors were encountered: