Skip to main content
← Back

CI Hardening, Continuous Fuzzing & Cross-Component Streams

Watch on YouTube ↗

The May 20, 2026 wasmCloud community call opens with the launch of AI-generated meeting notes and transcripts for every wasmCloud Wednesday, then digs into security: Bailey Hayes walks through the wasmCloud 2.2 release, CI hardening with CodeQL and OpenSSF Scorecard, and a new continuous-fuzzing story for the Kubernetes runtime operator. Aditya demos component socket tunneling — a forked SQLx driver talking to MySQL over WASI sockets — which leads into a deep discussion of cross-component streams and futures in the Wasm component model, where Bailey argues that composing components is both simpler and ~5x faster than wiring them through the Wasmtime linker.

Key Takeaways​

  • AI-generated meeting notes and transcripts now launch for every wasmCloud Wednesday call — all 2026 meetings are done, 2025 is being backfilled, alongside wasmcloud.com SEO work (WebP image conversion, social/Open Graph tags, content restructuring)
  • wasmCloud 2.2 was shipping during the call; the staging gates added the previous week had regressed the automated release flow ("you didn't change this code, so I'll skip it" — but the release needed it), fixed the same day
  • CI hardening: CodeQL coverage was fixed after discovering ~50% of the Rust codebase is macro expansions that need a pre-warmed cache to analyze (it sat at 49%), and OpenSSF Scorecard findings were cut from ~60 down to ~11
  • Continuous fuzzing landed for the Kubernetes runtime operator using Go's native fuzzing — modeled on Istio and cert-manager — targeting host interfaces and spec merging where JSON handling can panic; an overnight run surfaced bugs (in the test authoring, not the code under test)
  • Google OSS-Fuzz onboarding is low priority: the Go fuzz tests already run continuously in CI, and the host's untrusted-code sandbox inherits Wasmtime's robust, long-running fuzzing
  • Demo: component socket tunneling — explicit sandbox-port rules let a component connect out to a host OS port; a forked SQLx driver composed onto WASI sockets powered a live to-do app talking to MySQL on port 3306
  • Cross-component streams and futures: Wasmtime's dynamic linker doesn't pass stream, future, or error-context types between components; Aditya's PR adds that support, while Bailey's alternative — composing the components into one — sidesteps the linker entirely, runs ~5x faster, and previews future component-model runtime instantiation
  • The "Are We Fast Yet?" benchmark lands right after 2.2; KubeCon NA submissions are due May 31, and a booth and maintainer-track slot at KubeCon India (June 18) are being explored for Aditya

Chapters​

Meeting Notes​

New AI-Generated Community Notes and Site SEO​

Liam Randall kicked off with a tour of the new community meeting notes. After roughly five years of wasmCloud Wednesday calls, the project is now generating AI summaries and full transcripts for each meeting — two documents per call, with key takeaways and hot-links into the discussion. The goal is discoverability: some of the best WebAssembly and CNCF wasmCloud discussions happen on these calls, and they should be far easier to find and rediscover. All 2026 meetings are complete, 2025 is being backfilled, and the team will decide later whether to keep, refresh, or retire the 2022–2024 archive given how much wasmCloud's architecture has evolved.

Liam also summarized the broader wasmcloud.com SEO pass: converting large legacy images to WebP, ensuring social/Open Graph tags are configured across the site, deprioritizing older content, and raising the priority of newer material — tracked under "SEO"-tagged pull requests, with Eric Gregory triaging.

wasmCloud 2.2, CI Hardening, and CodeQL​

Bailey Hayes gave an update on wasmCloud 2.2, which was going out during the call. The staging gates landed the previous week had broken the automated release pipeline — the gate "smartly" skipped a step because the relevant code hadn't changed, but the release needed it — and that regression was fixed the same day.

On CI hardening: the team got CodeQL reporting and learned that about 50% of the Rust codebase is macro expansions, which CodeQL can't inspect without a pre-warmed cache, so coverage metrics were artificially low (sitting at 49%). After fixing the cache, Bailey kept whittling down findings from the OpenSSF Scorecard — from roughly 60 flagged items down to about 11.

Continuous Fuzzing and Google OSS-Fuzz​

One Scorecard finding was the lack of continuous fuzzing, so Bailey opened a PR adding Go native fuzzing to the runtime/Kubernetes operator — modeled on how Istio and cert-manager fuzz the spots where controllers merge specs or handle JSON, since that's where panics and weird runtime outcomes hide. An overnight run surfaced a few bugs, though they came from authoring the tests rather than the code under test.

