WebAssembly (Wasm)

What it does

The WebAssembly (Wasm) card connects Safeguard to Wasm components and modules stored as OCI artifacts in any registry that implements the OCI distribution spec (GitHub Container Registry, Docker Hub, Harbor, zot and others). Safeguard lists every repository and tag, and says for each tag whether it is a Wasm artifact. Each tag you select becomes a project that Safeguard scans. Find the card under Integrations on the Project/Product tab.

A Wasm scan reads the binary itself:

• whether it is a core module or a component, its size and sha256;
• the toolchain that built it, from the producers custom section (for example rustc 1.90.0, wit-component 0.234.0), recorded as metadata, not as dependencies;
• the WIT interfaces a component imports and exports, with versions (for example wasi:sockets/tcp@0.2.3), and the imports and exports of a core module (for example wasi_snapshot_preview1.path_open);
• dependencies embedded at build time: Rust crates recorded by cargo-auditable in the .dep-v0 custom section, which are matched against vulnerability advisories;
• other notable custom sections: name, sourceMappingURL, build_id, DWARF debug sections;
• cosign signatures on the OCI artifact.

The result is a CycloneDX 1.6 SBOM with the artifact as the main component, plus capability findings.

What a Wasm scan cannot know

• No OS packages. A Wasm artifact has no operating system layer.
• Only embedded dependencies. Dependencies are listed only when the build embedded them. Today that is Rust built with cargo auditable build. Go, TinyGo, C and C++, AssemblyScript and JavaScript (for example ComponentizeJS) components usually carry only toolchain names, so their dependency list is empty. An empty list means unknown, not clean.
• Build-only crates are not matched. Crates cargo-auditable marks as build dependencies are listed with scope excluded and are not matched against advisories, because they are not in the binary.
• Nested components are read recursively. Nested core modules and nested components are parsed (up to 16 levels). Capabilities come from the top-level imports and exports only, because imports of nested parts are satisfied inside the component.
• Imports are capabilities, not vulnerabilities. An import says what the code can ask the host for; the host decides what it grants. Language standard libraries import file system and environment interfaces even when the program never calls them.
• Signatures are verified only with your key. See Signatures.

Capability findings

Low means the capability reaches outside the sandbox if the host grants it. Info means ordinary plumbing. Nothing is rated higher, because an import alone never proves misuse.

Public vs private

Many registries (GitHub Container Registry and Docker Hub among them) do not offer a catalog to ordinary users. List the repositories by URL for those.

Supported auth methods

Only https registries are connected. Plain http:// registries are refused.

Permissions required

Safeguard only reads: it lists repositories and tags, and pulls manifests and blobs. It never pushes, tags or deletes. The least-privilege credential is a read-only (pull) token that can see only the repositories you want scanned.

Username and password or token

Registry names for pull access:

Least privilege: a dedicated read-only token or robot account limited to the repositories that hold Wasm artifacts.

Anonymous

Least privilege: nothing to configure.

Token types

Expiry: prefer tokens that expire, for example after 90 days. When a token expires, listing and scans fail with HTTP 401 until you enter a new one.

What we never need: push, delete, admin or user management rights.

Step-by-step setup

Publish a Wasm artifact (if you have not yet)

The CNCF TAG Runtime layout is a manifest with config media type application/vnd.wasm.config.v0+json and one application/wasm layer. wkg oci push writes it; with oras:

oras push registry.example.com/team/app:1.0.0 \
  --config config.json:application/vnd.wasm.config.v0+json \
  app.wasm:application/wasm

Build Rust components with cargo auditable build --target wasm32-wasip2 so the dependency list is embedded. Spin applications pushed with spin registry push are read too.

Create the credential

1. In your registry, create a read-only token or robot account (see Permissions required).
2. Copy the token. Most registries show it only once.

Connect it in Safeguard

1. Open Integrations and choose the Project/Product tab.
2. Click Connect on the WebAssembly (Wasm) card.
3. Choose Public or Private.
4. Public: enter a Name and the Repositories, one per line. Click Check repositories.
5. Private: enter a Name, the Registry host (for example ghcr.io), the Username and the Password or token. Optionally list Repositories. Click Verify credentials.
6. Click Next. Every repository is listed. Open a repository's tags: each tag shows its digest and whether it is a Wasm artifact.
7. Select the repositories and tags and click Connect.

Or with the Safeguard CLI

safeguard wasm inspect ./app.wasm
safeguard wasm scan ./app.wasm -o app.cdx.json
safeguard wasm scan oci://registry.example.com/team/app:1.0.0 --key cosign.pub
echo "$TOKEN" | safeguard wasm scan registry.example.com/team/app:1.0.0 --username ci --password-stdin

See CLI usage.

Webhooks and triggers

This integration has no webhooks: the OCI distribution spec has no standard push notification. Scans run when you connect, on the schedule you set, or when you rescan by hand.

What we read and store

• Read: repository and tag lists, the manifest of each tag (to classify it and pin the digest), the Wasm config blob, the Wasm layer, and cosign signature manifests and payloads.
• Stored: the SBOM, the capability findings, vulnerability findings for embedded dependencies, the manifest digest and the signature status. Credentials are encrypted at rest and never shown again after you save them.
• Not stored: the Wasm binary itself is not kept after the scan.
• No customer data from this integration is sent to third-party LLMs.

Each scan resolves the tag to its manifest digest and reads that digest, so the result is for exactly that artifact. A tag that is a container image rather than a Wasm artifact is scanned as a container image.

Signatures

Safeguard looks for cosign signatures in two places: the sha256-<digest>.sig tag cosign has always used, and the OCI 1.1 referrers API.

• Keyed signatures are verified with the public key you give (safeguard wasm inspect --key cosign.pub): the signature must verify and its payload must name this artifact's manifest digest. The result is "signed and verified" or "signature present but did not verify".
• Keyless signatures (Fulcio certificate) and Sigstore bundles found through the referrers API are reported as "signature present, not verified". The certificate identity is not shown, because the certificate chain and Rekor entry are not verified. Use cosign verify --certificate-identity ... --certificate-oidc-issuer ... for that.
• Hosted scans have no public key, so they report presence only.

Troubleshooting

Rotation and disconnect

• Rotate: edit the connection, enter the username and the new token, verify, and save. Leave the password blank to keep the stored one. Then revoke the old token in the registry.
• Disconnect: delete the connection under Integrations, then revoke the token or robot account in the registry.

Vendor references

• WebAssembly core binary format, checked 2026-10-16.
• Component Model binary format, checked 2026-10-16.
• Producers section, checked 2026-10-16.
• cargo-auditable parsing guide, checked 2026-10-16.
• CNCF TAG Runtime Wasm OCI artifact layout, checked 2026-10-16.
• wasm-pkg-tools registry metadata, checked 2026-10-16.
• OCI distribution spec, checked 2026-10-16.
• Cosign signature spec, checked 2026-10-16.
• GitHub Container Registry authentication, checked 2026-10-16.
• Docker Hub access token permissions, checked 2026-10-16.
• Harbor robot accounts, checked 2026-10-16.