Critérios de Melhores Práticas FLOSS (Selo de Aprovação)

Este é o conjunto de melhores práticas para projetos de Software Livre/Libre e de Código Aberto (FLOSS) alcançarem o selo de aprovação 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 para todos os níveis de selo também está disponível.

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

Aprovação

Fundamentos

Conteúdo básico do site do projeto

  • O site do projeto DEVE descrever sucintamente o que o software faz (qual problema ele resolve?). [description_good]
  • O site do projeto DEVE fornecer informações sobre como: obter, fornecer feedback (como relatórios de bugs ou melhorias) e contribuir com o software. [interact]
  • As informações sobre como contribuir DEVEM explicar o processo de contribuição (por exemplo, pull requests são usados?) {URL de atendimento} [contribution]
  • As informações sobre como contribuir DEVERIAM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação exigido). {URL de atendimento} [contribution_requirements]

Licença FLOSS

Documentação

  • O projeto DEVE fornecer documentação básica para o software produzido pelo projeto. {Justificativa de N/A} [documentation_basics]
  • O projeto DEVE fornecer documentação de referência que descreva a interface externa (tanto entrada quanto saída) do software produzido pelo projeto. {Justificativa de N/A} [documentation_interface]

Outro

  • Os sites do projeto (site, repositório e URLs de download) DEVEM suportar HTTPS usando TLS. [sites_https]
  • O projeto DEVE ter um ou mais mecanismos para discussão (incluindo mudanças propostas e questões) que sejam pesquisáveis, permitam que mensagens e tópicos sejam endereçados por URL, permitam que novas pessoas participem de algumas das discussões e não exijam instalação no lado do cliente de software proprietário. [discussion]
  • O projeto DEVERIA fornecer documentação em inglês e ser capaz de aceitar relatórios de bugs e comentários sobre código em inglês. [english]
  • O projeto DEVE ser mantido. [maintained]

Controle de Mudanças

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

  • O projeto DEVE ter um repositório de código-fonte controlado por versão que seja publicamente legível e tenha uma URL. [repo_public]
  • O repositório de código-fonte do projeto DEVE rastrear quais mudanças foram feitas, quem fez as mudanças e quando as mudanças foram feitas. [repo_track]
  • Para permitir revisão colaborativa, o repositório de código-fonte do projeto DEVE incluir versões intermediárias para revisão entre lançamentos; ele NÃO DEVE incluir apenas lançamentos finais. [repo_interim]
  • É SUGERIDO que software de controle de versão distribuído comum seja usado (por exemplo, git) para o repositório de código-fonte do projeto. [repo_distributed]

Numeração de versão única

  • Os resultados do projeto DEVEM ter um identificador de versão único para cada lançamento destinado a ser usado pelos usuários. [version_unique]
  • É SUGERIDO que o formato de numeração de versão Versionamento Semântico (SemVer) ou Versionamento de Calendário (CalVer) seja usado para lançamentos. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro. [version_semver]
  • É SUGERIDO que os projetos identifiquem cada lançamento dentro de seu sistema de controle de versão. Por exemplo, é SUGERIDO que aqueles que usam git identifiquem cada lançamento usando tags do git. [version_tags]

Notas de lançamento

  • O projeto DEVE fornecer, em cada lançamento, notas de lançamento que sejam um resumo legível por humanos das principais mudanças nesse lançamento para ajudar os usuários a determinar se devem atualizar e qual será o impacto da atualização. As notas de lançamento NÃO DEVEM ser a saída bruta de um log de controle de versão (por exemplo, os resultados do comando "git log" não são notas de lançamento). Projetos cujos resultados não se destinam à reutilização em vários locais (como o software para um único site ou serviço) E empregam entrega contínua PODEM selecionar "N/A". {Justificativa de N/A} {URL de atendimento} [release_notes]
  • As notas de lançamento DEVEM identificar todas as vulnerabilidades de tempo de execução publicamente conhecidas corrigidas neste lançamento que já tinham uma atribuição CVE ou similar quando o lançamento foi criado. Este critério pode ser marcado como não aplicável (N/A) se os usuários normalmente não conseguem atualizar o software por conta própria (por exemplo, como geralmente é verdade para atualizações de kernel). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Se não houver notas de lançamento ou se não houve vulnerabilidades publicamente conhecidas, escolha N/A. {Justificativa de N/A} [release_notes_vulns]

Relatórios

