Skip to main content
← Back

wasmCloud News: GitHub Actions Toolkit, Wash Attestation & WebGPU

For the latest WebAssembly news, the October 1, 2025 wasmCloud community call walks an end-to-end demo of a new GitHub Actions toolkit for the wash CLI — built around supply-chain security with binary attestation, SBOM generation via cargo auditable, and a language-agnostic build/publish flow. Bailey Hayes also previews a new non-interactive mode for CI and proposed volume mounts for wash plugins, while Colin Murphy and the team explore WebGPU, hybrid AI inferencing, and the road to the next version of wasmCloud and the Wasm component model.

Key Takeaways​

  • The new GitHub Actions toolkit gives a canonical, marketplace-discoverable way to set up and install wash in CI, with plugins, caching, and a one-to-one release cadence tracking the next version of wash (currently beta 9)
  • Binary attestation is now built in — the setup-wash action always installs and attests wash from signed binary releases (with SHAs and a provenance chain) using GitHub's native attestation, and you can't opt out of that verification
  • SBOM support is opt-in for Rust via a setup-cargo-auditable action; running cargo auditable before wash build embeds an SBOM in the .wasm output so the artifact is immediately attestable, pending first-party SBOM support in upstream cargo
  • A language-agnostic wash build action standardizes where artifacts land across toolchains (cargo, npm, and others), and a publish action does OCI publish with attestation enabled — composable from a repo without being on the Marketplace
  • A new non-interactive mode lets wash plugins run privileged host operations (like git clone or copy) in CI where there's no TTY to confirm prompts — a prerequisite Bailey hit while building her own plugin
  • Volume mounts for wash plugins were proposed to replace the awkward "copy out of scratch" pattern, aligning plugins with the volume-mount concept in the next host and workload spec
  • The next version of wasmCloud is roughly two weeks from a real release candidate, with Colin Murphy now a champion for the wasmCloud clocks proposal landing a much-requested time zones API, and Victor making big progress on a second reference implementation in JCO
  • WebGPU is emerging as the portable, hardware-agnostic standard for hybrid AI inferencing — with wgpu (Firefox) and Dawn (Chrome) as interchangeable backends — and a Firefox component model update from Ryan Hunt and Luke Wagner is coming at the end of the month

Chapters​

Meeting Notes​

GitHub Actions Toolkit: Installing wash with Built-in Attestation​

Bailey Hayes walked through the new GitHub Actions toolkit end to end, having shown a mostly-working version the previous week. The toolkit is a monorepo containing several actions, with the setup-wash action split out into its own repository so it can be listed in the GitHub Marketplace as the canonical way to set up and install wash. Because it's designed around the next version of wash (currently on beta 9), the action carries a release-candidate tag — it's feature complete but won't be a stable major version until the next wasmCloud release is stable. Every new feature has been cut as a release in lockstep with wash, and the action can install plugins and immediately set up a working environment, leveraging the cache.

