Playing Safely in the...
summary
WASM modules ship as OCI artifact blobs that reveal imports/exports so tools can inspect capabilities before execution; runtimes like WasmEdge and wasmCloud enforce a per-module sandbox and teams run fuzzers and sanitizers against runtimes. The component model lets engineers choose shared or isolated linear memory to shrink blast radii and apply least privilege. A current proposal adds no-read-no-write pages to give static read‑only regions without heavy OS support, reducing common attack surfaces.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 2:06Containers to WebAssembly security
- 7:07Engineering mistakes in WebAssembly
- 16:40Memory safety and component model
- 25:22WebAssembly sandboxing in practice
- 28:12WebAssembly isn't just containers
- 30:38Security best practices
related talks
39mWhat is Wasm A Non Experts Opinion
38mWebAssembly beyond the browser
36mSandboxing Your Sandbox: Leveraging Hypervisors for WebAssembly Security
31mHow We Can Create a Thriving Wasm Ecosystem
35mModern Sandboxing: Using Web Assembly in Java
48mDon't Trust Anything! Real-world Uses For WebAssembly
17mA case for Web Assembly
33mZero Trust in the Cloud with WebAssembly and WasmCloud
