Wasm modules are uploaded as separate files next to your bundled JavaScript, so you have two artifacts to review: the JavaScript with its npm packages and the binary with whatever was compiled into it. Track both, along with the toolchain, and expect the binary to hide its dependencies from manifest scanners.
How the pieces fit on Workers
Cloudflare documents that Workers supports WebAssembly through the WebAssembly.instantiate() API, which supports pre compiled modules. Each Worker runs in a single thread. SIMD is supported. WASI support is described as experimental, with only some syscalls implemented.
On the build side, Wrangler bundles JavaScript with esbuild, and non JavaScript files such as .wasm are uploaded as separate modules by default. With find_additional_modules set, matching files can be included as unbundled external modules.
Two artifacts, two inventories
| Artifact | How dependencies are declared | How to inventory |
|---|---|---|
| JavaScript bundle | package.json and lockfile, combined by esbuild | Scan the lockfile, check a dry run bundle |
| .wasm module | Compiled in from C, C++, Rust or another language | Record source dependencies and the toolchain at build time |
The lockfile for the Worker project will not mention a C library compiled into a module. If the module came from a vendor, the library list may not be public.
What to capture for each deployment
- The Worker lockfile hash.
- The hash of each .wasm file.
- The source repository and commit for each module you built.
- The compiler and its version, plus build flags.
- The compatibility date and flags.
- The list of source libraries inside each module, from the module's own build files.
If you also run a size optimizer such as wasm-opt, which Cloudflare mentions for reducing binary size, record that step too.
Behavior to know about
Cloudflare says Workers that use WebAssembly are typically larger than an equivalent JavaScript Worker, and larger Workers can take longer to start. That gives teams a reason to trim modules, which in turn is a chance to drop unused features and dependencies.
The platform page does not make security claims or describe limits in numbers, so avoid stating specifics that you have not checked on the current limits page.
Review questions
- Do we rebuild the module when an upstream library gets a fix?
- Who owns the rebuild, and how will we know it is due?
- Does the JavaScript glue code validate data going into and out of the module?
- Could a smaller module do the same work with fewer compiled libraries?
- Is the module from a source we can verify?
Keep the glue code honest
The JavaScript that calls the module is where input validation belongs. The sandbox limits what the module can reach on the host, but the module can still produce wrong output if fed hostile input and has a bug inside.
Try it yourself
Click through it at your own pace, or open it full screen.
This is the view you get from a lockfile. Ask yourself what a binary file would add to it, and where that list would come from.
Quick check
Does Wrangler bundle .wasm files into the JavaScript?
By default they are uploaded as separate modules, according to the Wrangler bundling documentation.
Is WASI fully supported on Workers?
Cloudflare describes WASI support as experimental, with only some syscalls implemented. Check the current page before depending on it.
Safeguard's SBOM and dependency scanning can cover the source repositories you compile into modules, alongside your Worker lockfile. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
