wasmCloud

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo básico na página do seu projeto! O status do selo básico se parece com isto: O nível do selo básico para o projeto 6363 é baseline-2 Aqui está como incorporar o selo básico:
Você pode mostrar o status do seu selo básico incorporando isto no seu arquivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/6363/baseline)](https://www.bestpractices.dev/projects/6363)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/6363"><img src="https://www.bestpractices.dev/projects/6363/baseline"></a>


Estes são os critérios de Nível Básico 3. Estes são critérios da versão v2026.08.28.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    wasmCloud is a cloud native platform for running WebAssembly workloads across any cloud, Kubernetes, datacenter, or edge.

    Using wasmCloud, you can run microservices, functions, and agents as ultra-dense, deny-by-default bytecode sandboxes that are far more secure and efficient than traditional containers.

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

 Controles 19/21 ●

  • Controles


    Suficiente para um badge!

    Quando um trabalho recebe permissões em um pipeline de CI/CD, o código-fonte ou configuração DEVE atribuir apenas os privilégios mínimos necessários para a atividade correspondente. [OSPS-AC-04.02]
    Configure os pipelines de CI/CD do projeto para atribuir as menores permissões disponíveis a usuários e serviços por padrão, elevando as permissões apenas quando necessário para tarefas específicas. Em alguns sistemas de controle de versão, isso pode ser possível no nível organizacional ou de repositório. Se não, defina permissões no nível superior do pipeline.

    Every workflow in .github/workflows sets a top-level permissions block of contents: read, and each job that needs more (for example id-token: write and attestations: write in release-tag.yml) requests only those scopes at the job level. zizmor's excessive-permissions audit runs on every pull request that changes a workflow (https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/lint-workflows.yml), and the repository default GITHUB_TOKEN permission is read-only.


    Suficiente para um badge!

    Os pipelines de CI/CD que aceitam entradas de colaboradores confiáveis DEVEM sanitizar e validar essas entradas antes de usá-las no pipeline. [OSPS-BR-01.04]
    Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de colaboradores em execuções explícitas de workflow. Embora os colaboradores sejam geralmente confiáveis, as entradas manuais em um workflow não podem ser revisadas e podem ser abusadas por uma tomada de conta ou ameaça interna.

    Collaborator input to pipelines (workflow_dispatch inputs, PR titles, branch names) reaches run steps only through env variables, never by direct expression interpolation; zizmor's template-injection audit enforces this on every pull request that changes a workflow (https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/lint-workflows.yml). Dispatch inputs are choice-typed where possible, and free-form inputs are validated before use: release-train.yml rejects a version override that is not SemVer (https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/release-train.yml).


    Suficiente para um badge!

    Quando um lançamento oficial for criado, todos os ativos dentro desse lançamento DEVEM estar claramente associados ao identificador de lançamento ou outro identificador único para o ativo. [OSPS-BR-02.02]
    Atribua um identificador de versão único a cada ativo de software produzido pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit do git.

    [version_unique]


    Suficiente para um badge!

    O projeto DEVE definir uma política para gerenciar segredos e credenciais usadas pelo projeto. A política deve incluir diretrizes para armazenar, acessar e rotacionar segredos e credenciais. [OSPS-BR-07.02]
    Documente como segredos e credenciais são gerenciados e usados dentro do projeto. Isso deve incluir detalhes sobre como os segredos são armazenados (por exemplo, usando uma ferramenta de gerenciamento de segredos), como o acesso é controlado e como os segredos são rotacionados ou atualizados. Certifique-se de que informações sensíveis não sejam codificadas diretamente no código-fonte ou armazenadas em sistemas de controle de versão.

    SECURITY.md defines the policy for secrets and credentials used by CI and release automation (https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md#secrets-and-credentials): prefer short-lived credentials (Sigstore keyless signing, OIDC role assumption, octo-sts/GitHub App tokens); stored secrets are GitHub Actions secrets with the narrowest scope, never in the repository, images, artifacts or logs, with secret scanning and push protection on; only org maintainers and repository admins can manage them; and secrets are rotated immediately on possible exposure, when a holder loses access, and at least yearly.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a integridade e autenticidade dos ativos de lançamento. [OSPS-DO-03.01]
    As instruções no projeto devem conter informações sobre a tecnologia usada, os comandos a serem executados e a saída esperada. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

    Per security-insights.yml: repository.release.attestations predicate-uri includes slsa Comment says: "Release binaries, container images and WIT interface packages carry Sigstore-signed SLSA provenance. Verify with gh attestation verify --repo wasmCloud/wasmCloud.". [signed_releases]


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a identidade esperada da pessoa ou processo que criou o lançamento de software. [OSPS-DO-03.02]
    A identidade esperada pode estar na forma de IDs de chave usados para assinar, emissor e identidade de um certificado sigstore ou outras formas similares. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

    Per security-insights.yml: repository.release.attestations predicate-uri includes slsa Comment says: "Release binaries, container images and WIT interface packages carry Sigstore-signed SLSA provenance. Verify with gh attestation verify --repo wasmCloud/wasmCloud.". [signed_releases]


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma declaração descritiva sobre o escopo e a duração do suporte para cada lançamento. [OSPS-DO-04.01]
    Para comunicar o escopo e a duração do suporte para os ativos de software lançados pelo projeto, o projeto deve ter um arquivo SUPPORT.md, uma seção "Support" em SECURITY.md ou outra documentação explicando o ciclo de vida do suporte, incluindo a duração esperada de suporte para cada lançamento, os tipos de suporte fornecidos (por exemplo, correções de bugs, atualizações de segurança) e quaisquer políticas ou procedimentos relevantes para obter suporte.

    SUPPORT.md (https://github.com/wasmCloud/wasmCloud/blob/main/SUPPORT.md#supported-releases) states the scope and duration of support: only the latest minor release is supported; fixes ship in the next release on the two-week train, critical vulnerability fixes ship out of cycle; the previous minor stops receiving fixes when a new minor ships; wash, wash-runtime, runtime-operator, runtime-gateway and the Helm chart share one version and support window.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE fornecer uma declaração descritiva de quando lançamentos ou versões não receberão mais atualizações de segurança. [OSPS-DO-05.01]
    Para comunicar o escopo e a duração do suporte para correções de segurança, o projeto deve ter um SUPPORT.md ou outra documentação explicando a política do projeto para atualizações de segurança.

    SUPPORT.md (https://github.com/wasmCloud/wasmCloud/blob/main/SUPPORT.md#supported-releases) states that a minor release stops receiving any fixes, including security fixes, when the next minor release ships (for example 2.11 stops when 2.12.0 is released), and that wasmCloud 1.x is end of life as of v1.9.2. SECURITY.md#supported-versions links it.


    Suficiente para um badge!

    A documentação do projeto DEVE ter uma política de que os colaboradores de código sejam revisados antes de conceder permissões elevadas a recursos sensíveis. [OSPS-GV-04.01]
    Publique uma política aplicável na documentação do projeto que exija que colaboradores de código sejam revisados e aprovados antes de receberem permissões elevadas a recursos sensíveis, como aprovação de merge ou acesso a segredos. É recomendado que a verificação inclua estabelecer uma linhagem justificável de identidade, como confirmar a associação do contribuidor com uma organização confiável conhecida.

    CONTRIBUTION_LADDER.md (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTION_LADDER.md#granting-access) requires review before escalated access (write, maintain or admin on a repository, org ownership, secrets or deployment environments, publishing releases or packages): no one receives it until the PR approving their role merges into MAINTAINERS.md; an org maintainer then grants the lowest level the role needs to the account with the person's contribution history; access is removed on emeritus status and reviewed yearly.


    Insuficiente para um badge.

    Quando o projeto tiver feito um lançamento, todos os ativos de software compilados lançados DEVEM ser entregues com uma lista de materiais de software. [OSPS-QA-02.02]
    É recomendado gerar automaticamente SBOMs no momento da compilação usando uma ferramenta que foi verificada quanto à precisão. Isso permite que os usuários ingiram esses dados de forma padronizada junto com outros projetos em seu ambiente.

    The release workflow generates SPDX SBOMs for every release binary and container image and attaches them, with Sigstore SBOM attestations, to the GitHub Release (https://github.com/wasmCloud/wasmCloud/blob/main/.github/workflows/release-tag.yml, .github/actions/release-binary-sbom, .github/actions/release-image-sbom). This landed on 2026-10-29, after the latest release (v2.11.0), so the first release carrying SBOMs is v2.12.0.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento compreendendo múltiplos repositórios de código-fonte, todos os subprojetos DEVEM impor requisitos de segurança que sejam tão rigorosos ou mais rigorosos que a base de código principal. [OSPS-QA-04.02]
    Quaisquer repositórios de código de subprojeto adicionais produzidos pelo projeto e compilados em um lançamento devem impor requisitos de segurança conforme aplicável ao status e intenção da respectiva base de código. Além de seguir os requisitos correspondentes da Linha de Base OSPS, isso pode incluir exigir uma revisão de segurança, garantir que esteja livre de vulnerabilidades e garantir que esteja livre de problemas de segurança conhecidos.

    wasmCloud's releases are cut from wasmCloud/wasmCloud. The other code repositories (wasmCloud/go, wasmCloud/typescript) enforce the same or stricter rules on main: pull requests with at least one approving review, code owner review, stale review dismissal, required status checks, no force pushes or deletion, plus required DCO and CodeQL code-scanning checks.


    Suficiente para um badge!

    A documentação do projeto DEVE documentar claramente quando e como os testes são executados. [OSPS-QA-06.02]
    Adicione uma seção à documentação de contribuição que explique como executar os testes localmente e como executar os testes no pipeline de CI/CD. A documentação deve explicar o que os testes estão testando e como interpretar os resultados.

    [test]


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política de que todas as mudanças importantes no software produzido pelo projeto devem adicionar ou atualizar testes da funcionalidade em um conjunto de testes automatizado. [OSPS-QA-06.03]
    Adicione uma seção à documentação de contribuição que explique a política para adicionar ou atualizar testes. A política deve explicar o que constitui uma mudança importante e quais testes devem ser adicionados ou atualizados.

    The contribution guide requires tests for new functionality. Its pull request process (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#pull-request-process) says contributors must write tests for any new functionality and ensure all tests pass, and its testing section (https://github.com/wasmCloud/wasmCloud/blob/main/CONTRIBUTING.md#testing) requires unit tests for new functionality, integration tests for CLI commands where appropriate, and tests for error cases and edge conditions. All changes go through reviewed pull requests, and the automated test suites run in GitHub Actions on every pull request (https://github.com/wasmCloud/wasmCloud/actions). [test_policy_mandated]


    Suficiente para um badge!

    Quando um commit for feito no branch principal, o sistema de controle de versão do projeto DEVE exigir pelo menos uma aprovação humana não-autora das mudanças antes do merge. [OSPS-QA-07.01]
    Configure o sistema de controle de versão do projeto para exigir pelo menos uma aprovação humana não-autora das mudanças antes de fazer merge no branch de lançamento ou principal. Isso pode ser alcançado exigindo que um pull request seja revisado e aprovado por pelo menos um outro colaborador antes que possa ser feito o merge.

    The main branch ruleset requires a pull request with at least one approving code-owner review, dismisses stale approvals on push, and requires approval of the most recent push, so every change is reviewed by someone other than its author before merge and release. Required status checks must also pass. [two_person_review]


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma modelagem de ameaças e análise de superfície de ataque para entender e proteger contra ataques em caminhos de código críticos, funções e interações dentro do sistema. [OSPS-SA-03.02]
    Modelagem de ameaças é uma atividade onde o projeto analisa a base de código, processos e infraestrutura associados, interfaces, componentes-chave e "pensa como um hacker" e faz um brainstorming de como o sistema pode ser quebrado ou comprometido. Cada ameaça identificada é listada para que o projeto possa então pensar em como evitar proativamente ou fechar quaisquer lacunas/vulnerabilidades que possam surgir. Certifique-se de que isso seja atualizado para novos recursos ou mudanças críticas.

    Threat model and trust boundaries: THREAT_MODEL.md (https://github.com/wasmCloud/wasmCloud/blob/main/THREAT_MODEL.md) defines the scope, actors, security goals and known limitations, and names four trust boundaries: component to host, workload to workload, workload to plugin, and workload to network. Gemara capability and threat catalogs (https://github.com/wasmCloud/wasmCloud/tree/main/docs/security) link each of 17 threats to the host capability and code that exposes it. SELF_ASSESSMENT.md (https://github.com/wasmCloud/wasmCloud/blob/main/SELF_ASSESSMENT.md#security-functions-and-features) lists the security functions that enforce them.

    Secure design principles: least privilege (a component is linked only against the imports its workload grants, with no ambient filesystem, network or environment access); safe defaults (the address policy denies loopback, link-local and metadata ranges, insecure registries are off, and policy-relaxing flags are opt-in and listed in THREAT_MODEL.md); complete mediation (every outbound wasi:http request and socket operation is checked against allowedHosts and the address policy); economy of mechanism (one TLS stack, rustls, and one sandbox, wasmtime); open design (all mechanisms are open source and documented); separation of privilege (operator, host and workload hold different credentials and grants); least common mechanism (per-workload stores, loopback network and resource quotas).

    Common implementation weaknesses: memory-safety weaknesses (CWE-787, 125, 416) are countered by Rust and Go, with unsafe_code = 'deny' across the workspace and wasmtime bounds checks and guard pages for guest code; injection (CWE-78, 89) by having no shell-outs on request paths and typed APIs; path traversal (CWE-22) by the hostPath allowlist and reserved paths; SSRF (CWE-918) by allowedHosts and the address policy; missing authentication (CWE-306) by NATS credentials and TLS; uncontrolled resource consumption (CWE-400) by memory, connection and file-descriptor quotas and epoch interruption; unsafe deserialization (CWE-502) by typed serde and protobuf decoding. CodeQL, cargo audit and cargo deny run in CI. [assurance_case]


    Insuficiente para um badge.

    Quaisquer vulnerabilidades nos componentes de software que não afetem o projeto DEVEM ser registradas em um documento VEX, complementando o relatório de vulnerabilidade com detalhes de não explorabilidade. [OSPS-VM-04.02]
    Estabeleça um feed VEX comunicando o status de explorabilidade de vulnerabilidades conhecidas, incluindo detalhes de avaliação ou quaisquer mitigações em vigor impedindo que código vulnerável seja executado.

    Advisories that do not affect wasmCloud are recorded with a reason in .cargo/audit.toml (https://github.com/wasmCloud/wasmCloud/blob/main/.cargo/audit.toml), but the project does not yet publish them as VEX documents.


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SCA relacionadas a vulnerabilidades e licenças. [OSPS-VM-05.01]
    Documente uma política no projeto que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. Inclua o processo para identificar, priorizar e remediar essas descobertas.

    SECURITY.md defines remediation thresholds for SCA findings (https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md#dependency-and-code-scanning). Vulnerabilities affecting released code: critical in an out-of-cycle patch within 7 days of a fix, high in the next release (at most 14 days), medium within 90 days, low best effort; non-applicable advisories are suppressed in .cargo/audit.toml with a reason. Licenses: every dependency must be on the deny.toml allowlist mirroring the CNCF allowed-license policy, or carry a linked CNCF exception.


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política para tratar violações de SCA antes de qualquer lançamento. [OSPS-VM-05.02]
    Documente uma política no projeto para abordar os resultados aplicáveis de Análise de Composição de Software antes de qualquer lançamento, e adicione verificações de status que confirmem a conformidade com essa política antes do lançamento.

    SECURITY.md#before-a-release (https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md#before-a-release): a release PR can't merge while cargo audit or cargo deny check licenses fails, or while a known critical or high advisory affecting released code is open.


    Suficiente para um badge!

    Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para dependências maliciosas e vulnerabilidades conhecidas em dependências, e então bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. [OSPS-VM-05.03]
    Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Análise de Composição de Software em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

    Per security-insights.yml: repository.security.tools type=SCA with integration.ci=true Comment says: "RustSec advisory check daily, on pushes to main, and on pull requests that change a Cargo manifest or the lockfile.".


    Suficiente para um badge!

    A documentação do projeto DEVE incluir uma política que defina um limite para a correção de descobertas de SAST. [OSPS-VM-06.01]
    Documente uma política no projeto que defina um limite para remediação de resultados de Teste de Segurança de Aplicação Estática (SAST). Inclua o processo para identificar, priorizar e remediar esses resultados.

    SECURITY.md#code-scanning (https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md#code-scanning): CodeQL and zizmor alerts in released code follow the same severity timeline as vulnerabilities (critical 7 days, high next release, medium 90 days); each alert is fixed or dismissed in the Security tab with a stated reason.


    Suficiente para um badge!

    Todas as mudanças na base de código do projeto DEVEM ser avaliadas automaticamente em relação a uma política documentada para vulnerabilidades de segurança e bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. [OSPS-VM-06.02]
    Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Teste de Segurança de Aplicação Estática (SAST) em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

    Per security-insights.yml: repository.security.tools type=SAST with integration.ci=true Comment says: "Static analysis of GitHub Actions workflows.".



Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/6363/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Brooks Townsend e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Brooks Townsend.
Entrada criada em 2022-08-15 21:56:48 UTC, última atualização em 2026-11-03 20:55:31 UTC. Selo de aprovação perdido pela última vez em 2023-11-02 18:23:16 UTC. Selo de aprovação alcançado pela última vez em 2023-11-02 18:38:53 UTC.