Critérios de Melhores Práticas FLOSS (Selo Ouro)

Este é o conjunto de melhores práticas para projetos de Software Livre/Libre e de Código Aberto (FLOSS) alcançarem o selo ouro de Melhores Práticas da Open Source Security Foundation (OpenSSF). Você pode mostrar esta lista com apenas os critérios ou com informações adicionais. O conjunto completo de critérios também está disponível.

Consulte discussão de critérios para mais informações sobre esses critérios.

Ouro

Fundamentos

Pré-requisitos

• O projeto DEVE alcançar um selo de nível prata. ^{[achieve_silver]}

Supervisão do projeto

• O projeto DEVE ter um "fator ônibus" de 2 ou mais. {URL de atendimento} ^[bus_factor]
• O projeto DEVE ter pelo menos dois contribuidores significativos não associados. {URL de atendimento} ^{[contributors_unassociated]}

Outro

• O projeto DEVE incluir uma declaração de copyright em cada arquivo-fonte, identificando o detentor do copyright (por exemplo, os colaboradores do [nome do projeto]). {Justificativa de atendimento} ^{[copyright_per_file]}
• O projeto DEVE incluir uma declaração de licença em cada arquivo-fonte. Isso PODE ser feito incluindo o seguinte dentro de um comentário perto do início de cada arquivo: SPDX-License-Identifier: [expressão de licença SPDX para o projeto]. {Justificativa de atendimento} ^{[license_per_file]}

Controle de Mudanças

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

• O repositório de código do projeto DEVE usar um software de controle de versão distribuído comum (por exemplo, git ou mercurial). {Justificativa de atendimento} ^{[repo_distributed]}
• O projeto DEVE identificar claramente pequenas tarefas que podem ser realizadas por novos colaboradores ou colaboradores casuais. {URL de atendimento} ^{[small_tasks]}
• O projeto DEVE exigir autenticação de dois fatores (2FA) para desenvolvedores para alterar um repositório central ou acessar dados sensíveis (como relatórios de vulnerabilidade privados). Este mecanismo 2FA PODE usar mecanismos sem mecanismos criptográficos, como SMS, embora isso não seja recomendado. {Justificativa de atendimento} ^{[require_2FA]}
• A autenticação de dois fatores (2FA) do projeto DEVERIA usar mecanismos criptográficos para evitar personificação. A autenticação 2FA baseada em Short Message Service (SMS), por si só, NÃO atende a este critério, pois não é criptografada. {Justificativa de atendimento} ^[secure_2FA]

Qualidade

Padrões de codificação

• O projeto DEVE documentar seus requisitos de revisão de código, incluindo como a revisão de código é conduzida, o que deve ser verificado e o que é necessário para ser aceitável. {Justificativa de N/A} {URL de atendimento} ^{[code_review_standards]}
• O projeto DEVE ter pelo menos 50% de todas as modificações propostas revisadas antes do lançamento por uma pessoa diferente do autor, para determinar se é uma modificação que vale a pena e livre de problemas conhecidos que argumentariam contra sua inclusão {Justificativa de atendimento} ^{[two_person_review]}

Sistema de compilação funcional

• O projeto DEVE ter uma compilação reproduzível. Se nenhuma compilação ocorrer (por exemplo, linguagens de script onde o código fonte é usado diretamente em vez de ser compilado), selecione "não aplicável" (N/A). {Justificativa de N/A} {URL de atendimento} ^{[build_reproducible]}

Conjunto de testes automatizados

• Um conjunto de testes DEVE ser invocável de forma padrão para aquela linguagem. {URL de atendimento} ^{[test_invocation]}
• O projeto DEVE implementar integração contínua, onde o código novo ou alterado é frequentemente integrado em um repositório de código central e testes automatizados são executados no resultado. {URL de atendimento} ^{[test_continuous_integration]}
• O projeto DEVE ter conjunto(s) de testes automatizados FLOSS que fornecem pelo menos 90% de cobertura de instrução se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. {Justificativa de N/A} {Justificativa de atendimento} ^{[test_statement_coverage90]}
• O projeto DEVE ter conjunto(s) de testes automatizados FLOSS que fornecem pelo menos 80% de cobertura de ramos se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. {Justificativa de N/A} {Justificativa de atendimento} ^{[test_branch_coverage80]}

Segurança

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

• O software produzido pelo projeto DEVE 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 DEVEM 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). {N/A permitido} {Justificativa de atendimento} ^{[crypto_used_network]}
• O software produzido pelo projeto DEVE, se suportar ou usar TLS, suportar pelo menos a versão 1.2 do TLS. Observe que o predecessor do TLS foi chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} ^{[crypto_tls12]}

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

• O site do projeto, repositório (se acessível via web) e site de download (se separado) DEVEM incluir cabeçalhos de fortalecimento chave com valores não permissivos. {URL de atendimento} ^{[hardened_site]}

Outras questões de segurança

• O projeto DEVE ter realizado uma revisão de segurança nos últimos 5 anos. Esta revisão DEVE considerar os requisitos de segurança e o limite de segurança. {Justificativa de atendimento} ^{[security_review]}
• Mecanismos de proteção DEVEM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. {Justificativa de N/A} {URL de atendimento} ^[hardening]

Análise

Análise dinâmica de código

• 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. {Justificativa de N/A} {Justificativa de atendimento} ^{[dynamic_analysis]}
• 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. {Justificativa de N/A} {Justificativa de atendimento} ^{[dynamic_analysis_enable_assertions]}