Skip to main content
← Back

WebAssembly News: Merging the wash CLI and SBOM Build Provenance

The March 5, 2025 wasmCloud community call is a short, heads-down WebAssembly news update from a team in KubeCon EU crunch mode. Brooks Townsend walks through the in-progress effort — led by maintainer Ahmed — to merge the wash CLI and wash-lib crates into a single wash crate so features ship faster, and explains why the team is holding a feature freeze until the PR lands. Masoud, a wasmCloud OSS Fellow, shares phase-one progress on SBOM and build-provenance work for wasmCloud artifacts, which sparks a discussion with Taylor Thomas about keeping component builds compliant with the OCI artifact standard.

Key Takeaways​

  • The wash CLI (wash-cli) and wash-lib crates are being consolidated into one wash crate, so new features and functionality can be released under a single crate much more quickly
  • The team is maintaining a feature freeze on both crates until the merge PR lands, and will cut one last wash-lib / wash-cli release just before it does
  • The change is invisible to most users — wash stays a single binary installed the same way — except that Cargo users will run cargo install wash instead of cargo install wash-cli
  • Masoud's SBOM and build-provenance work targets SLSA Build Level 2; Level 3 would require isolating the build and attestation into reusable workflows, which the current pipeline can't yet do cleanly
  • The team plans to evaluate the provenance approach asynchronously in Slack and pick it back up after KubeCon EU, since it isn't on the critical path for any feature
  • Masoud flagged a possible regression where some component images appeared to use an older custom config format; Taylor confirmed wasmCloud's tooling uses the standard OCI artifact config media type from the CNCF/OCI working group
  • The built-in HTTP client provider will sit behind the same kind of experimental flag as the built-in HTTP server provider, while the team teases out the right use cases for built-in providers

Chapters​

Meeting Notes​

Combining the wash CLI and wash-lib Crates​

Brooks opened with a quick touch-base — no big agenda items, with much of the team on-site, "heads down, looking forward toward KubeCon EU." The main item was an effort maintainer Ahmed has driven over the past few weeks: merging wash-lib and wash-cli, two separate crates in wasmCloud's Rust codebase, into a single wash crate. Combining them lets the team release wash features and functionality much faster, under one crate instead of two.

Getting there meant some cleanup. Ahmed had to rebase to bring over fixes from the repository's main branch, including swapping out a library with an incompatible license and resolving a couple of issues with an integration test for the HTTP client. To keep the merge clean, the team is holding a deliberate feature freeze — nothing new gets merged into wash-lib or wash-cli until the consolidation PR is across the line. This work is part of the Q1 roadmap, and Brooks noted it's moving along well (the customary CI flake notwithstanding).

What the Merge Means for Installing wash​

The plan: right before the PR lands, cut one last release of wash-lib and wash-cli; after it lands, there's a single wash crate under wasmCloud. For the vast majority of users this changes nothing — wash is still a single binary, still installed through the same package managers, which the team will update behind the scenes. The one visible difference is for people installing via Cargo, who will run cargo install wash instead of cargo install wash-cli. Small baby steps, but a good thing to get done.

Masoud's Update: SBOMs and Build Provenance​

Masoud, a wasmCloud OSS Fellow, reported on phase one of SBOM (software bill of materials) and build-provenance work for wasmCloud artifacts. After learning in January that an earlier assumption was wrong, he revised the approach and documented the full background in the issue. The crux: SLSA Build Level 3 requires isolating the build and the attestation — not just producing attestations — into reusable workflows, which wasmCloud's current pipeline can't do cleanly yet. So Masoud designed a solution suitable for Level 2 and stood up a repository to run wasmCloud component jobs and provider jobs with the necessary modifications. The trade-off he called out: the build pipeline is already complex, and the Level 2 approach adds more injection points, making it more complex still.

Reviewing the Work Async, and an OCI Artifact Question​

Because the provenance work isn't on the critical path for any feature, Brooks proposed reviewing Masoud's comment asynchronously in the wasmCloud Slack and making it the first discussion item in the following week's call — giving the team time to digest before deciding whether to proceed now or after the pipeline is simplified. Masoud agreed to post it there.

Masoud also flagged what looked like a regression: some of the latest component images appeared to be built in an older custom config format ("actor"-style), predating wasmCloud's adoption of the OCI standard. Brooks confirmed the team should be following the Wasm OCI Artifact recommendations from the working group. Taylor Thomas clarified that wasmCloud's current tooling uses the standard OCI config media type — the core of the spec produced with the CNCF and OCI folks — and that the word "actor" no longer appears in the codebase outside historical comments. Some old artifacts may still be drifting around with the legacy config type; Taylor asked Masoud to send a concrete example so they could track down what (or who) pushed it.

Open Floor: Built-in HTTP Client Behind an Experimental Flag​

With the agenda wrapped, Masoud asked whether the in-progress built-in HTTP client provider should sit behind the same kind of experimental flag recently added for built-in providers. Brooks confirmed yes — mirroring the built-in HTTP server provider's setup. wasmCloud wants to keep built-in providers behind an experimental flag while it teases out the right use cases, since built-ins behave differently from the project's discrete binary capability providers.

WebAssembly News and Updates​

This was a tooling-and-supply-chain edition of wasmCloud's weekly WebAssembly news. The headline items — consolidating the wash CLI into a single crate and pushing SBOM and build-provenance work toward SLSA compliance — are the unglamorous plumbing that makes a CNCF WebAssembly platform trustworthy in production. The OCI discussion is a reminder that wasmCloud distributes WebAssembly components and providers as standard OCI artifacts, the same registries that carry container images. For the broader ecosystem, the team teased ongoing progress toward WASI Preview 3 and was visibly in KubeCon EU prep mode. For ongoing updates, follow the wasmCloud blog and the Bytecode Alliance.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and the wash CLI is the developer's main entry point for building, signing, and publishing components as OCI artifacts. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: Supply-Chain Trust for WebAssembly Artifacts​

Most of this short call orbits one theme: trusting what you ship. Merging wash-lib and wash-cli is about delivery velocity, but the SBOM and build-provenance work is squarely about supply-chain security. An SBOM inventories exactly what went into a build, and provenance attestations (per SLSA) prove how and where a binary was produced — both critical when a WebAssembly component might be pulled from a registry and scheduled anywhere across a fleet, including on Kubernetes. The reason it's hard is the same reason it matters: SLSA Build Level 3 demands isolating the build from the attestation in reusable workflows, which a complex multi-job CI pipeline can't always satisfy without a redesign. The OCI-artifact thread reinforces the point — wasmCloud deliberately distributes components and providers as standard OCI artifacts with the spec's config media type, so the same registry tooling, scanners, and policies that secure container supply chains apply to WebAssembly workloads too.

Who Should Watch This​

This call is useful for wasmCloud contributors and maintainers tracking the wash crate consolidation and its Cargo install change (start at 2:10), platform and security engineers interested in SBOMs, build provenance, and SLSA levels for WebAssembly artifacts (Masoud's update at 5:36), and anyone publishing components or providers who wants to confirm wasmCloud's OCI-artifact compliance (the OCI discussion at 9:45).

Up Next​

The team planned to make Masoud's SBOM and build-provenance work the first discussion item in the following week's community call, after reviewing his comment asynchronously in Slack. Also on deck: tracking down the OCI artifact-format example Masoud was going to post, landing the wash-lib / wash-cli merge PR, and extending the experimental flag to the built-in HTTP client provider — all against the backdrop of KubeCon EU preparations.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →