소프트웨어 공급망 보안과 모듈 검증

The WASM sandbox protects the host at runtime, but it does not guarantee the module you run is the one you trust. Supply chain security covers where the bytes came from.

Key risks:

• Tampered modules in transit or storage
• Compromised build pipelines
• Malicious third-party WASM dependencies

Pin a module by its content hash so any byte change is detected before instantiation.

Cryptographic signatures prove authorship. The publisher signs the module; the host verifies with the corresponding public key before running it.

Always verify integrity/signature before calling WebAssembly.instantiate — never run untrusted bytes and check afterward.

Build attestations (e.g. SLSA) record how and where a module was built, letting you reject artifacts not produced by your trusted pipeline.

A WASM module may bundle third-party code. Track a bill of materials (SBOM) and scan dependencies for known vulnerabilities.

Deterministic builds let independent parties rebuild the same module and confirm the hash matches, defeating hidden tampering in the toolchain.

When pulling modules from a registry, use signed references and pin versions/digests rather than mutable tags to prevent substitution attacks.

Maintain an allowlist of approved module hashes in production. The host refuses to instantiate anything not on the list.

Combine sandbox + signing + provenance + capability limits. No single layer is sufficient; together they shrink the attack surface dramatically.

When should signature verification happen?

Supply chain security complements the runtime sandbox: use hashing for integrity, signatures for authorship, provenance/SBOM for trust, verify before instantiation, and allowlist approved hashes in production.