The key change over the prior week: setup-wash now installs and attests wash from signed binary releases rather than building from source. Bailey added extra verification to the wash release itself — SHAs and a provenance chain — using GitHub's native attestation integration. The setup-wash action always verifies the artifact's attestation (you can't opt out), then caches the binary. Users building their own components can opt into attestation on the publish operation and verify provenance with the GitHub CLI's gh attestation command, all from the standard wash developer workflow.

SBOMs with cargo auditable, and a Language-Agnostic wash build​

Inside the actions monorepo, Bailey demonstrated a publish action for a Rust component built with cargo auditable, which is Wasm-enabled: when wash build runs the underlying cargo build, the .wasm output carries an SBOM of the dependency chain. Until first-party SBOM support lands in upstream cargo, the new setup-cargo-auditable action configures wash to build with cargo auditable (it has to run before wash build), making the output immediately attestable. SBOM generation is opt-in.

The wash build action itself is intentionally simple but handy: it produces output identifying the artifact path in a language-agnostic way, since a cargo build, an npm build, and other toolchains each emit artifacts in different locations (see the build-and-publish developer guide for the underlying flow). Bailey kept it as a composite action rather than publishing it to the Marketplace. A publish.yaml example tied all the actions together — wash build, then OCI publish with attestation enabled at the end — and demonstrated that you can reference an action from a GitHub repo without it being on the Marketplace; the Marketplace's value is discovery. Feedback and contributions to the toolkit are welcome.

CI Story for the wash CLI: Non-Interactive Mode and Volume Mounts​

Bailey stressed why CI is worth so much attention before cutting the release: for a CLI tool that people build through CI, the CI story has to be buttoned up. She hit a concrete blocker building her own plugin, which uses a wash feature letting a plugin execute privileged commands on the host (e.g. a copy or a git clone) after a user confirms a prompt. In CI there's no one to say yes and no TTY shell — so she added a non-interactive mode that runs those operations by default in a non-interactive shell, which is exactly what a CI workflow needs.

She also began work on volume mounts for wash plugins. Today every plugin gets its own scratch cache directory mounted in when a component requests a host filesystem import, and plugins copy results out of scratch back to the real path with a privileged host exec (the very operation that forced the non-interactive fix). Bailey called that pattern weird and unexpected — Brooks agreed before heading out on vacation — and proposed mirroring the volume-mount concept from the next version of the host and workload spec, so a plugin could, say, mount the current working directory and modify in place. This work aligns with Brooks' open runtime pull request from two weeks prior.

Next Release Candidate, Time Zones, and the JCO Reference Implementation​

In community updates, Bailey noted that the next version of wasmCloud is roughly two weeks from a real release candidate (not yet feature complete), with porting scripts ready to move workloads from wadm to straight Kubernetes. Colin Murphy is now one of the champions for the wasmCloud clocks proposal, landing API changes and a much-requested time zones feature; a second release candidate is out for implementers, and Colin planned to cut another with the clock refactoring. Bailey gave a shout-out to Victor's huge progress on a second reference implementation inside JCO, which takes a component and runs it in a Node.js environment — the same APIs, a totally different execution path from the Rust host.

WebGPU, Hybrid AI Inferencing, and the Component Model​

Colin Murphy laid out a vision of compiling GPU and cryptography workloads to wasmCloud so that "anyone can just compile to it" without even knowing they're using WebAssembly. Asked by Liam about WebGPU's hardware agnosticism, Colin explained it's the emerging standard, with two interchangeable backends — Rust-based wgpu (from Firefox) and Google's Dawn (C++) — that are "just the back end," so it doesn't matter which side a workload lands on. He framed hybrid AI inferencing as the goal: the browser handles the client side via WebGPU while wasmCloud handles the server side, seamlessly. Bailey pointed to Firefox's Mozilla-maintained in-browser inferencing engine enabling sandboxed personal agents that keep your data local, and to a forthcoming Firefox component model update from Ryan Hunt and Luke Wagner at the end of the month. Bailey was also syncing with one of the WebAssembly CG chairs to align the component model proposal with the broader Community Group work.

WebAssembly News and Updates​

This community call doubles as a WebAssembly news roundup focused on supply-chain security and portable compute. The headline is wasmCloud's GitHub Actions toolkit, which bakes binary attestation and SBOM generation (via cargo auditable) into the wash build-and-publish flow using GitHub's native provenance integration — a meaningful step for securing the WebAssembly software supply chain. On the runtime front, WebGPU is converging as the portable, hardware-agnostic API for GPU and AI workloads, with wgpu and Dawn as interchangeable backends, and Mozilla's in-browser inferencing engine pointing toward sandboxed, local-first agents. And the Wasm component model continues to mature: a JCO second reference implementation is progressing, the wasmCloud clocks proposal is adding time zones, and Ryan Hunt and Luke Wagner are slated to give a Firefox component model update at the end of the month. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

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#, and more) 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 primary tool for building, signing, and shipping components — increasingly with first-class CI/CD integration and supply-chain attestation. 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 Attestation for WebAssembly​

The center of gravity in this call is supply-chain security for WebAssembly artifacts. The new GitHub Actions toolkit treats provenance as a default, not an add-on: setup-wash installs wash only from signed, attested binary releases and verifies that provenance chain on every run, so a compromised mirror or tampered download can't slip into your workflow. For the components you build, the publish action wires up GitHub's native artifact attestation so that each .wasm you push to an OCI registry carries a signed statement of how and from what it was built — verifiable later with gh attestation. Layering cargo auditable on top embeds an SBOM directly in the Wasm binary, capturing the dependency graph for audit. Together these make the WebAssembly artifact itself the unit of trust: small, sandboxed, and now cryptographically traceable from source to registry to running host. As wasmCloud moves toward its next major release, this CI-first, attestation-by-default posture is what makes the wash CLI safe to drop into automated pipelines.

Who Should Watch This​

This call is especially valuable for platform and DevOps engineers wiring WebAssembly builds into CI/CD pipelines who want attestation and SBOMs without bespoke tooling (start with the GitHub Actions walkthrough at 6:00), wash plugin authors and contributors tracking the non-interactive mode and volume-mount changes before the API stabilizes (the CI deep dive at 15:27), and AI/ML and edge developers curious about WebGPU, hybrid inferencing, and where the component model is headed (Colin's WebGPU discussion at 21:35).

Up Next​

The next community calls lead into the next major wasmCloud release — expect the real release candidate (about two weeks out), more wash API changes around volume mounts to land before stabilization, and the new runtime operator that began rolling out the week of this call. Watch also for the end-of-month Firefox component model update from Ryan Hunt and Luke Wagner, and continued progress on the JCO second reference implementation. Bailey explicitly asked for feedback on the proposed wash features now, before the API is finalized.

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 →