This policy covers the wasmCloud/go repository. The full process, including how reports are triaged, fixed and disclosed, is the wasmCloud Security Process and Policy. How this repository is threatened and defended is in SECURITY_ASSESSMENT.md.

CRA stewardship: This project is supported under the Linux Foundation CRA stewardship framework, as described at https://www.linuxfoundation.org/security. Security vulnerabilities should be reported through the mechanisms described below, which we will coordinate with our CRA steward. For actively exploited vulnerabilities and severe incidents that may require CRA escalation, please use the project's emergency security reporting mechanisms as appropriate.

Don't report security vulnerabilities as public issues, discussions or pull requests. Report them privately in either of these ways:

• Email the private security list at security@wasmcloud.com with the details.
• Use GitHub private vulnerability reporting from this repository's Security tab.

Reports go to the wasmCloud security team, a subset of the org maintainers. Each report is acknowledged within 3 business days.

• Fixed vulnerabilities are published as GitHub Security Advisories in this repository, and reach the Go vulnerability database from there.
• Known vulnerabilities that don't affect the SDK are recorded, with the reason, in the OpenVEX documents in vex/.

go verifies every module it downloads against the Go checksum database, so go get go.wasmcloud.dev/component@vX.Y.Z fails if the module isn't the one first published at that version. Don't turn that check off for go.wasmcloud.dev: leave it out of GONOSUMDB, GOPRIVATE and GOINSECURE, and don't set GOSUMDB=off. To re-check modules already in your module cache, run go mod verify.

Each component/vX.Y.Z tag is pushed by release-tag.yaml as the octo-sts[bot] GitHub App, never by a person. Releases are immutable, so GitHub signs a release attestation when each release is published, binding the tag to its commit. Verify it, and that it was published in this repository, with:

gh release verify component/vX.Y.Z --repo wasmCloud/go

Each release attaches component-vX.Y.Z.zip, the module zip that go get downloads, and SHA256SUMS. Both carry Sigstore-signed SLSA build provenance. Check a download and that release-tag.yaml signed it:

gh attestation verify component-vX.Y.Z.zip \
  --repo wasmCloud/go \
  --signer-workflow wasmCloud/go/.github/workflows/release-tag.yaml

Releases published before 2026-11-05 predate immutable releases and have neither the release attestation nor these assets; for those, rely on the checksum database.

Each ghcr.io/wasmcloud/go-airgap image carries two signed attestations, both pushed to the registry beside it: SLSA build provenance, and an SPDX software bill of materials generated by syft. Check the image and the workflow that built it:

gh attestation verify oci://ghcr.io/wasmcloud/go-airgap:<tag> \
  --repo wasmCloud/go \
  --signer-workflow wasmCloud/go/.github/workflows/airgapped.yaml

To verify and print the SBOM:

gh attestation verify oci://ghcr.io/wasmcloud/go-airgap:<tag> \
  --repo wasmCloud/go \
  --signer-workflow wasmCloud/go/.github/workflows/airgapped.yaml \
  --predicate-type https://spdx.dev/Document/v2.3 \
  --format json --jq '.[0].verificationResult.statement.predicate'

This repository follows the stored secrets and rotation policy of the wasmCloud project. In this repository that means:

• What is stored: no credential for releases. release-train.yaml and release-tag.yaml exchange their job's OIDC token with octo-sts for an app token that expires within an hour. Each has a trust policy in .github/chainguard that admits only that workflow on main, with only the permissions it needs. Every other workflow uses only its job's GITHUB_TOKEN or OIDC.
• Storage: any secret a workflow needs lives only in GitHub Actions secrets, never in the repository, images, artifacts or logs. Secret scanning and push protection block a push that contains a detected secret.
• Access: only repository admins (@wasmCloud/go-maintainers) and org maintainers can create, update or delete them. Changing a trust policy takes a reviewed pull request to main. Pull requests, including those from forks, never run a workflow that reads a secret or gets an octo-sts token.
• Rotation: a secret is rotated immediately if it may have been exposed, when someone who held it or administers it loses that access, and at least once a year. octo-sts tokens need no rotation: each is minted per job and revoked when the job ends.