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

  Detalhes:

  Os contribuidores são associados se forem pagos para trabalhar pela mesma organização (como empregado ou contratado) e a organização se beneficia dos resultados do projeto. Concessões financeiras não contam como sendo da mesma organização se passarem por outras organizações (por exemplo, concessões científicas pagas a diferentes organizações de uma fonte governamental ou ONG comum não fazem com que os contribuidores sejam associados). Alguém é um contribuidor significativo se fez contribuições não triviais para o projeto no último ano. Exemplos de bons indicadores de um contribuidor significativo são: escreveu pelo menos 1.000 linhas de código, contribuiu com 50 commits, ou contribuiu com pelo menos 20 páginas de documentação.

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

  Detalhes:

  Isso PODE ser feito incluindo o seguinte dentro de um comentário perto do início de cada arquivo: "Copyright os colaboradores do [nome do projeto].". Veja "Copyright Notices in Open Source Software Projects" por Steve Winslow.

• 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]}

  Detalhes:

  Isso PODE também ser feito incluindo uma declaração em linguagem natural identificando a licença. O projeto PODE também incluir uma URL estável apontando para o texto da licença, ou o texto completo da licença. Observe que o critério license_location requer que a licença do projeto esteja em um local padrão. Veja este tutorial SPDX para mais informações sobre expressões de licença SPDX. Observe a relação com copyright_per_file, cujo conteúdo normalmente precederia as informações de licença.

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

  Detalhes:

  Esta identificação é tipicamente feita marcando problemas selecionados em um rastreador de problemas com uma ou mais tags que o projeto usa para o propósito, por exemplo, up-for-grabs, first-timers-only, "Small fix", microtask ou IdealFirstBug. Essas novas tarefas não precisam envolver a adição de funcionalidade; elas podem ser melhorar a documentação, adicionar casos de teste ou qualquer outra coisa que ajude o projeto e ajude o colaborador a entender mais sobre o projeto.

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

  Detalhes:

  Um mecanismo de 2FA que atende a este critério seria um aplicativo de Time-based One-Time Password (TOTP) que gera automaticamente um código de autenticação que muda após um determinado período de tempo. Observe que o GitHub suporta TOTP.

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

  Detalhes:

  Veja também two_person_review e contribution_requirements.

• 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]}

  Detalhes:

  Uma compilação reproduzível significa que várias partes podem refazer independentemente o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. Em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Desenvolvedores JavaScript podem considerar usar npm shrinkwrap e webpack OccurrenceOrderPlugin. Usuários de GCC e clang podem achar útil a opção -frandom-seed. O ambiente de compilação (incluindo o conjunto de ferramentas) pode frequentemente ser definido para partes externas especificando o hash criptográfico de um contêiner específico ou máquina virtual que eles podem usar para recompilar. O projeto de compilações reproduzíveis tem documentação sobre como fazer isso.

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

  Detalhes:

  Na maioria dos casos, isso significa que cada desenvolvedor que trabalha em tempo integral no projeto integra pelo menos diariamente.

• 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]}

  Detalhes:

  Observe que o GitHub e o GitLab são conhecidos por atender a isso. Sites como https://securityheaders.com/ podem verificar isso rapidamente. Os principais cabeçalhos de proteção são: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (como "nosniff") e X-Frame-Options. Sites web totalmente estáticos sem capacidade de fazer login por meio das páginas web poderiam omitir alguns cabeçalhos de proteção com menos risco, mas não há maneira confiável de detectar tais sites, portanto exigimos esses cabeçalhos mesmo se forem sites totalmente estáticos.

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

  Detalhes:

  Isso PODE ser feito pelos membros do projeto e/ou uma avaliação independente. Esta avaliação PODE ser apoiada por ferramentas de análise estática e dinâmica, mas também deve haver revisão humana para identificar problemas (particularmente no projeto) que as ferramentas não conseguem detectar.

• 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]}