wasmCloud

wasmCloud makes an effort to maintain all stable APIs across versions.

The one major upgrade so far, v1 to v2, has a step-by-step migration guide at https://wasmcloud.com/docs/migration/. It covers what changed and why, an architecture comparison, a concept migration map from v1 to v2, and instructions for migrating capability providers, applications, secrets, configuration and distributed networking, plus what was intentionally removed. The v1 documentation remains available at https://wasmcloud.com/docs/v1/ for users still on v1.

https://github.com/wasmCloud/wasmCloud/issues

https://github.com/wasmCloud/wasmCloud/security/advisories

https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md

With all our Rust codebases we require PRs to pass cargo check, audit, and clippy format + lints https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/wash.yml

With all our Rust codebases we require PRs to pass cargo clippy format + lints coding styles https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/wash.yml

We simply compile using cargo flags

We simply build using cargo flags

We don't recursively build subdirectories

Rust supports bit-for-bit builds https://github.com/rust-lang/rust/issues/34902

We support installation in a wide variety of ways on https://wasmcloud.com/docs/installation, in addition to just cargo install or curling a github release tarball.

No custom installation system

We support simply using a standard Rust toolchain or using a devcontainer to make changes.

https://github.com/wasmCloud/wasmCloud/blob/main/Cargo.toml

We have Dependabot enabled across our key repositories

https://github.com/wasmCloud/wasmCloud/blob/main/Cargo.toml

We do not use deprecated functions and APIs

We report multiple automated test suites for each check-in.

We have a vast set of regression tests in our wasmbus test suite