Processo de relato de bugs

  • O projeto DEVE fornecer um processo para os usuários enviarem relatórios de bugs (por exemplo, usando um rastreador de problemas ou uma lista de discussão). {URL de atendimento} [report_process]
  • O projeto DEVERIA usar um rastreador de problemas para rastrear problemas individuais. [report_tracker]
  • O projeto DEVE reconhecer a maioria dos relatórios de bugs enviados nos últimos 2-12 meses (inclusive); a resposta não precisa incluir uma correção. [report_responses]
  • O projeto DEVERIA responder a uma maioria (>50%) das solicitações de melhorias nos últimos 2-12 meses (inclusive). [enhancement_responses]
  • O projeto DEVE ter um arquivo publicamente disponível para relatórios e respostas para pesquisa posterior. {URL de atendimento} [report_archive]

Processo de relato de vulnerabilidades

  • O projeto DEVE publicar o processo para relatar vulnerabilidades no site do projeto. {URL de atendimento} [vulnerability_report_process]
  • Se relatórios privados de vulnerabilidades forem suportados, o projeto DEVE incluir como enviar as informações de uma forma que seja mantida privada. {N/A permitido} {URL de atendimento} [vulnerability_report_private]
  • O tempo de resposta inicial do projeto para qualquer relatório de vulnerabilidade recebido nos últimos 6 meses DEVE ser menor ou igual a 14 dias. {N/A permitido} [vulnerability_report_response]

Qualidade

Sistema de compilação funcional

  • Se o software produzido pelo projeto requer construção para uso, o projeto DEVE fornecer um sistema de construção funcional que possa reconstruir automaticamente o software a partir do código-fonte. {N/A permitido} [build]
  • É SUGERIDO que ferramentas comuns sejam usadas para construir o software. {N/A permitido} [build_common_tools]
  • O projeto DEVERIA ser construível usando apenas ferramentas FLOSS. {N/A permitido} [build_floss_tools]

Conjunto de testes automatizados

  • O projeto DEVE usar pelo menos um conjunto de testes automatizados que seja disponibilizado publicamente como FLOSS (esse conjunto de testes pode ser mantido como um projeto FLOSS separado). O projeto DEVE mostrar ou documentar claramente como executar o(s) conjunto(s) de testes (por exemplo, por meio de um script de integração contínua (CI) ou por meio de documentação em arquivos como BUILD.md, README.md ou CONTRIBUTING.md). [test]
  • Um conjunto de testes DEVERIA ser invocável de forma padrão para aquela linguagem. [test_invocation]
  • É SUGERIDO que o conjunto de testes cubra a maioria (ou idealmente todos) os ramos de código, campos de entrada e funcionalidade. [test_most]
  • É SUGERIDO que o projeto implemente integração contínua (onde código novo ou alterado é frequentemente integrado em um repositório de código central e testes automatizados são executados no resultado). [test_continuous_integration]

Teste de novas funcionalidades

  • O projeto DEVE ter uma política geral (formal ou não) de que conforme nova funcionalidade importante seja adicionada ao software produzido pelo projeto, testes dessa funcionalidade devem ser adicionados a um conjunto de testes automatizados. [test_policy]
  • O projeto DEVE ter evidências de que a test_policy para adicionar testes foi seguida nas mudanças mais recentes e importantes ao software produzido pelo projeto. [tests_are_added]
  • É SUGERIDO que esta política sobre adicionar testes (veja test_policy) seja documentada nas instruções para propostas de mudanças. [tests_documented_added]

Sinalizadores de aviso

  • O projeto DEVE habilitar uma ou mais flags de avisos do compilador, um modo de linguagem "seguro", ou usar uma ferramenta "linter" separada para procurar erros de qualidade de código ou erros comuns simples, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. {N/A permitido} [warnings]
  • O projeto DEVE tratar os avisos. {N/A permitido} [warnings_fixed]
  • É SUGERIDO que projetos sejam maximamente rigorosos com avisos no software produzido pelo projeto, onde prático. {N/A permitido} [warnings_strict]

Segurança

