Wrangle

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 na página do seu projeto! O status do selo se parece com isto: O nível do selo para o projeto 15135 é silver Aqui está como incorporá-lo:
Você pode mostrar o status do seu selo incorporando isto no seu arquivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15135/badge)](https://www.bestpractices.dev/projects/15135)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/15135"><img src="https://www.bestpractices.dev/projects/15135/badge"></a>


Estes são os critérios de nível de Aprovação. Você também pode visualizar os critérios de nível Prata ou Ouro.

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

        

 Fundamentos 13/13 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    Prepare scientific data with native Polars, reusable YAML protocols, a readable CLI and reproducible evidence. Researchers and agents use the same checked preparation engine.

    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.

  • Conteúdo básico do site do projeto


    Suficiente para um badge!

    O site do projeto DEVE descrever sucintamente o que o software faz (qual problema ele resolve?). [description_good]
    Isso DEVE estar em linguagem que usuários potenciais possam entender (por exemplo, ele usa o mínimo de jargão).

    The merged source README explains how Wrangle turns research files into checked analysis tables using reusable YAML protocols. It identifies researchers and agents as users and excludes model building.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md


    Suficiente para um badge!

    O site do projeto DEVE fornecer informações sobre como: obter, fornecer feedback (como relatórios de bugs ou melhorias) e contribuir com o software. [interact]

    The public README and CONTRIBUTING give installation, examples, issue reporting and the pull-request path. Bug and pull-request templates identify the required information.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/ISSUE_TEMPLATE/bug-report.md


    Suficiente para um badge!

    As informações sobre como contribuir DEVEM explicar o processo de contribuição (por exemplo, pull requests são usados?) (URL obrigatória) [contribution]
    Presumimos que projetos no GitHub usam issues e pull requests, a menos que indicado de outra forma. Essa informação pode ser breve, por exemplo, declarando que o projeto usa pull requests, um rastreador de issues ou postagens em uma lista de discussão (qual?)

    CONTRIBUTING documents a public pull-request process against master, development setup, acceptance requirements and review. The PR template provides a matching checklist.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md


    Suficiente para um badge!

    As informações sobre como contribuir DEVERIAM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação exigido). (URL obrigatória) [contribution_requirements]

    CONTRIBUTING states acceptable researcher-focused changes, scientific declarations, coding rules, meaningful tests, documentation and review requirements. pyproject.toml specifies the enforced Ruff rules and exceptions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


  • Licença FLOSS


    Suficiente para um badge!

    O software produzido pelo projeto DEVE ser lançado como FLOSS. [floss_license]
    FLOSS é software lançado de uma forma que atende à Definição de Código Aberto ou à Definição de Software Livre. Exemplos de tais licenças incluem CC0, MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Para nossos propósitos, isso significa que a licença DEVE ser: O software PODE também ser licenciado de outras formas (por exemplo, "GPLv2 ou proprietário" é aceitável).

    Wrangle source is licensed under the OSI-approved MIT license, available in the top-level LICENSE and package metadata.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


    Suficiente para um badge!

    É SUGERIDO que qualquer licença(s) exigida para o software produzido pelo projeto seja aprovada pela Open Source Initiative (OSI). [floss_license_osi]
    A OSI usa um processo de aprovação rigoroso para determinar quais licenças são OSS.

    The project uses the OSI-approved MIT license, declared in LICENSE and pyproject.toml.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


    Suficiente para um badge!

    O projeto DEVE publicar a(s) licença(s) de seus resultados em um local padrão em seu repositório de código-fonte. (URL obrigatória) [license_location]
    Uma convenção é publicar a licença como um arquivo de nível superior chamado LICENSE ou COPYING, que PODE ser seguido por uma extensão como ".txt" ou ".md". Uma convenção alternativa é ter um diretório chamado LICENSES contendo arquivo(s) de licença; esses arquivos são tipicamente nomeados como seu identificador de licença SPDX seguido por uma extensão de arquivo apropriada, conforme descrito na Especificação REUSE. Observe que este critério é apenas um requisito no repositório de código-fonte. Você NÃO precisa incluir o arquivo de licença ao gerar algo a partir do código-fonte (como um executável, pacote ou contêiner). Por exemplo, ao gerar um pacote R para a Comprehensive R Archive Network (CRAN), siga a prática padrão do CRAN: se a licença for uma licença padrão, use a especificação de licença curta padrão (para evitar instalar outra cópia do texto) e liste o arquivo LICENSE em um arquivo de exclusão como .Rbuildignore. Da mesma forma, ao criar um pacote Debian, você pode colocar um link no arquivo de copyright para o texto da licença em /usr/share/common-licenses e excluir o arquivo de licença do pacote criado (por exemplo, deletando o arquivo após chamar dh_auto_install). Nós encorajamos a inclusão de informações de licença legíveis por máquina em formatos gerados, quando praticável.

    The public repository has a top-level LICENSE containing the MIT license; package metadata also declares MIT.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


  • Documentação


    Suficiente para um badge!

    O projeto DEVE fornecer documentação básica para o software produzido pelo projeto. [documentation_basics]
    Esta documentação deve estar em alguma mídia (como texto ou vídeo) que inclua: como instalá-lo, como iniciá-lo, como usá-lo (possivelmente com um tutorial usando exemplos) e como usá-lo de forma segura (por exemplo, o que fazer e o que não fazer) se esse for um tópico apropriado para o software. A documentação de segurança não precisa ser longa. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. Se o projeto não produz software, escolha "não aplicável" (N/A).

    The public README and shipped getting-started guide explain installation, real-file drafting, minimal complete examples, preparation and result reuse. The security requirements explain expected guarantees and limits.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md


    Suficiente para um badge!

    O projeto DEVE fornecer documentação de referência que descreva a interface externa (tanto entrada quanto saída) do software produzido pelo projeto. [documentation_interface]
    A documentação de uma interface externa explica a um usuário final ou desenvolvedor como usá-la. Isso incluiria sua interface de programação de aplicativos (API) se o software tiver uma. Se for uma biblioteca, documente as principais classes/tipos e métodos/funções que podem ser chamados. Se for uma aplicação web, defina sua interface de URL (geralmente sua interface REST). Se for uma interface de linha de comando, documente os parâmetros e opções que suporta. Em muitos casos, é melhor que a maior parte desta documentação seja gerada automaticamente, para que essa documentação permaneça sincronizada com o software conforme ele muda, mas isso não é obrigatório. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. A documentação PODE ser gerada automaticamente (quando praticável, esta é frequentemente a melhor forma de fazê-lo). A documentação de uma interface REST pode ser gerada usando Swagger/OpenAPI. A documentação da interface de código PODE ser gerada usando ferramentas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) e Doxygen (muitos). Simplesmente ter comentários no código de implementação não é suficiente para satisfazer este critério; precisa haver uma maneira fácil de ver a informação sem ler todo o código-fonte. Se o projeto não produz software, escolha "não aplicável" (N/A).

    The generated catalog and operation contracts document arguments, preconditions, outputs and errors from the engine definitions. The recipe manual documents grammar, scientific boundaries and recovery; CLI help exposes the same operations.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/operations.json https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/recipes.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/build_catalog.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py


  • Outro


    Suficiente para um badge!

    Os sites do projeto (site, repositório e URLs de download) DEVEM suportar HTTPS usando TLS. [sites_https]
    Isso requer que a URL da página inicial do projeto e a URL do repositório de controle de versão comecem com "https:", não "http:". Você pode obter certificados gratuitos do Let's Encrypt. Os projetos PODEM implementar este critério usando (por exemplo) GitHub pages, GitLab pages ou SourceForge project pages. Se você suportar HTTP, recomendamos que você redirecione o tráfego HTTP para HTTPS.

    The merged source identifies the HTTPS GitHub repository as the project homepage. Source and package distribution use HTTPS.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


    Suficiente para um badge!

    O projeto DEVE ter um ou mais mecanismos para discussão (incluindo mudanças propostas e questões) que sejam pesquisáveis, permitam que mensagens e tópicos sejam endereçados por URL, permitam que novas pessoas participem de algumas das discussões e não exijam instalação no lado do cliente de software proprietário. [discussion]
    Exemplos de mecanismos aceitáveis incluem lista(s) de discussão arquivadas, discussões de questões e pull requests do GitHub, Bugzilla, Mantis e Trac. Mecanismos de discussão assíncronos (como IRC) são aceitáveis se atenderem a esses critérios; certifique-se de que haja um mecanismo de arquivamento endereçável por URL. JavaScript proprietário, embora desencorajado, é permitido.

    Public GitHub issues and pull requests provide searchable, URL-addressable discussion through ordinary web access.
    Evidence: https://github.com/autonomio/wrangle/issues https://github.com/autonomio/wrangle/pulls


    Suficiente para um badge!

    O projeto DEVERIA fornecer documentação em inglês e ser capaz de aceitar relatórios de bugs e comentários sobre código em inglês. [english]
    O inglês é atualmente a língua franca da tecnologia de computadores; o suporte ao inglês aumenta o número de diferentes desenvolvedores e revisores em potencial em todo o mundo. Um projeto pode atender a este critério mesmo que o idioma principal de seus desenvolvedores principais não seja o inglês.

    The project README, manuals, contribution instructions and issue/PR templates are English; discussion can be conducted in English.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/issues


    Suficiente para um badge!

    O projeto DEVE ser mantido. [maintained]
    No mínimo, o projeto deve tentar responder a relatórios significativos de problemas e vulnerabilidades. Um projeto que está buscando ativamente um badge provavelmente é mantido. Todos os projetos e pessoas têm recursos limitados, e projetos típicos devem rejeitar algumas mudanças propostas, portanto, recursos limitados e rejeições de propostas não indicam por si só um projeto não mantido.

    Quando um projeto souber que não será mais mantido, ele deve definir este critério como "Não atendido" e usar o(s) mecanismo(s) apropriado(s) para indicar a outros que não está sendo mantido. Por exemplo, use "DEPRECATED" como o primeiro cabeçalho de seu README, adicione "DEPRECATED" perto do início de sua página inicial, adicione "DEPRECATED" ao início da descrição do projeto do repositório de código, adicione um badge de sem intenção de manutenção em seu README e/ou página inicial, marque-o como descontinuado em quaisquer repositórios de pacotes (por exemplo, npm deprecate), e/ou use o sistema de marcação do repositório de código para arquivá-lo (por exemplo, a configuração "archive" do GitHub, a marcação "archived" do GitLab, o status "readonly" do Gerrit ou o status de projeto "abandoned" do SourceForge). Discussão adicional pode ser encontrada aqui.

    The owner actively maintains Wrangle through the merged native-Polars preparation release, meaningful tests and successful public CI. GOVERNANCE identifies maintenance roles; SECURITY defines issue and private-vulnerability handling.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md


 Controle de Mudanças 9/9 ●

  • Repositório de código-fonte público controlado por versão


    Suficiente para um badge!

    O projeto DEVE ter um repositório de código-fonte controlado por versão que seja publicamente legível e tenha uma URL. [repo_public]
    A URL PODE ser a mesma que a URL do projeto. O projeto PODE usar branches privados (não públicos) em casos específicos enquanto a mudança não for lançada publicamente (por exemplo, para corrigir uma vulnerabilidade antes de ser revelada ao público).

    The GitHub repository publicly exposes project source, commits, tags and pull requests.
    Evidence: https://github.com/autonomio/wrangle https://github.com/autonomio/wrangle/commits/master


    Suficiente para um badge!

    O repositório de código-fonte do projeto DEVE rastrear quais mudanças foram feitas, quem fez as mudanças e quando as mudanças foram feitas. [repo_track]

    Git commit history records authors, dates and individual source changes.
    Evidence: https://github.com/autonomio/wrangle https://github.com/autonomio/wrangle/commits/master


    Suficiente para um badge!

    Para permitir revisão colaborativa, o repositório de código-fonte do projeto DEVE incluir versões intermediárias para revisão entre lançamentos; ele NÃO DEVE incluir apenas lançamentos finais. [repo_interim]
    Os projetos PODEM optar por omitir versões intermediárias específicas de seus repositórios de código-fonte públicos (por exemplo, aquelas que corrigem vulnerabilidades de segurança não públicas específicas, podem nunca ser lançadas publicamente ou incluem material que não pode ser legalmente postado e não estão no lançamento final).

    Public git history contains intermediate development commits between releases, including the native 1.0 development commits merged through PR46.
    Evidence: https://github.com/autonomio/wrangle https://github.com/autonomio/wrangle/commits/master


    Suficiente para um badge!

    É SUGERIDO que software de controle de versão distribuído comum seja usado (por exemplo, git) para o repositório de código-fonte do projeto. [repo_distributed]
    O Git não é especificamente exigido e os projetos podem usar software de controle de versão centralizado (como subversion) com justificativa.

    Wrangle uses git, a commonly used distributed version-control system.
    Evidence: https://github.com/autonomio/wrangle https://github.com/autonomio/wrangle/commits/master


  • Numeração de versão única


    Suficiente para um badge!

    Os resultados do projeto DEVEM ter um identificador de versão único para cada lançamento destinado a ser usado pelos usuários. [version_unique]
    Isso PODE ser atendido de várias maneiras, incluindo IDs de commit (como git commit id ou mercurial changeset id) ou um número de versão (incluindo números de versão que usam versionamento semântico ou esquemas baseados em data como AAAAMMDD).

    Public releases have distinct version identifiers and git references. Native v1.0.0 is now published as a GitHub release with the tag pointing to merged master b6.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/releases https://github.com/autonomio/wrangle/tags https://github.com/autonomio/wrangle/releases/tag/v1.0.0


    Suficiente para um badge!

    É SUGERIDO que o formato de numeração de versão Versionamento Semântico (SemVer) ou Versionamento de Calendário (CalVer) seja usado para lançamentos. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro. [version_semver]
    Os projetos geralmente devem preferir qualquer formato que seja esperado por seus usuários, por exemplo, porque é o formato normal usado por seu ecossistema. Muitos ecossistemas preferem SemVer, e SemVer é geralmente preferido para interfaces de programação de aplicações (APIs) e kits de desenvolvimento de software (SDKs). CalVer tende a ser usado por projetos que são grandes, têm um número excepcionalmente grande de dependências desenvolvidas independentemente, têm um escopo em constante mudança ou são sensíveis ao tempo. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro, porque incluir um nível micro suporta branches mantidos simultaneamente sempre que isso se tornar necessário. Outros formatos de numeração de versão podem ser usados como números de versão, incluindo IDs de commit do git ou IDs de changeset do mercurial, desde que identifiquem exclusivamente as versões. No entanto, algumas alternativas (como IDs de commit do git) podem causar problemas como identificadores de lançamento, porque os usuários podem não ser capazes de determinar facilmente se estão atualizados. O formato do ID de versão pode não ser importante para identificar lançamentos de software se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua).

    Suficiente para um badge!

    É SUGERIDO que os projetos identifiquem cada lançamento dentro de seu sistema de controle de versão. Por exemplo, é SUGERIDO que aqueles que usam git identifiquem cada lançamento usando tags do git. [version_tags]

    Published releases are identified by git tags, including native v1.0.0 at b6f5354caf3e428ef23325a41e87ac9d1e767eff and legacy v0.7.6. A tag reference is not a cryptographic tag signature.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/releases https://github.com/autonomio/wrangle/tags https://github.com/autonomio/wrangle/releases/tag/v1.0.0


  • Notas de lançamento


    Suficiente para um badge!

    O projeto DEVE fornecer, em cada lançamento, notas de lançamento que sejam um resumo legível por humanos das principais mudanças nesse lançamento para ajudar os usuários a determinar se devem atualizar e qual será o impacto da atualização. As notas de lançamento NÃO DEVEM ser a saída bruta de um log de controle de versão (por exemplo, os resultados do comando "git log" não são notas de lançamento). Projetos cujos resultados não se destinam à reutilização em vários locais (como o software para um único site ou serviço) E empregam entrega contínua PODEM selecionar "N/A". (URL obrigatória) [release_notes]
    As notas de lançamento PODEM ser implementadas de várias maneiras. Muitos projetos as fornecem em um arquivo chamado "NEWS", "CHANGELOG" ou "ChangeLog", opcionalmente com extensões como ".txt", ".md" ou ".html". Historicamente, o termo "change log" significava um log de todas as mudanças, mas para atender a esses critérios, o que é necessário é um resumo legível por humanos. As notas de lançamento PODEM, em vez disso, ser fornecidas por mecanismos de sistema de controle de versão, como o fluxo de trabalho GitHub Releases.

    CHANGELOG and the published v1.0.0 release describe native behavior, compatibility and upgrade impact. Human-readable historical notes include reconstructed 0.6.10 notes; the migration guide describes corrected scientific behavior.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CHANGELOG.md https://github.com/autonomio/wrangle/releases/tag/v0.6.10 https://github.com/autonomio/wrangle/releases/tag/v0.7.6 https://github.com/autonomio/wrangle/releases/tag/v1.0.0


    Suficiente para um badge!

    As notas de lançamento DEVEM identificar todas as vulnerabilidades de tempo de execução publicamente conhecidas corrigidas neste lançamento que já tinham uma atribuição CVE ou similar quando o lançamento foi criado. Este critério pode ser marcado como não aplicável (N/A) se os usuários normalmente não conseguem atualizar o software por conta própria (por exemplo, como geralmente é verdade para atualizações de kernel). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Se não houver notas de lançamento ou se não houve vulnerabilidades publicamente conhecidas, escolha N/A. [release_notes_vulns]
    Este critério ajuda os usuários a determinar se uma determinada atualização irá corrigir uma vulnerabilidade que é publicamente conhecida, para ajudar os usuários a tomar uma decisão informada sobre atualização. Se os usuários normalmente não conseguem atualizar o software por conta própria em seus computadores, mas devem depender de um ou mais intermediários para realizar a atualização (como é frequentemente o caso de um kernel e software de baixo nível que está entrelaçado com um kernel), o projeto pode escolher "não aplicável" (N/A) em vez disso, já que essa informação adicional não será útil para esses usuários. Da mesma forma, um projeto pode escolher N/A se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Listar as vulnerabilidades de todas as dependências transitivas de um projeto torna-se difícil conforme as dependências aumentam e variam, e é desnecessário já que ferramentas que examinam e rastreiam dependências podem fazer isso de uma forma mais escalável.

    The project owner confirms release notes identify every applicable publicly known Wrangle runtime vulnerability fix that already had a CVE or equivalent identifier when the release was created. Report counts and incident absence are not inferred. Owner attestation: https://github.com/autonomio/wrangle/blob/6dbd01b69f987030ed9aa8fc2f2d4d298fa03f70/wrangle/docs/security/openssf-evidence.yaml
    Evidence: https://github.com/autonomio/wrangle/blob/6dbd01b69f987030ed9aa8fc2f2d4d298fa03f70/wrangle/docs/security/openssf-evidence.yaml


 Relatórios 8/8 ●

 Qualidade 13/13 ●

 Segurança 16/16 ●

 Análise 8/8 ●


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/15135/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 Mikko Kotila e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Mikko Kotila.
Entrada criada em 2026-10-01 15:20:31 UTC, última atualização em 2026-10-01 19:59:56 UTC. Selo de aprovação alcançado pela última vez em 2026-10-01 19:54:19 UTC.