letsgolang

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:

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/11658/badge)](https://www.bestpractices.dev/projects/11658)

ou incorporando isto no seu HTML:

<a href="https://www.bestpractices.dev/projects/11658"><img src="https://www.bestpractices.dev/projects/11658/badge"></a>

Estes são os critérios de nível

. Você também pode visualizar os critérios de nível

.

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

Análise 2/2 ●

Análise dinâmica de código

Criterion [dynamic_analysis]
Atendido

Não atendido

N/A

?

O projeto DEVE aplicar pelo menos uma ferramenta de análise dinâmica a qualquer lançamento de produção proposto do software produzido pelo projeto antes de seu lançamento. ^{[dynamic_analysis]}
Uma ferramenta de análise dinâmica examina o software executando-o com entradas específicas. Por exemplo, o projeto PODE usar uma ferramenta de fuzzing (por exemplo, American Fuzzy Lop) ou um scanner de aplicação web (por exemplo, OWASP ZAP ou w3af). Em alguns casos, o projeto OSS-Fuzz pode estar disposto a aplicar testes de fuzzing ao seu projeto. Para fins deste critério, a ferramenta de análise dinâmica precisa variar as entradas de alguma forma para procurar vários tipos de problemas ou ser um conjunto de testes automatizado com pelo menos 80% de cobertura de ramificação. A página da Wikipedia sobre análise dinâmica e a página da OWASP sobre fuzzing identificam algumas ferramentas de análise dinâmica. A(s) ferramenta(s) de análise PODEM estar focadas em procurar vulnerabilidades de segurança, mas isso não é obrigatório.

The project employs an automated test suite that performs dynamic analysis by executing the installer in a controlled environment. The test suite varies inputs, such as Go versions and installation paths, to ensure the script behaves correctly under different scenarios. Furthermore, the code is executed with strict shell options (set -euo pipefail) which acts as a runtime error-detection mechanism. The dynamic tests specifically verify the security logic within the get_temporary_asset function, ensuring that umask settings, directory permissions, and trap cleanups function as intended during execution.
Criterion [dynamic_analysis_enable_assertions]
Atendido

Não atendido

N/A

?

O projeto DEVERIA incluir muitas asserções em tempo de execução no software que produz e verificar essas asserções durante a análise dinâmica. ^{[dynamic_analysis_enable_assertions]}
Este critério não sugere habilitar asserções durante a produção; isso é inteiramente decisão do projeto e de seus usuários. O foco deste critério é, em vez disso, melhorar a detecção de falhas durante a análise dinâmica antes da implantação. Habilitar asserções no uso em produção é completamente diferente de habilitar asserções durante a análise dinâmica (como testes). Em alguns casos, habilitar asserções no uso em produção é extremamente imprudente (especialmente em componentes de alta integridade). Existem muitos argumentos contra habilitar asserções em produção, por exemplo, bibliotecas não devem travar chamadores, sua presença pode causar rejeição por lojas de aplicativos e/ou ativar uma asserção em produção pode expor dados privados, como chaves privadas. Observe que em muitas distribuições Linux NDEBUG não é definido, então assert() em C/C++ será habilitado por padrão para produção nesses ambientes. Pode ser importante usar um mecanismo de asserção diferente ou definir NDEBUG para produção nesses ambientes.
The project follows a fail-fast design philosophy, which incorporates a variety of runtime assertions to catch issues early during dynamic analysis and testing. These assertions are primarily aimed at validating conditions before the code proceeds to the next steps, ensuring that any violations are caught as soon as possible during development, without reaching production.

Key Mechanisms in Testing:
1. Strict Execution Mode: The script uses set -euo pipefail, which enforces a fail-fast mechanism, acting as a global assertion during testing. This ensures that the script immediately exits if a command fails or if an undefined variable is accessed, effectively preventing further erroneous execution.
2. Explicit State Assertions: Critical functions, such as get_temporary_asset, include manual assertions to verify assumptions about the environment. For instance, the script checks if umask was set correctly and ensures that file permissions match the expected security profile (700 or 600).
3. Defensive Validation: Internal parameters and conditions are validated using assertions. For example, the script checks if the correct number of arguments is passed (if $# -ne 1) and provides descriptive error messages to help developers catch issues early during testing.
These assertions help the project to detect potential faults dynamically during test executions, and while they are part of the project's testing process, they are not enabled in production builds, in line with best practices.

This approach enhances the reliability of the project by addressing many common issues during development, ensuring that production releases are stable and secure.

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

letsgolang

Fundamentos 0/5 ●

Geral

Pré-requisitos

Supervisão do projeto

Outro

Controle de Mudanças 1/4 ●

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

Qualidade 0/7 ●

Padrões de codificação

Sistema de compilação funcional

Conjunto de testes automatizados

Segurança 0/5 ●

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

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

Outras questões de segurança

Análise 2/2 ●

Análise dinâmica de código