Conhecimento de desenvolvimento seguro

  • O projeto DEVE ter pelo menos um desenvolvedor principal que saiba como projetar software seguro. (Veja 'details' para os requisitos exatos.) [know_secure_design]
  • Pelo menos um dos desenvolvedores principais do projeto DEVE conhecer tipos comuns de erros que levam a vulnerabilidades neste tipo de software, bem como pelo menos um método para combater ou mitigar cada um deles. [know_common_errors]

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

  • O software produzido pelo projeto DEVE usar, por padrão, apenas protocolos criptográficos e algoritmos que são publicamente publicados e revisados por especialistas (se protocolos criptográficos e algoritmos forem usados). {N/A permitido} [crypto_published]
  • Se o software produzido pelo projeto for uma aplicação ou biblioteca, e seu propósito principal não for implementar criptografia, então ele DEVERIA apenas chamar software especificamente projetado para implementar funções criptográficas; ele NÃO DEVERIA reimplementar o seu próprio. {N/A permitido} [crypto_call]
  • Toda funcionalidade no software produzido pelo projeto que depende de criptografia DEVE ser implementável usando FLOSS. {N/A permitido} [crypto_floss]
  • Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM usar comprimentos de chave padrão que pelo menos atendam aos requisitos mínimos do NIST até o ano de 2030 (conforme declarado em 2012). DEVE ser possível configurar o software para que comprimentos de chave menores sejam completamente desabilitados. {N/A permitido} [crypto_keylength]
  • Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos quebrados (por exemplo, MD4, MD5, DES único, RC4, Dual_EC_DRBG), ou usar modos de cifra que são inadequados ao contexto, a menos que sejam necessários para implementar um protocolo interoperável (onde o protocolo implementado é a versão mais recente desse padrão amplamente suportado pelo ecossistema de rede, esse ecossistema requer o uso de tal algoritmo ou modo, e esse ecossistema não oferece nenhuma alternativa mais segura). A documentação DEVE descrever quaisquer riscos de segurança relevantes e quaisquer mitigações conhecidas se esses algoritmos ou modos quebrados forem necessários para um protocolo interoperável. {N/A permitido} [crypto_working]
  • Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVERIAM 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} [crypto_weaknesses]
  • Os mecanismos de segurança dentro do software produzido pelo projeto DEVERIAM implementar sigilo perfeito para frente para protocolos de acordo de chave, de modo que uma chave de sessão derivada de um conjunto de chaves de longo prazo não possa ser comprometida se uma das chaves de longo prazo for comprometida no futuro. {N/A permitido} [crypto_pfs]
  • Se o software produzido pelo projeto causar o armazenamento de 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). Veja também OWASP Password Storage Cheat Sheet. {N/A permitido} [crypto_password_storage]
  • Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM gerar todas as chaves criptográficas e nonces usando um gerador de números aleatórios criptograficamente seguro, e NÃO DEVEM fazê-lo usando geradores que são criptograficamente inseguros. {N/A permitido} [crypto_random]

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

  • O projeto DEVE usar um mecanismo de entrega que contraponha ataques MITM. Usar https ou ssh+scp é aceitável. [delivery_mitm]
  • Um hash criptográfico (por exemplo, um sha1sum) NÃO DEVE ser recuperado por http e usado sem verificar uma assinatura criptográfica. [delivery_unsigned]

Vulnerabilidades conhecidas publicamente corrigidas

  • NÃO DEVE haver vulnerabilidades não corrigidas de severidade média ou superior que sejam publicamente conhecidas por mais de 60 dias. [vulnerabilities_fixed_60_days]
  • Os projetos DEVERIAM corrigir todas as vulnerabilidades críticas rapidamente após serem relatadas. [vulnerabilities_critical_fixed]

Outras questões de segurança

  • Os repositórios públicos NÃO DEVEM vazar uma credencial privada válida (por exemplo, uma senha funcionando ou chave privada) que se destina a limitar o acesso público. [no_leaked_credentials]

Análise

Análise estática de código

  • Pelo menos uma ferramenta de análise estática de código (além de avisos do compilador e modos de linguagem "seguros") DEVE ser aplicada a qualquer grande lançamento de produção proposto do software antes de seu lançamento, se houver pelo menos uma ferramenta FLOSS que implemente este critério na linguagem selecionada. {Justificativa de N/A} {Justificativa de atendimento} [static_analysis]
  • É SUGERIDO que pelo menos uma das ferramentas de análise estática usadas para o critério static_analysis inclua regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado. {N/A permitido} [static_analysis_common_vulnerabilities]
  • Todas as vulnerabilidades exploráveis de severidade média e superior descobertas com análise estática de código DEVEM ser corrigidas de forma oportuna após serem confirmadas. {N/A permitido} [static_analysis_fixed]
  • É SUGERIDO que a análise estática de código-fonte ocorra em cada commit ou pelo menos diariamente. {N/A permitido} [static_analysis_often]

Análise dinâmica de código

  • É SUGERIDO que pelo menos uma ferramenta de análise dinâmica seja aplicada a qualquer grande lançamento de produção proposto do software antes de seu lançamento. [dynamic_analysis]
  • É SUGERIDO que 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) seja 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). {N/A permitido} [dynamic_analysis_unsafe]
  • É SUGERIDO que o projeto use uma configuração para pelo menos alguma análise dinâmica (como testes ou fuzzing) que habilite muitas asserções. Em muitos casos, essas asserções não devem ser habilitadas em builds de produção. [dynamic_analysis_enable_assertions]
  • Todas as vulnerabilidades exploráveis de severidade média e superior descobertas com análise dinâmica de código DEVEM ser corrigidas em tempo hábil após serem confirmadas. {N/A permitido} [dynamic_analysis_fixed]