Statement coverage is measured in CI with cargo-llvm-cov (FLOSS) on every push to main (https://github.com/wasmCloud/wasmCloud/actions/workflows/coverage.yml), and the job fails if line or region coverage drops below 80% (xtask/src/coverage.rs). The latest run on main reports 83.34% line coverage: https://github.com/wasmCloud/wasmCloud/actions/runs/41673826482/job/126048957835.

The contribution guide requires tests for new functionality. Its pull request process (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#pull-request-process) says contributors must write tests for any new functionality and ensure all tests pass, and its testing section (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#testing) requires unit tests for new functionality, integration tests for CLI commands where appropriate, and tests for error cases and edge conditions. All changes go through reviewed pull requests, and the automated test suites run in GitHub Actions on every pull request (https://github.com/wasmCloud/wasmCloud/actions).

The project's instructions for change proposals include the policy. The Pull Request Process in the contribution guide (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#pull-request-process) lists "Write tests for any new functionality" as a required step before submitting a pull request, and its Testing section (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#testing) requires unit tests for new functionality and integration tests for CLI commands where appropriate. The pull request template (https://github.com/wasmCloud/wasmCloud/blob/main/.github/pull_request_template.md) points every contributor to this guide.

Fails builds if cargo clippy is not satisfied or if formatting is incorrect

All controls are deny-by-default and is designed to be secure by default. See our THREAT_MODEL.md https://github.com/wasmCloud/wasmCloud

wasmCloud's default security mechanisms use no algorithms or modes with known serious weaknesses. TLS (inbound ingress, outbound wasi:http, OCI registries, NATS) uses rustls 0.23 with the aws-lc-rs provider, which implements only TLS 1.2 and 1.3 with AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) and ECDHE key exchange; it has no SSLv3, RC4, 3DES, CBC-mode or SHA-1 signature support enabled by default. Component content is identified by SHA-256 OCI digests (crates/wash-runtime/src/component_source.rs). The project's code does not use SHA-1, MD5, DES or RC4. The only weak primitive in the dependency tree is MD5 in postgres-protocol, used solely when a Postgres server is configured for legacy MD5 password authentication; SCRAM-SHA-256 is used otherwise.

wasmCloud supports multiple cryptographic algorithms through rustls 0.23 with the aws-lc-rs provider, which it uses for all TLS (HTTP ingress, outbound wasi:http, OCI registries, NATS). Symmetric ciphers: AES-128-GCM, AES-256-GCM and ChaCha20-Poly1305. Hashes: SHA-256 and SHA-384 in the TLS 1.2 and 1.3 cipher suites. Key exchange: X25519, P-256 and P-384 ECDHE, plus the X25519MLKEM768 post-quantum hybrid. Signatures: ECDSA (P-256, P-384), Ed25519 and RSA-PSS/PKCS#1 with SHA-2. The algorithm is negotiated per connection, so a peer that disables one algorithm (for example a server restricting its suites) still interoperates using another. wasmCloud does not hard-code any algorithm, so one found to be broken is removed by a rustls/aws-lc-rs update without changing wasmCloud code. Content digests use SHA-256 via the OCI digest format, which names its algorithm and so allows others such as SHA-512.

Keys, certificates and credentials are kept separate from the code and supplied at runtime, so they can be replaced without rebuilding: TLS server certificate and key paths (--tls-cert-path, --tls-key-path), client CA bundles (--tls-ca-path, --http-client-ca-path, --oci-ca-path), outbound client certificates (--http-client-cert-path, --http-client-key-path), NATS TLS and credential files (--scheduler-nats-tls-, --data-nats-tls-), OCI registry credentials, and workload secrets delivered through wasmcloud:secrets. See crates/wash/src/cli/host.rs. NATS credential files are reread when they change, so credentials can be rotated without restarting the host.

Outbound connections default to encrypted protocols: OCI registry pulls use HTTPS unless an operator explicitly sets --allow-insecure-registries (default false), outbound wasi:http requests to https:// hosts use TLS, and NATS connections support TLS (and TLS-first) with CA and client certificates. Inbound HTTP ingress supports TLS (--tls-cert-path/--tls-key-path). Plain HTTP ingress remains available for deployments where a gateway or ingress controller terminates TLS in front of the host.

All TLS in wasmCloud uses rustls 0.23 (with the aws-lc-rs provider), via rustls, tokio-rustls, hyper-rustls, reqwest's rustls-tls and oci-client's rustls-tls features (workspace Cargo.toml). rustls implements only TLS 1.2 and TLS 1.3 and has no support for SSL or TLS 1.0/1.1.

TLS clients verify server certificates by default. Client configurations are built with rustls ClientConfig::builder().with_root_certificates(...) using the platform's native trust store, webpki roots, and any operator-supplied CA bundles (crates/wash-runtime/src/host/http_client.rs). The codebase contains no custom certificate verifier and no option to disable verification.

Certificate verification happens during the rustls TLS handshake, before any application data is sent, so no request, header, credential or body is transmitted to a peer whose certificate fails verification.

Per security-insights.yml: repository.release.attestations predicate-uri includes slsa Comment says: "Release binaries, container images and WIT interface packages carry Sigstore-signed SLSA provenance. Verify with gh attestation verify --repo wasmCloud/wasmCloud.".

wasmCloud validates input from every untrusted source and rejects what is not allowed, using allowlists where the data has restrictions:

• WebAssembly components (untrusted code): wasmtime validates every component's binary format and types before compiling it, and rejects invalid modules. A component is linked only against the imports its workload spec grants; any other import fails instantiation (crates/wash-runtime/src/engine/mod.rs).
• Control-plane requests over NATS: workload start/update/stop messages are deserialized into typed protobuf/serde structures and validated before use (crates/wash-runtime/src/washlet/mod.rs); malformed or invalid requests are rejected with an error.
• Kubernetes resources: the runtime-operator's CRDs carry OpenAPI schema validation (kubebuilder validation markers in runtime-operator/api/runtime/v1alpha1/), so the API server rejects invalid specs before the operator sees them.
• Outbound network access: wasi:http requests are allowed only to hosts on the workload's allowedHosts allowlist (crates/wash-runtime/src/host/allowed_hosts.rs, egress_policy.rs), and socket connections are checked against the workload spec and the host's address policy, which denies loopback, link-local and metadata ranges by default (crates/wash-runtime/src/sockets/policy.rs).
• Filesystem access: hostPath volumes must fall inside the operator's --allowed-host-path allowlist, and reserved host paths are refused (crates/wash/src/cli/host.rs, crates/wash-runtime/src/engine/volumes.rs).
• Inbound HTTP: requests are parsed by hyper, which rejects malformed HTTP, and are routed only to workloads that declared a matching route; unmatched requests are rejected.
• OCI artifacts: components pulled by digest are checked against that SHA-256 digest.

The threat model (https://github.com/wasmCloud/wasmCloud/blob/main/THREAT_MODEL.md) describes these trust boundaries in more detail.

wasmCloud uses several hardening mechanisms so that defects are less likely to become vulnerabilities:

• Memory-safe languages and denied undefined behavior: the host, CLI and plugins are Rust and the operator and gateway are Go. The Rust workspace denies unsafe_code for every crate ([workspace.lints.rust] in Cargo.toml, with warnings also denied); the few exceptions are individually annotated #[allow(unsafe_code)] sites for OS FFI and environment mutation, each with a SAFETY comment.
• Lints that eliminate crash and misuse classes: the workspace denies clippy's unwrap_used, expect_used, panic, indexing_slicing, panicking_unwrap, transmute_ptr_to_ref, transmute_undefined_repr and serde_api_misuse ([workspace.lints.clippy] in Cargo.toml), so an unexpected input yields an error instead of a panic, an out-of-bounds index, or an unsound transmute.
• Compiler and linker hardening: Rust release binaries are built with the toolchain's default mitigations for Linux targets (position-independent executables, full RELRO, non-executable stack and data, and stack probes against stack clashing), and Go binaries get the Go runtime's bounds checking and stack guards.
• Sandboxing of untrusted code: guest WebAssembly runs in wasmtime with bounds-checked linear memory and guard pages, structured control flow (Wasm-level control-flow integrity), Spectre mitigations on memory and table accesses, and epoch-based interruption, so a defect in guest code cannot read or write host memory.
• Resource limits: per-workload and host-wide limits on guest memory, connections and file descriptors (crates/wash-runtime/src/engine/guest_memory.rs, crates/wash-runtime/src/host/quota.rs) keep a defect from exhausting the host.
• Continuous checks: CodeQL, zizmor, cargo audit and cargo deny run in CI.

Threat model and trust boundaries: THREAT_MODEL.md (https://github.com/wasmCloud/wasmCloud/blob/main/THREAT_MODEL.md) defines the scope, actors, security goals and known limitations, and names four trust boundaries: component to host, workload to workload, workload to plugin, and workload to network. Gemara capability and threat catalogs (https://github.com/wasmCloud/wasmCloud/tree/main/docs/security) link each of 17 threats to the host capability and code that exposes it. SELF_ASSESSMENT.md (https://github.com/wasmCloud/wasmCloud/blob/main/SELF_ASSESSMENT.md#security-functions-and-features) lists the security functions that enforce them.

Secure design principles: least privilege (a component is linked only against the imports its workload grants, with no ambient filesystem, network or environment access); safe defaults (the address policy denies loopback, link-local and metadata ranges, insecure registries are off, and policy-relaxing flags are opt-in and listed in THREAT_MODEL.md); complete mediation (every outbound wasi:http request and socket operation is checked against allowedHosts and the address policy); economy of mechanism (one TLS stack, rustls, and one sandbox, wasmtime); open design (all mechanisms are open source and documented); separation of privilege (operator, host and workload hold different credentials and grants); least common mechanism (per-workload stores, loopback network and resource quotas).

Common implementation weaknesses: memory-safety weaknesses (CWE-787, 125, 416) are countered by Rust and Go, with unsafe_code = 'deny' across the workspace and wasmtime bounds checks and guard pages for guest code; injection (CWE-78, 89) by having no shell-outs on request paths and typed APIs; path traversal (CWE-22) by the hostPath allowlist and reserved paths; SSRF (CWE-918) by allowedHosts and the address policy; missing authentication (CWE-306) by NATS credentials and TLS; uncontrolled resource consumption (CWE-400) by memory, connection and file-descriptor quotas and epoch interruption; unsafe deserialization (CWE-502) by typed serde and protobuf decoding. CodeQL, cargo audit and cargo deny run in CI.

clippy lints for several common vulnerabilities. It is the standard tool for detecting this type of vulnerabilities in the Rust ecosystem.

N/A. The software wasmCloud produces is written in memory-safe languages: Rust (host, CLI, plugins) and Go (operator, gateway); the repository contains no C or C++ in its shipped components. The Rust workspace denies unsafe_code by default ([workspace.lints.rust] in Cargo.toml). The small number of exceptions are individually annotated #[allow(unsafe_code)] sites, each with a SAFETY comment, for OS FFI (macOS process footprint and signal mask, Windows file streams, UDP socket options) and for environment-variable mutation, which Rust 2024 marks unsafe and which the host serializes behind a lock. The operator's Go code also has native fuzz tests (e.g. runtime-operator/api/runtime/v1alpha1/workload_fuzz_test.go) whose seed corpora run with the regular test suite. Untrusted guest code runs inside wasmtime, a Bytecode Alliance project that is continuously fuzzed with sanitizers through OSS-Fuzz.