Critérios de Melhores Práticas FLOSS (Selo Prata)
Este é o conjunto de melhores práticas para projetos de Software Livre/Libre e de Código Aberto (FLOSS) alcançarem o selo prata 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.
Prata
Fundamentos
Pré-requisitos
Conteúdo básico do site do projeto
-
As informações sobre como contribuir DEVEM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação obrigatório).
{URL de atendimento}
[contribution_requirements]
Supervisão do projeto
-
O projeto DEVERIA ter um mecanismo legal onde todos os desenvolvedores de quantidades não triviais de software do projeto afirmem que estão legalmente autorizados a fazer essas contribuições. A abordagem mais comum e facilmente implementada para fazer isso é usando um Developer Certificate of Origin (DCO), onde os usuários adicionam "signed-off-by" em seus commits e o projeto faz link para o site do DCO. No entanto, isso PODE ser implementado como um Contributor License Agreement (CLA) ou outro mecanismo legal.
{URL de atendimento}
[dco]
-
O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave).
{URL de atendimento}
[governance]
-
O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão.
{URL de atendimento}
[code_of_conduct]
-
O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma.
{URL de atendimento}
[roles_responsibilities]
-
O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS).
{URL de atendimento}
[access_continuity]
-
O projeto DEVERIA ter um "bus factor" de 2 ou mais.
{URL de atendimento}
[bus_factor]
Documentação
-
O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano.
{URL de atendimento}
[documentation_roadmap]
-
O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A).
{Justificativa de N/A}
{URL de atendimento}
[documentation_architecture]
-
O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança").
{N/A permitido}
{URL de atendimento}
[documentation_security]
-
O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software.
{Justificativa de N/A}
{URL de atendimento}
[documentation_quick_start]
-
O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume.
{Justificativa de N/A}
{Justificativa de atendimento}
[documentation_current]
-
A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada.
{URL de atendimento}
[documentation_achievements]
Acessibilidade e internacionalização
-
O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo.
{Justificativa de N/A}
{Justificativa de atendimento}
[accessibility_best_practices]
-
O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[internationalization]
Outro
-
Se os sites do projeto (site, repositório e URLs de download) armazenam 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). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[sites_password_security]
Controle de Mudanças
Versões anteriores
-
O projeto DEVE manter as versões mais antigas do produto mais frequentemente usadas ou fornecer um caminho de atualização para versões mais recentes. Se o caminho de atualização for difícil, o projeto DEVE documentar como realizar a atualização (por exemplo, as interfaces que mudaram e etapas sugeridas detalhadas para ajudar na atualização).
{Justificativa de N/A}
{Justificativa de atendimento}
[maintenance_or_update]
Relatórios
Processo de relato de bugs
-
O projeto DEVE usar um rastreador de questões para rastrear questões individuais.
{Justificativa de N/A}
{Justificativa de atendimento}
[report_tracker]
Processo de relato de vulnerabilidades
-
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).
{Justificativa de N/A}
{URL de atendimento}
[vulnerability_report_credit]
-
O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades.
{URL de atendimento}
[vulnerability_response_process]
Qualidade
Padrões de codificação
-
O projeto DEVE identificar os guias de estilo de codificação específicos para as linguagens primárias que utiliza, e exigir que as contribuições geralmente estejam em conformidade com eles.
{Justificativa de N/A}
{URL de atendimento}
[coding_standards]
-
O projeto DEVE aplicar automaticamente seu(s) estilo(s) de codificação selecionado(s) se houver pelo menos uma ferramenta FLOSS que possa fazer isso na(s) linguagem(ns) selecionada(s).
{Justificativa de N/A}
{Justificativa de atendimento}
[coding_standards_enforced]
Sistema de compilação funcional
-
Os sistemas de compilação para binários nativos DEVEM honrar as variáveis de compilador e vinculador (ambiente) relevantes passadas para eles (por exemplo, CC, CFLAGS, CXX, CXXFLAGS e LDFLAGS) e passá-las para invocações de compilador e vinculador. Um sistema de compilação PODE estendê-las com flags adicionais; ele NÃO DEVE simplesmente substituir valores fornecidos pelos seus próprios. Se nenhum binário nativo estiver sendo gerado, selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[build_standard_variables]
-
O sistema de compilação e instalação DEVERIA preservar informações de depuração se elas forem solicitadas nas flags relevantes (por exemplo, "install -s" não é usado). Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[build_preserve_debug]
-
O sistema de compilação do software produzido pelo projeto NÃO DEVE compilar recursivamente subdiretórios se houver dependências cruzadas nos subdiretórios. Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[build_non_recursive]
-
O projeto DEVE ser capaz de repetir o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. 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}
{Justificativa de atendimento}
[build_repeatable]
Sistema de instalação
-
O projeto DEVE fornecer uma maneira de instalar e desinstalar facilmente o software produzido pelo projeto usando uma convenção comumente utilizada.
{Justificativa de N/A}
{Justificativa de atendimento}
[installation_common]
-
O sistema de instalação para usuários finais DEVE honrar convenções padrão para selecionar o local onde os artefatos compilados são escritos no momento da instalação. Por exemplo, se instalar arquivos em um sistema POSIX, ele DEVE honrar a variável de ambiente DESTDIR. Se não houver sistema de instalação ou convenção padrão, selecione "não aplicável" (N/A).
{Justificativa de N/A}
{Justificativa de atendimento}
[installation_standard_variables]
-
O projeto DEVE fornecer uma maneira para desenvolvedores em potencial instalarem rapidamente todos os resultados do projeto e ambiente de suporte necessário para fazer alterações, incluindo os testes e ambiente de teste. Isso DEVE ser realizado com uma convenção comumente utilizada.
{Justificativa de N/A}
{Justificativa de atendimento}
[installation_development_quick]
Componentes mantidos externamente
-
O projeto DEVE listar dependências externas de uma forma processável por computador.
{Justificativa de N/A}
{URL de atendimento}
[external_dependencies]
-
Os projetos DEVEM monitorar ou verificar periodicamente suas dependências externas (incluindo cópias de conveniência) para detectar vulnerabilidades conhecidas, e corrigir vulnerabilidades exploráveis ou verificá-las como não exploráveis.
{Justificativa de N/A}
{Justificativa de atendimento}
[dependency_monitoring]
-
"O projeto DEVE:
- facilitar a identificação e atualização de componentes mantidos externamente reutilizados; ou
- usar os componentes padrão fornecidos pelo sistema ou linguagem de programação.
Então, se uma vulnerabilidade for encontrada em um componente reutilizado, será
fácil atualizar esse componente."
{Justificativa de N/A}
{Justificativa de atendimento}
[updateable_reused_components]
-
O projeto DEVERIA evitar usar funções e APIs obsoletas ou desatualizadas onde alternativas FLOSS estejam disponíveis no conjunto de tecnologia que usa (sua "pilha de tecnologia") e para uma supermaioria dos usuários que o projeto suporta (para que os usuários tenham acesso pronto à alternativa).
{Justificativa de N/A}
{Justificativa de atendimento}
[interfaces_current]
Conjunto de testes automatizados
-
Uma suíte de testes automatizada DEVE ser aplicada a cada check-in em um repositório compartilhado para pelo menos um branch. Esta suíte de testes DEVE produzir um relatório sobre sucesso ou falha do teste.
{Justificativa de atendimento}
[automated_integration_testing]
-
O projeto DEVE adicionar testes de regressão a uma suíte de testes automatizada para pelo menos 50% dos bugs corrigidos nos últimos seis meses.
{Justificativa de N/A}
{Justificativa de atendimento}
[regression_tests_added50]
-
O projeto DEVE ter suíte(s) de teste automatizada(s) FLOSS que forneçam pelo menos 80% de cobertura de instruções 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_coverage80]
Teste de novas funcionalidades
-
O projeto DEVE ter uma política escrita formal de que, à medida que uma nova funcionalidade importante é adicionada, testes para a nova funcionalidade DEVEM ser adicionados a uma suíte de testes automatizada.
{Justificativa de N/A}
{Justificativa de atendimento}
[test_policy_mandated]
-
O projeto DEVE incluir, em suas instruções documentadas para propostas de mudança, a política de que testes devem ser adicionados para novas funcionalidades importantes.
{Justificativa de N/A}
{Justificativa de atendimento}
[tests_documented_added]
Sinalizadores de aviso
-
Os projetos DEVEM ser maximamente rigorosos com avisos no software produzido pelo projeto, onde for prático.
{Justificativa de N/A}
{Justificativa de atendimento}
[warnings_strict]
Segurança
Conhecimento de desenvolvimento seguro
-
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).
{Justificativa de N/A}
{Justificativa de atendimento}
[implement_secure_design]
Usar práticas criptográficas boas e básicas
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_weaknesses]
-
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.
{N/A permitido}
{Justificativa de atendimento}
[crypto_algorithm_agility]
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_credential_agility]
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_used_network]
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_tls12]
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_certificate_verification]
-
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).
{N/A permitido}
{Justificativa de atendimento}
[crypto_verification_private]
Lançamento seguro
-
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).
{Justificativa de N/A}
{Justificativa de atendimento}
[signed_releases]
-
É 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.
{Justificativa de atendimento}
[version_tags_signed]
Outras questões de segurança
-
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.
{Justificativa de N/A}
{Justificativa de atendimento}
[input_validation]
-
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.
{Justificativa de N/A}
{Justificativa de atendimento}
[hardening]
-
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 de atendimento}
[assurance_case]
Análise
Análise estática de código
-
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.
{Justificativa de N/A}
{Justificativa de atendimento}
[static_analysis_common_vulnerabilities]
Análise dinâmica de código
-
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).
{Justificativa de N/A}
{Justificativa de atendimento}
[dynamic_analysis_unsafe]