Talos

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

 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]

    Public GitHub tracker exists.

    https://github.com/autonomio/talos/issues


  • Processo de relato de vulnerabilidades


    Suficiente 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]

    The maintainer confirms compliance with crediting reporters of vulnerability reports resolved during the preceding12months, except those requesting anonymity. No report count, individual report, private narrative or response timestamp is invented. If a separately confirmed zero-resolution denominator is supplied, the official N/A option can instead be used.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md
    https://www.bestpractices.dev/en/criteria/1?details=true#vulnerability_report_credit


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

    Reporting routes and reporter-credit policy exist, but a complete documented acknowledgement, triage, remediation, coordinated disclosure and closure process is absent from the merged source. Root prepares that process on the next branch; historic compliance remains a separate fact.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


 Qualidade 12/19 ●

 Segurança 4/13 ●

  • Conhecimento de desenvolvimento seguro


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

    O projeto DEVE implementar princípios de projeto seguro (de "know_secure_design"), quando aplicável. Se o projeto não está produzindo software, selecione "não aplicável" (N/A). [implement_secure_design]
    Por exemplo, os resultados do projeto devem ter 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). Eles também devem ter mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável). Note que em alguns casos os princípios entrarão em conflito, caso em que uma escolha deve ser feita (por exemplo, muitos mecanismos podem tornar as coisas mais complexas, contrariando a "economia de mecanismo" / mantenha simples).

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

    Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM 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.

    SHA-256 artifact/source checks; no SHA1/MD5 security mechanism identified in Talos runtime.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/provenance.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/backends/adapters.py


    Mal suficiente para um badge.

    O projeto DEVERIA suportar múltiplos algoritmos criptográficos, para que os usuários possam mudar rapidamente se um for quebrado. Algoritmos de chave simétrica comuns incluem AES, Twofish e Serpent. Alternativas comuns de algoritmos de hash criptográfico incluem SHA-2 (incluindo SHA-224, SHA-256, SHA-384 E SHA-512) e SHA-3. [crypto_algorithm_agility]

    Manifest identifiers intentionally schema-coupled to SHA256; no selectable hash agility. Delegated SSH/TLS algorithms negotiate externally. SHOULD may be unmet with provenance-schema migration explanation; do not change manifest identity merely for badge.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/serialization.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py


    Insuficiente para um badge.

    O projeto DEVE suportar o armazenamento de credenciais de autenticação (como senhas e tokens dinâmicos) e chaves criptográficas privadas em arquivos que são separados de outras informações (como arquivos de configuração, bancos de dados e logs), e permitir que os usuários as atualizem e substituam sem recompilação de código. Se o projeto nunca processar credenciais de autenticação e chaves criptográficas privadas, selecione "não aplicável" (N/A). [crypto_credential_agility]

    Executing the current ambience sampler reaches a dependency-owned embedded RANDOM.ORG API credential without a caller credential-file or environment configuration argument. A local replacement reads caller-owned private API key files on every request and verifies rotation without changing source; it remains unmerged. Git credential rotation alone does not clear the sampler finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py


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

    O software produzido pelo projeto DEVERIA suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVERIAM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (N/A). [crypto_used_network]

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

    O software produzido pelo projeto DEVERIA, se suportar ou usar TLS, suportar pelo menos a versão TLS 1.2. Observe que o predecessor do TLS era chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_tls12]

    Insuficiente para um badge.

    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado TLS por padrão ao usar TLS, incluindo em sub-recursos. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_certificate_verification]
    Observe que a verificação incorreta de certificado TLS é um erro comum. Para mais informações, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. e "Do you trust this application?" por Michael Catanzaro.

    Executing the current quantum sampler through its distributed Chances0.1.9 dependency reaches urlopen with CERT_NONE and check_hostname=False. A verified stdlib replacement with TLS1.2+, chain/hostname checks and redirect refusal is implemented locally and tested against real loopback TLS servers; it remains unmerged. Other standard dataset/Git transports do not clear this positive finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml


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

    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado antes de enviar cabeçalhos HTTP com informações privadas (como cookies seguros). Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_verification_private]

  • Lançamento seguro


    Insuficiente para um badge.

    O projeto DEVE assinar criptograficamente os lançamentos dos resultados do projeto destinados ao uso generalizado, e DEVE haver um processo documentado explicando aos usuários como eles podem obter as chaves públicas de assinatura e verificar a(s) assinatura(s). A chave privada para essa(s) assinatura(s) NÃO DEVE estar em site(s) usado(s) para distribuir diretamente o software ao público. Se os lançamentos não forem destinados ao uso generalizado, selecione "não aplicável" (N/A). [signed_releases]
    Os resultados do projeto incluem tanto o código-fonte quanto quaisquer entregáveis gerados quando aplicável (por exemplo, executáveis, pacotes e contêineres). Os entregáveis gerados PODEM ser assinados separadamente do código-fonte. Estes PODEM ser implementados como tags git assinadas (usando assinaturas digitais criptográficas). Os projetos PODEM fornecer resultados gerados separadamente de ferramentas como git, mas nesses casos, os resultados separados DEVEM ser assinados separadamente.

    Latest published v1.4 remains unproven as signed. Merged deploy workflow supports signed provenance on a future authorized wheel/sdist publication. The next branch adds release assets and Sigstore bundles, but workflow code or a local build cannot establish an actual signed release. Await reviewed release execution and consumer verification; do not rewrite old tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/deploy.yml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/docs/Developer/Release-Policy.md
    https://github.com/autonomio/talos/releases/tag/v1.4


    Mal suficiente para um badge.

    É SUGERIDO que no sistema de controle de versão, cada tag de versão importante (uma tag que faz parte de um lançamento principal, lançamento menor ou corrige vulnerabilidades publicamente observadas) seja criptograficamente assinada e verificável conforme descrito em signed_releases. [version_tags_signed]

    Current release script creates ordinary tags; latest v1.4 ref is commit object, no signed tag. SUGGESTED can be unmet; do not rewrite historical tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/scripts/create_release.py


  • Outras questões de segurança


    Insuficiente para um badge.

    Os resultados do projeto DEVEM verificar todas as entradas de fontes potencialmente não confiáveis para garantir que sejam válidas (uma *lista de permissões*), e rejeitar entradas inválidas, se houver quaisquer restrições sobre os dados. [input_validation]
    Observe que comparar a entrada com uma lista de "formatos inválidos" (também conhecida como *lista de negação*) normalmente não é suficiente, porque os atacantes muitas vezes podem contornar uma lista de negação. Em particular, os números são convertidos em formatos internos e então verificados se estão entre o mínimo e o máximo (inclusive), e as strings de texto são verificadas para garantir que sejam padrões de texto válidos (por exemplo, UTF-8 válido, comprimento, sintaxe, etc.). Alguns dados podem precisar ser "qualquer coisa" (por exemplo, um carregador de arquivos), mas estes normalmente seriam raros.

    Current-source probes reproduce committed-manifest content tampering accepted under an unchanged lineage ID, objective direction sideways accepted, and string false accepted for boolean policy controls. Local regressions reject all of these before caller imports/source hydration, while preserving draft/historical identities; fixes remain unmerged and other constrained-input boundaries still require review.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/validator.py


    Suficiente para um badge!

    Mecanismos de proteção DEVERIAM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. [hardening]
    Os mecanismos de proteção podem incluir cabeçalhos HTTP como Content Security Policy (CSP), flags de compilador para mitigar ataques (como -fstack-protector), ou flags de compilador para eliminar comportamento indefinido. Para nossos propósitos, o privilégio mínimo não é considerado um mecanismo de proteção (privilégio mínimo é importante, mas separado).

    Project produces interpreted local library/CLI, no account-serving runtime or native build. Describe memory-safe language/delegated platform hardening where applicable; least-privilege CI alone is explicitly not this hardening criterion.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


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

    O projeto DEVE fornecer um caso de garantia que justifique por que seus requisitos de segurança são atendidos. O caso de garantia DEVE incluir: uma descrição do modelo de ameaças, identificação clara dos limites de confiança, um argumento de que os princípios de projeto seguro foram aplicados e um argumento de que fraquezas comuns de segurança na implementação foram combatidas. (URL obrigatória) [assurance_case]
    Um caso de garantia é "um corpo documentado de evidências que fornece um argumento convincente e válido de que um conjunto específico de reivindicações críticas sobre as propriedades de um sistema são adequadamente justificadas para uma dada aplicação em um dado ambiente" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Limites de confiança são fronteiras onde os dados ou a execução muda seu nível de confiança, por exemplo, os limites de um servidor em uma aplicação web típica. É comum listar princípios de projeto seguro (como Saltzer e Schroeer) e fraquezas comuns de segurança na implementação (como o OWASP top 10 ou CWE/SANS top 25), e mostrar como cada um é combatido. O caso de garantia do BadgeApp pode ser um exemplo útil. Isso está relacionado a documentation_security, documentation_architecture e implement_secure_design.

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

    Master CodeQL run36893895563 succeeded. The Python security analysis workflow is actually merged and executing.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/pr_checks_codeql.yml
    https://github.com/autonomio/talos/actions/runs/36893895563


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

    No project-produced code in memory-unsafe language; native framework dependencies monitored separately.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml



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/15140/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 16:30:01 UTC, última atualização em 2026-10-01 19:11:47 UTC.