Chances

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 15137 é passing 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/15137/badge)](https://www.bestpractices.dev/projects/15137)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/15137"><img src="https://www.bestpractices.dev/projects/15137/badge"></a>


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

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

        

 Fundamentos 16/17 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    Scientific randomness from declared protocols, with verified arrays, explicit streams, execution receipts and conditional exact replay.

    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.

    Passing is earned. Silver proposals are grounded in merged source and execution evidence at https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/.bestpractices.json . PR #48 prepares authenticated source/distribution publication. Silver remains unearned: dependency findings, completed signed publication, access continuity, vulnerability-report credit, and the historical regression-test denominator remain unresolved. https://github.com/autonomio/chances/pull/48

  • Pré-requisitos


    Suficiente para um badge!

    O projeto DEVE alcançar um distintivo de nível aprovado. [achieve_passing]

  • Conteúdo básico do site do projeto


    Suficiente para um badge!

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

    CONTRIBUTING links the constitution, locked development setup, meaningful review brief, and required quality checks. The constitution defines PR acceptance, coding conventions, and the ten merge gates. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CLAUDE.md


  • Supervisão do projeto


    Mal suficiente para um badge.

    O projeto DEVERIA ter um mecanismo legal onde todos os desenvolvedores de quantidades não triviais de software do projeto afirmem que estão legalmente autorizados a fazer essas contribuições. A abordagem mais comum e facilmente implementada para fazer isso é usando um Developer Certificate of Origin (DCO), onde os usuários adicionam "signed-off-by" em seus commits e o projeto faz link para o site do DCO. No entanto, isso PODE ser implementado como um Contributor License Agreement (CLA) ou outro mecanismo legal. (URL obrigatória) [dco]
    O DCO é o mecanismo recomendado porque é fácil de implementar, rastreado no código-fonte e o git suporta diretamente um recurso "signed-off" usando "commit -s". Para ser mais eficaz, é melhor que a documentação do projeto explique o que "signed-off" significa para aquele projeto. Um CLA é um acordo legal que define os termos sob os quais obras intelectuais foram licenciadas para uma organização ou projeto. Um contributor assignment agreement (CAA) é um acordo legal que transfere direitos em uma obra intelectual para outra parte; os projetos não são obrigados a ter CAAs, já que ter CAA aumenta o risco de que contribuidores potenciais não contribuam, especialmente se o receptor for uma organização com fins lucrativos. Os CLAs da Apache Software Foundation (a licença de contribuidor individual e o CLA corporativo) são exemplos de CLAs, para projetos que determinam que os riscos desses tipos de CLAs para o projeto são menores do que seus benefícios.

    A DCO, CLA, or equivalent contributor authorization mechanism is not currently required or documented. The project retains its MIT license and reviewed contribution process, but those are not represented as developer legal attestations. This SHOULD criterion has been considered; retrospective legal assertions will not be inferred from existing commits, and introducing a contribution-signoff obligation requires an explicit governance decision. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CONTRIBUTING.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/LICENSE https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md


    Suficiente para um badge!

    O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave). (URL obrigatória) [governance]
    É necessário haver alguma forma bem estabelecida e documentada de tomar decisões e resolver disputas. Em projetos pequenos, isso pode ser tão simples quanto "o proprietário do projeto e líder toma todas as decisões finais". Existem vários modelos de governança, incluindo ditador benevolente e meritocracia formal; para mais detalhes, consulte Modelos de governança. Tanto abordagens centralizadas (por exemplo, mantenedor único) quanto descentralizadas (por exemplo, grupo de mantenedores) foram usadas com sucesso em projetos. As informações de governança não precisam documentar a possibilidade de criar um fork do projeto, já que isso é sempre possível para projetos FLOSS.

    GOVERNANCE identifies maintainers as the decision authority for priority, release timing, review requirements, and project scope. MAINTAINERS assigns responsibilities and names the sole approving authority; CLAUDE defines the enforced contribution and review process. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md


    Suficiente para um badge!

    O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. (URL obrigatória) [code_of_conduct]
    Os projetos podem ser capazes de melhorar a civilidade de sua comunidade e estabelecer expectativas sobre conduta aceitável adotando um código de conduta. Isso pode ajudar a evitar problemas antes que ocorram e tornar o projeto um lugar mais acolhedor para encorajar contribuições. Isso deve se concentrar apenas no comportamento dentro da comunidade/local de trabalho do projeto. Exemplos de códigos de conduta são o código de conduta do kernel Linux, o Contributor Covenant Code of Conduct, o Código de Conduta Debian, o Código de Conduta Ubuntu, o Código de Conduta Fedora, o Código de Conduta GNOME, o Código de Conduta da Comunidade KDE, o Código de Conduta da Comunidade Python, A Diretriz de Conduta da Comunidade Ruby e O Código de Conduta do Rust.

    The standard root CODE_OF_CONDUCT.md states expected and prohibited behavior, moderation consequences, and the route for reporting conduct issues to maintainers. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CODE_OF_CONDUCT.md


    Suficiente para um badge!

    O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma. (URL obrigatória) [roles_responsibilities]
    A documentação para governança e papéis e responsabilidades pode estar em um único lugar.

    MAINTAINERS names Mikko Kotila as maintainer and assigns release approval, security triage, issue prioritization, and merge decisions. It separately identifies bit-mis as required reviewing authority, with the review and environment activation process linked. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md


    Informações obrigatórias desconhecidas, insuficiente para um badge.

    O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS). (URL obrigatória) [access_continuity]

    Unresolved maintainer fact: if either the maintainer or bit-mis becomes unable or unwilling to support the project, can another authorized person create and close issues, accept changes, and release software within one week, including repository/organization administration, release approval, PyPI access, and necessary legal authority? Who owns this continuity role, and where is the recovery procedure documented? Existing admin access alone does not prove publication capability or succession authority. No continuity attestation is inferred. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/.github/CODEOWNERS


    Mal suficiente para um badge.

    O projeto DEVERIA ter um "bus factor" de 2 ou mais. (URL obrigatória) [bus_factor]
    Um "bus factor" (também conhecido como "truck factor") é o número mínimo de membros do projeto que precisam desaparecer repentinamente de um projeto ("ser atropelados por um ônibus") antes que o projeto pare devido à falta de pessoal conhecedor ou competente. A ferramenta truck-factor pode estimar isso para projetos no GitHub. Para mais informações, consulte Assessing the Bus Factor of Git Repositories de Cosentino et al.

    Only one current maintainer is publicly documented. Review and organization access do not by themselves establish that a second person has the scientific, security, and release knowledge needed to sustain the project. This SHOULD criterion has been considered: the small project currently retains centralized maintainership and its designated review authority, rather than claiming undocumented staffing or changing reviewer policy to satisfy a badge. Access continuity is assessed separately. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md


  • Documentação


    Suficiente para um badge!

    O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano. (URL obrigatória) [documentation_roadmap]
    O projeto pode não alcançar o roadmap, e isso é aceitável; o objetivo do roadmap é ajudar usuários e contribuidores potenciais a entender a direção pretendida do projeto. Não precisa ser detalhado.

    The roadmap merged in PR #46 covers 2026-10-02 through 2027-10-31 and documents planned capabilities, maintenance priorities, and excluded scope for at least the next year. This source is on protected master. https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/docs/Roadmap.md https://github.com/autonomio/chances/pull/46


    Suficiente para um badge!

    O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A). (URL obrigatória) [documentation_architecture]
    Uma arquitetura de software explica as estruturas fundamentais de um programa, ou seja, os principais componentes do programa, os relacionamentos entre eles e as principais propriedades desses componentes e relacionamentos.

    The package boundary documents major modules and their responsibilities, and the documentation hub explains the execution sequence from protocol validation through local generation, output checks, publication, verification, and replay. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/README.md


    Suficiente para um badge!

    O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança"). (URL obrigatória) [documentation_security]
    Estes são os requisitos de segurança que o software deve atender.

    The specification/receipt reference documents untrusted literal and array inputs, no pickle/callback execution, resource and output constraints, unsigned receipt integrity, and the exact-replay compatibility boundary. SECURITY and the assurance case distinguish these guarantees from authenticity, scientific suitability, and external compromise. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Specifications-and-Receipts.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Security-Assurance-Case.md


    Suficiente para um badge!

    O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software. (URL obrigatória) [documentation_quick_start]
    A ideia é mostrar aos usuários como começar e fazer o software fazer qualquer coisa. Isso é extremamente importante para que potenciais usuários comecem.

    The README provides source installation, a bounded normal draw, observable array shape, and a complete save/verify/replay workflow. It explicitly distinguishes the repository 2.0 API from historical 0.1 PyPI releases. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md


    Suficiente para um badge!

    O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume. [documentation_current]
    A documentação PODE incluir informações sobre diferenças ou mudanças entre versões do software e/ou link para versões antigas da documentação. A intenção deste critério é que um esforço seja feito para manter a documentação consistente, não que a documentação deva ser perfeita.

    Canonical prose is maintained against the current API and version; generated installed mirrors and catalogs are checked for drift. Built-wheel documentation examples, portable links/fragments, version metadata, site build, and browser checks run in CI. This is evidence of an ongoing consistency effort, not a claim that documentation can contain no future defect. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Documentation-System.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/tests/package/test_documentation.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/scripts/build_catalog.py https://github.com/autonomio/chances/actions/runs/36921324501


    Suficiente para um badge!

    A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada. (URL obrigatória) [documentation_achievements]
    Uma conquista é qualquer conjunto de critérios externos que o projeto trabalhou especificamente para atender, incluindo alguns selos. Esta informação não precisa estar na página inicial do site do projeto. Um projeto usando o GitHub pode colocar conquistas na página inicial do repositório adicionando-as ao arquivo README.

    The repository README hyperlinks the earned Best Practices entry and live Scorecard evidence. The Passing achievement was added in PR 36 on the same day it was earned, within 48 hours; no Silver award is advertised. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/pull/36 https://www.bestpractices.dev/en/projects/15137


  • Acessibilidade e internacionalização


    Suficiente para um badge!

    O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo. [accessibility_best_practices]
    Para aplicações web, veja as Diretrizes de Acessibilidade para Conteúdo Web (WCAG 2.0) e seu documento de apoio Understanding WCAG 2.0; veja também informações de acessibilidade do W3C. Para aplicações GUI, considere usar as diretrizes de acessibilidade específicas do ambiente (como Gnome, KDE, XFCE, Android, iOS, Mac e Windows). Algumas aplicações TUI (por exemplo, programas `ncurses`) podem fazer certas coisas para se tornarem mais acessíveis (como a configuração `force-arrow-cursor` do `alpine`). A maioria das aplicações de linha de comando são bastante acessíveis como estão. Este critério é frequentemente N/A, por exemplo, para bibliotecas de programas. Aqui estão alguns exemplos de ações a tomar ou questões a considerar:
    • Forneça alternativas de texto para qualquer conteúdo não textual para que possa ser transformado em outras formas que as pessoas precisam, como letras grandes, braille, fala, símbolos ou linguagem mais simples (diretriz WCAG 2.0 1.1)
    • A cor não é usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. (diretriz WCAG 2.0 1.4.1)
    • A apresentação visual de texto e imagens de texto tem uma razão de contraste de pelo menos 4.5:1, exceto para texto grande, texto incidental e logotipos (diretriz WCAG 2.0 1.4.3)
    • Torne toda a funcionalidade disponível a partir de um teclado (diretriz WCAG 2.1)
    • Um projeto GUI ou baseado na web DEVERIA testar com pelo menos um leitor de tela nas plataformas de destino (por exemplo, NVDA, Jaws ou WindowEyes no Windows; VoiceOver no Mac & iOS; Orca no Linux/BSD; TalkBack no Android). Programas TUI PODEM trabalhar para reduzir o redesenho para evitar leitura redundante por leitores de tela.

    The library and JSON CLI expose text-based interfaces. Documentation checks exercise keyboard navigation, skip links, light/dark themes, desktop/mobile layouts, and Axe WCAG 2 A/AA checks across representative page roles; images have text alternatives. The recorded CI passed these checks. Automated accessibility checks are not claimed to establish universal accessibility or a completed human screen-reader audit. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/tests/docs.spec.js https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/actions/runs/36921324501


    Mal suficiente para um badge.

    O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A). [internationalization]
    Localização "refere-se à adaptação de um produto, aplicação ou conteúdo de documento para atender aos requisitos de idioma, cultura e outros de um mercado-alvo específico (um locale)". Internacionalização é o "projeto e desenvolvimento de um produto, aplicação ou conteúdo de documento que permite fácil localização para públicos-alvo que variam em cultura, região ou idioma". (Veja "Localization vs. Internationalization" do W3C.) O software atende a este critério simplesmente sendo internacionalizado. Nenhuma localização para outro idioma específico é necessária, pois uma vez que o software foi internacionalizado, é possível para outros trabalharem na localização.

    Human-facing error messages and maintained prose are English; the package has no message-localization framework. This SHOULD criterion has been considered: scientific protocol identifiers, structured error codes, and receipt formats currently prioritize one stable interchange contract, and maintenance remains focused on the documented English audience. Human-facing strings could be localized separately in future without changing those identifiers. Because the CLI does generate user-facing messages, N/A is not claimed. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_errors.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Command-Line.md


  • Outro


    Suficiente para um badge!

    Se os sites do projeto (site, repositório e URLs de download) armazenam senhas para autenticação de usuários externos, as senhas DEVEM ser armazenadas como hashes iterados com um salt por usuário usando um algoritmo de extensão de chave (iterado) (por exemplo, Argon2id, Bcrypt, Scrypt ou PBKDF2). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A). [sites_password_security]
    Observe que o uso do GitHub atende a este critério. Este critério aplica-se apenas a senhas usadas para autenticação de usuários externos nos sites do projeto (também conhecida como autenticação de entrada). Se os sites do projeto precisam fazer login em outros sites (também conhecida como autenticação de saída), eles podem precisar armazenar tokens de autorização para esse propósito de forma diferente (já que armazenar um hash seria inútil). Isso aplica o critério crypto_password_storage aos sites do projeto, semelhante a sites_https.

    The repository and project communication use GitHub, which the official Silver criterion details explicitly accept. Chances operates no custom user-password database or authentication website; the documentation output is static. Package distribution uses PyPI rather than a project-operated login system. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/product-docs.json https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances https://pypi.org/project/chances/ https://www.bestpractices.dev/en/criteria/1?details=true


 Controle de Mudanças 1/1 ●

 Relatórios 2/3 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE usar um rastreador de questões para rastrear questões individuais. [report_tracker]

    Users submit defects through the public GitHub issue tracker; the README requests a minimal protocol, package versions, and structured error. Public issue templates support bug and enhancement reports. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md https://github.com/autonomio/chances/issues/new/choose


  • Processo de relato de vulnerabilidades


    Informações obrigatórias desconhecidas, insuficiente para um badge.

    O projeto DEVE dar crédito ao(s) relator(es) de todos os relatórios de vulnerabilidade resolvidos nos últimos 12 meses, exceto para o(s) relator(es) que solicitarem anonimato. Se não houve vulnerabilidades resolvidas nos últimos 12 meses, selecione "não aplicável" (N/A). (URL obrigatória) [vulnerability_report_credit]

    Unresolved maintainer fact: between 2025-10-02 and 2026-10-02, were any vulnerability reports resolved, including private reports? If none, N/A is justified; otherwise provide the public fix/release/advisory URLs crediting each reporter who did not request anonymity. SECURITY promises credit, but a future policy and an empty public advisory list do not establish the handling of private historical reports. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/security/advisories


    Suficiente para um badge!

    O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades. (URL obrigatória) [vulnerability_response_process]
    Isso está fortemente relacionado a vulnerability_report_process, que exige que haja uma forma documentada de relatar vulnerabilidades. Também está relacionado a vulnerability_report_response, que exige resposta a relatos de vulnerabilidades dentro de um determinado prazo.

    SECURITY documents private reporting, acknowledgement target, reproduction, impact/version triage, reporter coordination, prioritized critical fixes, disclosure, public fix notes, and reporter credit. These documented response steps are separate from historical response-time attestations. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md


 Qualidade 17/19 ●

 Segurança 12/13 ●

 Análise 2/2 ●

  • Análise estática de código


    Suficiente para um badge!

    O projeto DEVE usar pelo menos uma ferramenta de análise estática com regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. [static_analysis_common_vulnerabilities]
    Ferramentas de análise estática que são especificamente projetadas para procurar vulnerabilidades comuns são mais propensas a encontrá-las. Dito isso, usar quaisquer ferramentas estáticas normalmente ajudará a encontrar alguns problemas, então estamos sugerindo mas não exigindo isso para o nível de selo 'passing'.

    CodeQL Python analysis runs on master pushes, pull requests, and a weekly schedule. The proposed Chances 2.0 major release has passed this analysis before publication; the PR required the CodeQL status. Public ruleset and typing analysis provide additional static checks. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/.github/workflows/pr_checks_codeql.yml https://github.com/autonomio/chances/actions/runs/36887139299


  • Análise dinâmica de código


    Suficiente para um badge!

    Se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) DEVE ser rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). [dynamic_analysis_unsafe]
    Exemplos de mecanismos para detectar problemas de segurança de memória incluem Address Sanitizer (ASAN) (disponível no GCC e LLVM), Memory Sanitizer e valgrind. Outras ferramentas potencialmente usadas incluem thread sanitizer e undefined behavior sanitizer. Assertivas generalizadas também funcionariam.

    The project-authored product code is Python, with JavaScript used by documentation tooling; the project does not produce C or C++ source. NumPy/SciPy and platform native publication APIs are external dependencies, not project-authored memory-unsafe-language source. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/pyproject.toml https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/_publication.py



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/15137/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:58:41 UTC, última atualização em 2026-10-03 08:29:52 UTC. Selo de aprovação alcançado pela última vez em 2026-10-01 16:42:28 UTC.