Astetik

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

 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 public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    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]

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    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).

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    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.

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


  • 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).

    Released results have unique tag/version identities and source commit IDs. Latest published historical release is v1.16; current protected source version 2.0.0 is explicitly unpublished. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/pyproject.toml https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    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).

    The currently maintained source follows three-component SemVer with a mandatory per-PR bump gate. Historical PyPI versions such as 1.16 followed Python version syntax and were not strict three-component SemVer. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Semantic-Versioning.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/governance/version_gate.py


    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]

    Released historical versions have Git tags, and the configured release process derives a unique v<project.version> tag for future explicitly authorized releases. Evidence: https://github.com/autonomio/astetik/tags https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Making-Release.md


  • 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.

    Latest distributed release v1.16 has human-readable notes identifying Hatch migration and minor fixes. Current 2.0 source has a reviewed human-readable changelog; future notes are generated from that reviewed section rather than raw git logs. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/CHANGELOG.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    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.

    No publicly known Astetik runtime vulnerability with a CVE or comparable advisory was found in GitHub advisories or the OSV PyPI package query. The criterion concerns project vulnerabilities, not transitive dependencies. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


 Relatórios 8/8 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE fornecer um processo para os usuários enviarem relatórios de bugs (por exemplo, usando um rastreador de problemas ou uma lista de discussão). (URL obrigatória) [report_process]

    SUPPORT and issue templates describe how to submit a versioned reproducible report using the public GitHub issue tracker. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SUPPORT.md https://github.com/autonomio/astetik/issues


    Suficiente para um badge!

    O projeto DEVERIA usar um rastreador de problemas para rastrear problemas individuais. [report_tracker]

    Live GitHub repository metadata has has_issues=true; issues are the documented bug and contribution tracker. Evidence: https://api.github.com/repos/autonomio/astetik https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SUPPORT.md


    Suficiente para um badge!

    O projeto DEVE reconhecer a maioria dos relatórios de bugs enviados nos últimos 2-12 meses (inclusive); a resposta não precisa incluir uma correção. [report_responses]

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    Suficiente para um badge!

    O projeto DEVERIA responder a uma maioria (>50%) das solicitações de melhorias nos últimos 2-12 meses (inclusive). [enhancement_responses]
    A resposta PODE ser 'não' ou uma discussão sobre seus méritos. O objetivo é simplesmente que haja alguma resposta a algumas solicitações, o que indica que o projeto ainda está ativo. Para fins deste critério, os projetos não precisam contar solicitações falsas (por exemplo, de spammers ou sistemas automatizados). Se um projeto não estiver mais fazendo melhorias, selecione "não atendido" e inclua a URL que torna esta situação clara para os usuários. Se um projeto tende a ser sobrecarregado pelo número de solicitações de melhorias, selecione "não atendido" e explique.

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    Suficiente para um badge!

    O projeto DEVE ter um arquivo publicamente disponível para relatórios e respostas para pesquisa posterior. (URL obrigatória) [report_archive]

    GitHub issue and PR discussions are public, searchable, URL-addressable, and accessible through a browser without installing proprietary client software. Evidence: https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/pulls


  • Processo de relato de vulnerabilidades


    Suficiente para um badge!

    O projeto DEVE publicar o processo para relatar vulnerabilidades no site do projeto. (URL obrigatória) [vulnerability_report_process]
    Projetos hospedados no GitHub DEVERIAM considerar habilitar o relato privado de uma vulnerabilidade de segurança. Projetos no GitLab DEVERIAM considerar usar sua capacidade de relatar uma vulnerabilidade de forma privada. Projetos PODEM identificar um endereço de e-mail em https://PROJECTSITE/security, frequentemente na forma security@example.org. Este processo de relato de vulnerabilidades PODE ser o mesmo que seu processo de relato de bugs. Relatórios de vulnerabilidades PODEM ser sempre públicos, mas muitos projetos têm um mecanismo de relato de vulnerabilidades privado.

    SECURITY documents how to report vulnerabilities privately by arranging a channel through the established author contact, warns against public exploitable details, and defines useful report contents. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SECURITY.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md


    Suficiente para um badge!

    Se relatórios privados de vulnerabilidades forem suportados, o projeto DEVE incluir como enviar as informações de uma forma que seja mantida privada. (URL obrigatória) [vulnerability_report_private]
    Exemplos incluem um relatório de defeito privado enviado na web usando HTTPS (TLS) ou um e-mail criptografado usando OpenPGP. Se relatórios de vulnerabilidades forem sempre públicos (portanto, nunca há relatórios privados de vulnerabilidades), escolha "não aplicável" (N/A).

    GitHub private vulnerability reporting is enabled for Astetik. Reports are submitted privately over GitHub HTTPS at https://github.com/autonomio/astetik/security/advisories/new . Live repository setting verified 2026-10-02; reporters should not publish exploitable details in public issues. Evidence: https://github.com/autonomio/astetik/security/advisories/new https://github.com/autonomio/astetik/security/policy


    Suficiente para um badge!

    O tempo de resposta inicial do projeto para qualquer relatório de vulnerabilidade recebido nos últimos 6 meses DEVE ser menor ou igual a 14 dias. [vulnerability_report_response]
    Se não houve vulnerabilidades relatadas nos últimos 6 meses, escolha "não aplicável" (N/A).

    The primary maintainer confirms no private vulnerability reports were received in the past 12 months as of 2026-10-02. No public Astetik vulnerability report or advisory was found in the last six months. Thus there is no initial-response interval to claim; the official criterion permits N/A when no vulnerabilities were reported in that period. Evidence: https://github.com/autonomio/astetik/security/advisories


 Qualidade 13/13 ●

 Segurança 16/16 ●

  • Conhecimento de desenvolvimento seguro


    Suficiente para um badge!

    O projeto DEVE ter pelo menos um desenvolvedor principal que saiba como projetar software seguro. (Veja 'details' para os requisitos exatos.) [know_secure_design]
    Isto requer entender os seguintes princípios de projeto, incluindo os 8 princípios de Saltzer and Schroeder:
    • economia de mecanismo (mantenha o projeto tão simples e pequeno quanto prático, por exemplo, adotando simplificações amplas)
    • padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão)
    • mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável)
    • projeto aberto (mecanismos de segurança não devem depender da ignorância do invasor sobre seu projeto, mas sim em informações mais facilmente protegidas e alteradas como chaves e senhas)
    • separação de privilégios (idealmente, acesso a objetos importantes deve depender de mais de uma condição, de forma que derrotar um sistema de proteção não permita acesso completo. Por exemplo, autenticação multifator, como exigir tanto uma senha quanto um token de hardware, é mais forte que autenticação de fator único)
    • menor privilégio (processos devem operar com o menor privilégio necessário)
    • menor mecanismo comum (o projeto deve minimizar os mecanismos comuns a mais de um usuário e dos quais todos os usuários dependem, por exemplo, diretórios para arquivos temporários)
    • aceitabilidade psicológica (a interface humana deve ser projetada para facilidade de uso - projetar para "menor surpresa" pode ajudar)
    • superfície de ataque limitada (a superfície de ataque - o conjunto dos diferentes pontos onde um invasor pode tentar entrar ou extrair dados - deve ser limitada)
    • validação de entrada com listas de permissões (entradas devem tipicamente ser verificadas para determinar se são válidas antes de serem aceitas; esta validação deve usar listas de permissões (que aceitam apenas valores conhecidamente bons), não listas de negação (que tentam listar valores conhecidamente ruins)).
    Um "desenvolvedor principal" em um projeto é qualquer pessoa que esteja familiarizada com a base de código do projeto, esteja confortável fazendo mudanças nela, e seja reconhecida como tal pela maioria dos outros participantes no projeto. Um desenvolvedor principal tipicamente faria várias contribuições ao longo do último ano (via código, documentação ou respondendo perguntas). Desenvolvedores seriam tipicamente considerados desenvolvedores principais se iniciaram o projeto (e não deixaram o projeto há mais de três anos), têm a opção de receber informações em um canal privado de relato de vulnerabilidades (se houver um), podem aceitar commits em nome do projeto, ou realizar lançamentos finais do software do projeto. Se há apenas um desenvolvedor, esse indivíduo é o desenvolvedor principal. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir projeto. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o material).

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms understanding all specified secure-design principles: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability, limited attack surface, and allowlist input validation. Confirmation given 2026-10-02; implementation controls are documented in the assurance case. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    Suficiente para um badge!

    Pelo menos um dos desenvolvedores principais do projeto DEVE conhecer tipos comuns de erros que levam a vulnerabilidades neste tipo de software, bem como pelo menos um método para combater ou mitigar cada um deles. [know_common_errors]
    Exemplos (dependendo do tipo de software) incluem injeção SQL, injeção de SO, estouro clássico de buffer, cross-site scripting, autenticação ausente e autorização ausente. Veja o CWE/SANS top 25 ou OWASP Top 10 para listas comumente usadas. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir erros comuns de implementação que levam a vulnerabilidades. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o material).

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms knowing common vulnerability classes relevant to this library and at least one mitigation for each, including injection, unsafe deserialization, path traversal, missing authorization, secret leakage, and vulnerable dependencies. Confirmation given 2026-10-02; the assurance case records the project trust boundaries and relevant controls. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • Usar práticas criptográficas boas e básicas

    Observe que alguns softwares não precisam usar mecanismos criptográficos. Se o seu projeto produzir software que (1) inclui, ativa ou habilita funcionalidade de criptografia, e (2) pode ser liberado dos Estados Unidos (EUA) para fora dos EUA ou para um não cidadão dos EUA, você pode ser legalmente obrigado a tomar algumas etapas extras. Normalmente isso envolve apenas o envio de um e-mail. Para mais informações, consulte a seção de criptografia de Understanding Open Source Technology & US Export Controls.

    Suficiente para um badge!

    O software produzido pelo projeto DEVE usar, por padrão, apenas protocolos criptográficos e algoritmos que são publicamente publicados e revisados por especialistas (se protocolos criptográficos e algoritmos forem usados). [crypto_published]
    Esses critérios criptográficos nem sempre se aplicam porque alguns softwares não têm necessidade de usar diretamente capacidades criptográficas.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Suficiente para um badge!

    Se o software produzido pelo projeto for uma aplicação ou biblioteca, e seu propósito principal não for implementar criptografia, então ele DEVERIA apenas chamar software especificamente projetado para implementar funções criptográficas; ele NÃO DEVERIA reimplementar o seu próprio. [crypto_call]

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Suficiente para um badge!

    Toda funcionalidade no software produzido pelo projeto que depende de criptografia DEVE ser implementável usando FLOSS. [crypto_floss]
    Veja o Open Standards Requirement for Software by the Open Source Initiative.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Suficiente para um badge!

    Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM usar comprimentos de chave padrão que pelo menos atendam aos requisitos mínimos do NIST até o ano de 2030 (conforme declarado em 2012). DEVE ser possível configurar o software para que comprimentos de chave menores sejam completamente desabilitados. [crypto_keylength]
    Esses comprimentos mínimos de bits são: chave simétrica 112, módulo de fatoração 2048, chave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 e hash 224 (hashing de senha não é coberto por este comprimento de bits, mais informações sobre hashing de senha podem ser encontradas no critério crypto_password_storage). Veja https://www.keylength.com para uma comparação de recomendações de comprimento de chave de várias organizações. O software PODE permitir comprimentos de chave menores em algumas configurações (idealmente não permitiria, já que isso permite ataques de downgrade, mas comprimentos de chave mais curtos são às vezes necessários para interoperabilidade).

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Suficiente para um badge!

    Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos quebrados (por exemplo, MD4, MD5, DES único, RC4, Dual_EC_DRBG), ou usar modos de cifra que são inadequados ao contexto, a menos que sejam necessários para implementar um protocolo interoperável (onde o protocolo implementado é a versão mais recente desse padrão amplamente suportado pelo ecossistema de rede, esse ecossistema requer o uso de tal algoritmo ou modo, e esse ecossistema não oferece nenhuma alternativa mais segura). A documentação DEVE descrever quaisquer riscos de segurança relevantes e quaisquer mitigações conhecidas se esses algoritmos ou modos quebrados forem necessários para um protocolo interoperável. [crypto_working]
    O modo ECB é quase nunca apropriado porque revela blocos idênticos dentro do texto cifrado conforme demonstrado pelo pinguim ECB, e o modo CTR é frequentemente inadequado porque não realiza autenticação e causa duplicatas se o estado de entrada for repetido. Em muitos casos é melhor escolher um modo de algoritmo de cifra de bloco projetado para combinar sigilo e autenticação, por exemplo, Galois/Counter Mode (GCM) e EAX. Projetos PODEM permitir que usuários habilitem mecanismos quebrados (por exemplo, durante a configuração) onde necessário para compatibilidade, mas então os usuários sabem que estão fazendo isso.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Suficiente para um badge!

    Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVERIAM depender de algoritmos criptográficos ou modos com fraquezas sérias conhecidas (por exemplo, o algoritmo de hash criptográfico SHA-1 ou o modo CBC em SSH). [crypto_weaknesses]
    Preocupações sobre o modo CBC em SSH são discutidas em CERT: SSH CBC vulnerability.

    Project integrity digests use hashlib.sha256. No MD5/SHA1 security mechanism or home-grown cipher was found in runtime. Repository delivery uses platform HTTPS/signing primitives. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_json.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_source_file.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_result.py


    Suficiente para um badge!

    Os mecanismos de segurança dentro do software produzido pelo projeto DEVERIAM implementar sigilo perfeito para frente para protocolos de acordo de chave, de modo que uma chave de sessão derivada de um conjunto de chaves de longo prazo não possa ser comprometida se uma das chaves de longo prazo for comprometida no futuro. [crypto_pfs]

    The installed local scientific library does not implement a network key-agreement protocol or session encryption. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Overview/Boundary.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    Suficiente para um badge!

    Se o software produzido pelo projeto causar o armazenamento de 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). Veja também OWASP Password Storage Cheat Sheet. [crypto_password_storage]
    Este critério aplica-se apenas quando o software está aplicando autenticação de usuários usando senhas para usuários externos (também conhecida como autenticação de entrada), como aplicações web do lado do servidor. Não se aplica em casos onde o software armazena senhas para autenticar em outros sistemas (também conhecida como autenticação de saída, por exemplo, o software implementa um cliente para algum outro sistema), já que pelo menos partes desse software devem ter acesso frequentemente à senha não hasheada.

    The installed local scientific library does not authenticate external users or store authentication passwords. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    Suficiente para um badge!

    Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM gerar todas as chaves criptográficas e nonces usando um gerador de números aleatórios criptograficamente seguro, e NÃO DEVEM fazê-lo usando geradores que são criptograficamente inseguros. [crypto_random]
    Um gerador de números aleatórios criptograficamente seguro pode ser um gerador de números aleatórios de hardware, ou pode ser um gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG) usando um algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Exemplos de chamadas para geradores de números aleatórios seguros incluem o java.security.SecureRandom do Java e o window.crypto.getRandomValues do JavaScript. Exemplos de chamadas para geradores de números aleatórios inseguros incluem o java.util.Random do Java e o Math.random do JavaScript.

    Astetik does not generate cryptographic keys or nonces. Scientific determinism/content identities are SHA-256 hashes, not randomly generated secrets. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • Entrega protegida contra ataques man-in-the-middle (MITM)


    Suficiente para um badge!

    O projeto DEVE usar um mecanismo de entrega que contraponha ataques MITM. Usar https ou ssh+scp é aceitável. [delivery_mitm]
    Um mecanismo ainda mais forte é liberar o software com pacotes assinados digitalmente, já que isso mitiga ataques no sistema de distribuição, mas isso só funciona se os usuários puderem estar confiantes de que as chaves públicas para assinaturas estão corretas e se os usuários realmente verificarão a assinatura.

    The public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    Suficiente para um badge!

    Um hash criptográfico (por exemplo, um sha1sum) NÃO DEVE ser recuperado por http e usado sem verificar uma assinatura criptográfica. [delivery_unsigned]
    Esses hashes podem ser modificados durante o trânsito.

    The public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


  • Vulnerabilidades conhecidas publicamente corrigidas


    Suficiente para um badge!

    NÃO DEVE haver vulnerabilidades não corrigidas de severidade média ou superior que sejam publicamente conhecidas por mais de 60 dias. [vulnerabilities_fixed_60_days]
    A vulnerabilidade deve ser corrigida e lançada pelo próprio projeto (as correções podem ser desenvolvidas em outro lugar). Uma vulnerabilidade se torna publicamente conhecida (para este propósito) uma vez que tem um CVE com informações lançadas publicamente sem paywall (relatadas, por exemplo, no National Vulnerability Database) ou quando o projeto foi informado e a informação foi liberada ao público (possivelmente pelo projeto). Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente usado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade eles mesmos usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem publicamente reveladas uma vez que a vulnerabilidade seja publicamente conhecida. Nota: isso significa que os usuários podem ficar vulneráveis a todos os atacantes em todo o mundo por até 60 dias. Este critério é frequentemente muito mais fácil de atender do que o que o Google recomenda em Rebooting responsible disclosure, porque o Google recomenda que o período de 60 dias comece quando o projeto é notificado mesmo se o relatório não for público. Observe também que este critério de selo, como outros critérios, aplica-se ao projeto individual. Alguns projetos fazem parte de organizações guarda-chuva maiores ou projetos maiores, possivelmente em múltiplas camadas, e muitos projetos alimentam seus resultados para outras organizações e projetos como parte de uma cadeia de suprimentos potencialmente complexa. Um projeto individual geralmente não pode controlar o resto, mas um projeto individual pode trabalhar para lançar uma correção de vulnerabilidade de forma oportuna. Portanto, focamos apenas no tempo de resposta do projeto individual. Uma vez que uma correção esteja disponível do projeto individual, outros podem determinar como lidar com a correção (por exemplo, eles podem atualizar para a versão mais recente ou podem aplicar apenas a correção como uma solução cherry-picked).

    No publicly known medium-or-higher Astetik runtime vulnerability was found in GitHub advisories or the OSV package database. Live Scorecard configuration findings are separately tracked and do not establish exploitable project vulnerabilities older than 60 days. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query https://github.com/autonomio/astetik/security/code-scanning


    Suficiente para um badge!

    Os projetos DEVERIAM corrigir todas as vulnerabilidades críticas rapidamente após serem relatadas. [vulnerabilities_critical_fixed]

    No confirmed critical Astetik vulnerability is currently known from the public advisory/OSV audit, and the primary maintainer confirms no private vulnerability reports in the past 12 months. There is no outstanding confirmed critical vulnerability or historical fix interval to misrepresent. Critical reports are prioritized for immediate triage and prompt remediation; this answer does not invent a past response-time result. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


  • Outras questões de segurança


    Suficiente para um badge!

    Os repositórios públicos NÃO DEVEM vazar uma credencial privada válida (por exemplo, uma senha funcionando ou chave privada) que se destina a limitar o acesso público. [no_leaked_credentials]
    Um projeto PODE vazar credenciais "de amostra" para testes e bancos de dados sem importância, desde que não sejam destinadas a limitar o acesso público.

    GitHub secret-scanning alert 1 is resolved as false_positive after independent analysis: the detected bytes span adjacent WB_A3 country-code and WOE_ID geographic-ID fields in countries.dbf record 184 (North Korea), matching public Natural Earth v4.0.0 attributes. The matched value is geographical metadata, not a credential. No valid private credential is identified in the public repository audit. Evidence: https://github.com/autonomio/astetik/security/secret-scanning/1 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/extras/countries.dbf https://raw.githubusercontent.com/nvkelso/natural-earth-vector/v4.0.0/50m_cultural/ne_50m_admin_0_countries.dbf


 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/15154/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-02 06:55:56 UTC, última atualização em 2026-10-02 09:51:47 UTC. Selo de aprovação alcançado pela última vez em 2026-10-02 09:07:57 UTC.