A completer fuzzing story, Bailey noted, would reuse Wasmtime's existing corpus against wasmCloud's host layer — the thin layer above the sandbox where wasmCloud parses bytes, inspects interfaces, and feeds them down. Liam asked whether wasmCloud should onboard to Google OSS-Fuzz; Bailey's take was that it's low priority: the Go fuzz tests already run continuously in CI, and the untrusted-code sandbox itself is unchanged from Wasmtime, which is already fuzzed robustly and continuously. Liam connected this to the recent wave of LLM-assisted vulnerability discovery (and the value of inheriting Wasmtime's security posture), but agreed it isn't the current top priority.

Demo: Component Socket Tunneling with SQLx​

Aditya demoed a pull request that lets a component tunnel out to a host OS port through explicit port definitions. A new set of sandbox-port rules means a socket attempting to connect to, say, 5432 can be redirected, while a plain sandbox-port mapping pointed at 3306 lets the component reach the host's network namespace directly — something previously impossible because the TCP sockets were looped through a virtualized network space.

The demo used a fork of SQLx whose transport layer was composed onto WASI sockets instead of Tokio, with a config.yaml rule set permitting a connection to port 3306. An HTTP component served a WASI HTTP server and called into a service-lead component that pooled connections to a MySQL database. The result was a live to-do app — adding items, marking them done, running filtered table joins, and a live-refreshing table view — all persisting to MySQL over the tunneled socket. Aditya plans to submit it to the wasmCloud demos repo as an example.

Cross-Component Streams, Composition, and Runtime Instantiation​

Aditya then raised a harder problem: trying to create a stream in one component and consume it in another doesn't work in wasmCloud, because stream, future, and error-context types aren't supported by Wasmtime's dynamic linker across components. His PR (plus an upstream Wasmtime change) aims to add async-compatible cross-component stream communication.

Bailey reframed the architecture. A wasmCloud workload has an optional service component (the long-lived "front door"/router with the chops to do egress and routing) plus stateless reactor-style components that can also link and call each other. His proposed alternative to extending the linker: compose the workload's components into a single component. Composition makes the stream/future problem disappear — the component model wires up async streams natively — and Bailey found it improves performance by ~5x. It also previews a future component-model feature, runtime instantiation, where the service acts as the root component and instantiates only what it needs on demand.

The tradeoff Chris Obdam flagged in chat: composed components scale together. Bailey's answer — for the "diabolical case" of unrelated components bundled into one workload, recommend separate workload deployments (zero scaling impact), and consider in-memory host-local routing so same-host workloads skip the network. The throughline: give people enough "picks and shovels" to build the right platform for their workloads.

Benchmarking and KubeCon​

Bailey is holding the "Are We Fast Yet?" benchmark PR until 2.2 is out, then will land it and pay the "GitHub Actions tax" of re-running a new workflow dozens of times before it works — expecting it live the following week. Good performance data is a prerequisite for the sweeping architectural changes (host component plugins, HTTP routing, HTTP instance reuse for P3) he wants to make. On community: KubeCon NA submissions are due May 31 (the team offers feedback on CNCF wasmCloud submissions), and Aditya is attending KubeCon India (June 18) — Liam will check with CNCF about a project-pavilion booth, and Bailey suggested looking into the maintainer track.

WebAssembly News and Updates​

This call lands squarely in the current WebAssembly conversation about supply-chain security and component-to-component communication. The fuzzing discussion echoes the broader push — visible in Wasmtime's continuous fuzzing and recent LLM-assisted security reviews across the Bytecode Alliance — toward hardening the runtimes that execute untrusted code. Meanwhile, cross-component streams and futures sit at the frontier of the Wasm component model and WASI Preview 3's async model: how do stream and future values move between independently sandboxed components? wasmCloud's answer — favor composition over linker plumbing — is a pragmatic read on where the component model is heading. For more, follow webassembly news from the Bytecode Alliance and the WASI subgroup.

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 runs on Wasmtime, ships a Kubernetes-native runtime operator, and bakes in OpenTelemetry observability so you can trace components in production. By scheduling sandboxed Wasm components across a distributed mesh, wasmCloud bridges WebAssembly's portable, deny-by-default execution model and real-world cloud-native infrastructure.

Topic Deep Dive: Cross-Component Communication in the Wasm Component Model​

The most technically interesting thread of this call is how independently sandboxed components talk to each other. In wasmCloud today, components in a workload can link and call one another, but the Wasm component model types that make async communication ergonomic — stream, future, and error-context — aren't yet passed across components by Wasmtime's dynamic linker. There are two paths forward. One extends the linker to support those types directly (Aditya's PR). The other, which Bailey favors, composes the cooperating components into a single component ahead of time: the component model then wires the async streams up natively, no linker val-type juggling required, with a measured ~5x performance win. Composition also sets up runtime instantiation, a future component-model capability where a root "service" component lazily instantiates the sub-components it actually needs. For platform teams, the practical guidance is to model truly independent workloads as separate deployments (so they scale independently) and reserve composition for components that genuinely collaborate. This is the kind of architectural decision the component model is uniquely positioned to make safe — composition without trust escalation, with the blast radius bounded at the component boundary.

Who Should Watch This​

This call is especially useful for platform and security engineers hardening CI/CD supply chains (CodeQL, OpenSSF Scorecard, and the OSS-Fuzz decision — from 10:01), Kubernetes operator developers curious how Go native fuzzing applies to controllers that merge specs (15:04), and developers building multi-component wasmCloud workloads who need cross-component streams or are weighing composition vs. linking (30:34).

Up Next​

Expect the "Are We Fast Yet?" benchmark to land the following week, clearing the path for the larger architectural changes Bailey wants to benchmark first: host component plugins, HTTP routing, and HTTP instance reuse for WASI P3. Aditya's socket-tunneling SQLx demo should arrive as a wasmCloud demos example, and the cross-component streams/composition discussion will continue. Watch for KubeCon India coordination as well.

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 →