Critérios de Melhores Práticas FLOSS (Todos os Níveis)

Este é o conjunto de melhores práticas para projetos de Software Livre/Libre e de Código Aberto (FLOSS) alcançarem os selos de Melhores Práticas da Open Source Security Foundation (OpenSSF) nos níveis de selo de aprovação, prata e ouro. Você pode mostrar esta lista com apenas os critérios ou com informações adicionais. Você também pode ver apenas os critérios de aprovação, prata e ouro, bem como estatísticas de critérios.

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

  Detalhes:

  Isso DEVE estar em linguagem que usuários potenciais possam entender (por exemplo, ele usa o mínimo de jargão).

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

  Detalhes:

  Presumimos que projetos no GitHub usam issues e pull requests, a menos que indicado de outra forma. Essa informação pode ser breve, por exemplo, declarando que o projeto usa pull requests, um rastreador de issues ou postagens em uma lista de discussão (qual?)

• 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

• O software produzido pelo projeto DEVE ser lançado como FLOSS. ^{[floss_license]}

  Detalhes:

  FLOSS é software lançado de uma forma que atende à Definição de Código Aberto ou à Definição de Software Livre. Exemplos de tais licenças incluem CC0, MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Para nossos propósitos, isso significa que a licença DEVE ser:

  • uma licença aprovada pela Open Source Initiative (OSI), ou
  • uma licença livre aprovada pela Free Software Foundation (FSF), ou
  • uma licença livre aceitável para o Debian main, ou
  • uma licença "boa" de acordo com o Fedora.

  O software PODE também ser licenciado de outras formas (por exemplo, "GPLv2 ou proprietário" é aceitável).

• É SUGERIDO que qualquer licença(s) exigida para o software produzido pelo projeto seja aprovada pela Open Source Initiative (OSI). ^{[floss_license_osi]}

  Detalhes:

  A OSI usa um processo de aprovação rigoroso para determinar quais licenças são OSS.

• O projeto DEVE publicar a(s) licença(s) de seus resultados em um local padrão em seu repositório de código-fonte. {URL de atendimento} ^{[license_location]}

  Detalhes:

  Uma convenção é publicar a licença como um arquivo de nível superior chamado LICENSE ou COPYING, que PODE ser seguido por uma extensão como ".txt" ou ".md". Uma convenção alternativa é ter um diretório chamado LICENSES contendo arquivo(s) de licença; esses arquivos são tipicamente nomeados como seu identificador de licença SPDX seguido por uma extensão de arquivo apropriada, conforme descrito na Especificação REUSE. Observe que este critério é apenas um requisito no repositório de código-fonte. Você NÃO precisa incluir o arquivo de licença ao gerar algo a partir do código-fonte (como um executável, pacote ou contêiner). Por exemplo, ao gerar um pacote R para a Comprehensive R Archive Network (CRAN), siga a prática padrão do CRAN: se a licença for uma licença padrão, use a especificação de licença curta padrão (para evitar instalar outra cópia do texto) e liste o arquivo LICENSE em um arquivo de exclusão como .Rbuildignore. Da mesma forma, ao criar um pacote Debian, você pode colocar um link no arquivo de copyright para o texto da licença em /usr/share/common-licenses e excluir o arquivo de licença do pacote criado (por exemplo, deletando o arquivo após chamar dh_auto_install). Nós encorajamos a inclusão de informações de licença legíveis por máquina em formatos gerados, quando praticável.

Documentação

• O projeto DEVE fornecer documentação básica para o software produzido pelo projeto. {Justificativa de N/A} ^{[documentation_basics]}

  Detalhes:

  Esta documentação deve estar em alguma mídia (como texto ou vídeo) que inclua: como instalá-lo, como iniciá-lo, como usá-lo (possivelmente com um tutorial usando exemplos) e como usá-lo de forma segura (por exemplo, o que fazer e o que não fazer) se esse for um tópico apropriado para o software. A documentação de segurança não precisa ser longa. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. Se o projeto não produz software, escolha "não aplicável" (N/A).

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

  Detalhes:

  A documentação de uma interface externa explica a um usuário final ou desenvolvedor como usá-la. Isso incluiria sua interface de programação de aplicativos (API) se o software tiver uma. Se for uma biblioteca, documente as principais classes/tipos e métodos/funções que podem ser chamados. Se for uma aplicação web, defina sua interface de URL (geralmente sua interface REST). Se for uma interface de linha de comando, documente os parâmetros e opções que suporta. Em muitos casos, é melhor que a maior parte desta documentação seja gerada automaticamente, para que essa documentação permaneça sincronizada com o software conforme ele muda, mas isso não é obrigatório. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. A documentação PODE ser gerada automaticamente (quando praticável, esta é frequentemente a melhor forma de fazê-lo). A documentação de uma interface REST pode ser gerada usando Swagger/OpenAPI. A documentação da interface de código PODE ser gerada usando ferramentas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) e Doxygen (muitos). Simplesmente ter comentários no código de implementação não é suficiente para satisfazer este critério; precisa haver uma maneira fácil de ver a informação sem ler todo o código-fonte. Se o projeto não produz software, escolha "não aplicável" (N/A).

Outro

• Os sites do projeto (site, repositório e URLs de download) DEVEM suportar HTTPS usando TLS. ^{[sites_https]}

  Detalhes:

  Isso requer que a URL da página inicial do projeto e a URL do repositório de controle de versão comecem com "https:", não "http:". Você pode obter certificados gratuitos do Let's Encrypt. Os projetos PODEM implementar este critério usando (por exemplo) GitHub pages, GitLab pages ou SourceForge project pages. Se você suportar HTTP, recomendamos que você redirecione o tráfego HTTP para 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]

  Detalhes:

  Exemplos de mecanismos aceitáveis incluem lista(s) de discussão arquivadas, discussões de questões e pull requests do GitHub, Bugzilla, Mantis e Trac. Mecanismos de discussão assíncronos (como IRC) são aceitáveis se atenderem a esses critérios; certifique-se de que haja um mecanismo de arquivamento endereçável por URL. JavaScript proprietário, embora desencorajado, é permitido.

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

  Detalhes:

  O inglês é atualmente a língua franca da tecnologia de computadores; o suporte ao inglês aumenta o número de diferentes desenvolvedores e revisores em potencial em todo o mundo. Um projeto pode atender a este critério mesmo que o idioma principal de seus desenvolvedores principais não seja o inglês.

• O projeto DEVE ser mantido. ^[maintained]

  Detalhes:

  No mínimo, o projeto deve tentar responder a relatórios significativos de problemas e vulnerabilidades. Um projeto que está buscando ativamente um badge provavelmente é mantido. Todos os projetos e pessoas têm recursos limitados, e projetos típicos devem rejeitar algumas mudanças propostas, portanto, recursos limitados e rejeições de propostas não indicam por si só um projeto não mantido.
  
  Quando um projeto souber que não será mais mantido, ele deve definir este critério como "Não atendido" e usar o(s) mecanismo(s) apropriado(s) para indicar a outros que não está sendo mantido. Por exemplo, use "DEPRECATED" como o primeiro cabeçalho de seu README, adicione "DEPRECATED" perto do início de sua página inicial, adicione "DEPRECATED" ao início da descrição do projeto do repositório de código, adicione um badge de sem intenção de manutenção em seu README e/ou página inicial, marque-o como descontinuado em quaisquer repositórios de pacotes (por exemplo, npm deprecate), e/ou use o sistema de marcação do repositório de código para arquivá-lo (por exemplo, a configuração "archive" do GitHub, a marcação "archived" do GitLab, o status "readonly" do Gerrit ou o status de projeto "abandoned" do SourceForge). Discussão adicional pode ser encontrada aqui.

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

  Detalhes:

  A URL PODE ser a mesma que a URL do projeto. O projeto PODE usar branches privados (não públicos) em casos específicos enquanto a mudança não for lançada publicamente (por exemplo, para corrigir uma vulnerabilidade antes de ser revelada ao público).

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

  Detalhes:

  Os projetos PODEM optar por omitir versões intermediárias específicas de seus repositórios de código-fonte públicos (por exemplo, aquelas que corrigem vulnerabilidades de segurança não públicas específicas, podem nunca ser lançadas publicamente ou incluem material que não pode ser legalmente postado e não estão no lançamento final).

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

  Detalhes:

  O Git não é especificamente exigido e os projetos podem usar software de controle de versão centralizado (como subversion) com justificativa.

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

  Detalhes:

  Isso PODE ser atendido de várias maneiras, incluindo IDs de commit (como git commit id ou mercurial changeset id) ou um número de versão (incluindo números de versão que usam versionamento semântico ou esquemas baseados em data como AAAAMMDD).

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

  Detalhes:

  Os projetos geralmente devem preferir qualquer formato que seja esperado por seus usuários, por exemplo, porque é o formato normal usado por seu ecossistema. Muitos ecossistemas preferem SemVer, e SemVer é geralmente preferido para interfaces de programação de aplicações (APIs) e kits de desenvolvimento de software (SDKs). CalVer tende a ser usado por projetos que são grandes, têm um número excepcionalmente grande de dependências desenvolvidas independentemente, têm um escopo em constante mudança ou são sensíveis ao tempo. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro, porque incluir um nível micro suporta branches mantidos simultaneamente sempre que isso se tornar necessário. Outros formatos de numeração de versão podem ser usados como números de versão, incluindo IDs de commit do git ou IDs de changeset do mercurial, desde que identifiquem exclusivamente as versões. No entanto, algumas alternativas (como IDs de commit do git) podem causar problemas como identificadores de lançamento, porque os usuários podem não ser capazes de determinar facilmente se estão atualizados. O formato do ID de versão pode não ser importante para identificar lançamentos de software se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua).

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

  Detalhes:

  As notas de lançamento PODEM ser implementadas de várias maneiras. Muitos projetos as fornecem em um arquivo chamado "NEWS", "CHANGELOG" ou "ChangeLog", opcionalmente com extensões como ".txt", ".md" ou ".html". Historicamente, o termo "change log" significava um log de todas as mudanças, mas para atender a esses critérios, o que é necessário é um resumo legível por humanos. As notas de lançamento PODEM, em vez disso, ser fornecidas por mecanismos de sistema de controle de versão, como o fluxo de trabalho GitHub Releases.

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

  Detalhes:

  Este critério ajuda os usuários a determinar se uma determinada atualização irá corrigir uma vulnerabilidade que é publicamente conhecida, para ajudar os usuários a tomar uma decisão informada sobre atualização. Se os usuários normalmente não conseguem atualizar o software por conta própria em seus computadores, mas devem depender de um ou mais intermediários para realizar a atualização (como é frequentemente o caso de um kernel e software de baixo nível que está entrelaçado com um kernel), o projeto pode escolher "não aplicável" (N/A) em vez disso, já que essa informação adicional não será útil para esses usuários. Da mesma forma, um projeto pode escolher N/A se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Listar as vulnerabilidades de todas as dependências transitivas de um projeto torna-se difícil conforme as dependências aumentam e variam, e é desnecessário já que ferramentas que examinam e rastreiam dependências podem fazer isso de uma forma mais escalável.

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

  Detalhes:

  A resposta PODE ser 'não' ou uma discussão sobre seus méritos. O objetivo é simplesmente que haja alguma resposta a algumas solicitações, o que indica que o projeto ainda está ativo. Para fins deste critério, os projetos não precisam contar solicitações falsas (por exemplo, de spammers ou sistemas automatizados). Se um projeto não estiver mais fazendo melhorias, selecione "não atendido" e inclua a URL que torna esta situação clara para os usuários. Se um projeto tende a ser sobrecarregado pelo número de solicitações de melhorias, selecione "não atendido" e explique.

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

  Detalhes:

  Projetos hospedados no GitHub DEVERIAM considerar habilitar o relato privado de uma vulnerabilidade de segurança. Projetos no GitLab DEVERIAM considerar usar sua capacidade de relatar uma vulnerabilidade de forma privada. Projetos PODEM identificar um endereço de e-mail em https://PROJECTSITE/security, frequentemente na forma security@example.org. Este processo de relato de vulnerabilidades PODE ser o mesmo que seu processo de relato de bugs. Relatórios de vulnerabilidades PODEM ser sempre públicos, mas muitos projetos têm um mecanismo de relato de vulnerabilidades privado.

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

  Detalhes:

  Exemplos incluem um relatório de defeito privado enviado na web usando HTTPS (TLS) ou um e-mail criptografado usando OpenPGP. Se relatórios de vulnerabilidades forem sempre públicos (portanto, nunca há relatórios privados de vulnerabilidades), escolha "não aplicável" (N/A).

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

  Detalhes:

  Se não houve vulnerabilidades relatadas nos últimos 6 meses, escolha "não aplicável" (N/A).

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]

  Detalhes:

  Um sistema de construção determina quais ações precisam ocorrer para reconstruir o software (e em que ordem), e então executa essas etapas. Por exemplo, ele pode invocar um compilador para compilar o código-fonte. Se um executável é criado a partir do código-fonte, deve ser possível modificar o código-fonte do projeto e então gerar um executável atualizado com essas modificações. Se o software produzido pelo projeto depende de bibliotecas externas, o sistema de construção não precisa construir essas bibliotecas externas. Se não houver necessidade de construir nada para usar o software depois que seu código-fonte for modificado, selecione "não aplicável" (N/A).

• É SUGERIDO que ferramentas comuns sejam usadas para construir o software. {N/A permitido} ^{[build_common_tools]}

  Detalhes:

  Por exemplo, Maven, Ant, cmake, o autotools, make, rake (Ruby) ou devtools (R).

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

  Detalhes:

  O projeto PODE usar múltiplos conjuntos de testes automatizados (por exemplo, um que executa rapidamente, versus outro que é mais completo mas requer equipamento especial). Existem muitos frameworks de teste e sistemas de suporte a testes disponíveis, incluindo Selenium (automação de navegador web), Junit (JVM, Java), RUnit (R), testthat (R).

• Um conjunto de testes DEVERIA ser invocável de forma padrão para aquela linguagem. ^{[test_invocation]}

  Detalhes:

  Por exemplo, "make check", "mvn test", ou "rake test" (Ruby).

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

  Detalhes:

  Desde que haja uma política, mesmo que verbal, que diga que desenvolvedores devem adicionar testes ao conjunto de testes automatizados para novas funcionalidades importantes, selecione "Met".

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

  Detalhes:

  Funcionalidade importante seria tipicamente mencionada nas notas de lançamento. Perfeição não é necessária, apenas evidências de que testes estão sendo tipicamente adicionados na prática ao conjunto de testes automatizados quando nova funcionalidade importante é adicionada ao software produzido pelo projeto.

• É SUGERIDO que esta política sobre adicionar testes (veja test_policy) seja documentada nas instruções para propostas de mudanças. ^{[tests_documented_added]}

  Detalhes:

  Contudo, mesmo uma regra informal é aceitável desde que os testes estejam sendo adicionados na prática.

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]

  Detalhes:

  Exemplos de flags de avisos do compilador incluem gcc/clang "-Wall". Exemplos de modo de linguagem "seguro" incluem JavaScript "use strict" e perl5 "use warnings". Uma ferramenta "linter" separada é simplesmente uma ferramenta que examina o código-fonte para procurar erros de qualidade de código ou erros comuns simples. Estes são tipicamente habilitados dentro do código-fonte ou instruções de compilação.

• O projeto DEVE tratar os avisos. {N/A permitido} ^{[warnings_fixed]}

  Detalhes:

  Estes são os avisos identificados pela implementação do critério warnings. O projeto deve corrigir avisos ou marcá-los no código-fonte como falsos positivos. Idealmente não haveria avisos, mas um projeto PODE aceitar alguns avisos (tipicamente menos de 1 aviso por 100 linhas ou menos de 10 avisos).

• É SUGERIDO que projetos sejam maximamente rigorosos com avisos no software produzido pelo projeto, onde prático. {N/A permitido} ^{[warnings_strict]}

  Detalhes:

  Alguns avisos não podem ser efetivamente habilitados em alguns projetos. O que é necessário é evidência de que o projeto está se esforçando para habilitar flags de avisos onde puder, de forma que erros sejam detectados cedo.

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

  Detalhes:

  Isto requer entender os seguintes princípios de projeto, incluindo os 8 princípios de Saltzer and Schroeder:

  • economia de mecanismo (mantenha o projeto tão simples e pequeno quanto prático, por exemplo, adotando simplificações amplas)
  • padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão)
  • mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável)
  • projeto aberto (mecanismos de segurança não devem depender da ignorância do invasor sobre seu projeto, mas sim em informações mais facilmente protegidas e alteradas como chaves e senhas)
  • separação de privilégios (idealmente, acesso a objetos importantes deve depender de mais de uma condição, de forma que derrotar um sistema de proteção não permita acesso completo. Por exemplo, autenticação multifator, como exigir tanto uma senha quanto um token de hardware, é mais forte que autenticação de fator único)
  • menor privilégio (processos devem operar com o menor privilégio necessário)
  • menor mecanismo comum (o projeto deve minimizar os mecanismos comuns a mais de um usuário e dos quais todos os usuários dependem, por exemplo, diretórios para arquivos temporários)
  • aceitabilidade psicológica (a interface humana deve ser projetada para facilidade de uso - projetar para "menor surpresa" pode ajudar)
  • superfície de ataque limitada (a superfície de ataque - o conjunto dos diferentes pontos onde um invasor pode tentar entrar ou extrair dados - deve ser limitada)
  • validação de entrada com listas de permissões (entradas devem tipicamente ser verificadas para determinar se são válidas antes de serem aceitas; esta validação deve usar listas de permissões (que aceitam apenas valores conhecidamente bons), não listas de negação (que tentam listar valores conhecidamente ruins)).

  Um "desenvolvedor principal" em um projeto é qualquer pessoa que esteja familiarizada com a base de código do projeto, esteja confortável fazendo mudanças nela, e seja reconhecida como tal pela maioria dos outros participantes no projeto. Um desenvolvedor principal tipicamente faria várias contribuições ao longo do último ano (via código, documentação ou respondendo perguntas). Desenvolvedores seriam tipicamente considerados desenvolvedores principais se iniciaram o projeto (e não deixaram o projeto há mais de três anos), têm a opção de receber informações em um canal privado de relato de vulnerabilidades (se houver um), podem aceitar commits em nome do projeto, ou realizar lançamentos finais do software do projeto. Se há apenas um desenvolvedor, esse indivíduo é o desenvolvedor principal. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir projeto. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o material).

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

  Detalhes:

  Exemplos (dependendo do tipo de software) incluem injeção SQL, injeção de SO, estouro clássico de buffer, cross-site scripting, autenticação ausente e autorização ausente. Veja o CWE/SANS top 25 ou OWASP Top 10 para listas comumente usadas. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir erros comuns de implementação que levam a vulnerabilidades. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o material).

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

  Detalhes:

  Esses critérios criptográficos nem sempre se aplicam porque alguns softwares não têm necessidade de usar diretamente capacidades criptográficas.

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

  Detalhes:

  Veja o Open Standards Requirement for Software by the Open Source Initiative.

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

  Detalhes:

  Esses comprimentos mínimos de bits são: chave simétrica 112, módulo de fatoração 2048, chave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 e hash 224 (hashing de senha não é coberto por este comprimento de bits, mais informações sobre hashing de senha podem ser encontradas no critério crypto_password_storage). Veja https://www.keylength.com para uma comparação de recomendações de comprimento de chave de várias organizações. O software PODE permitir comprimentos de chave menores em algumas configurações (idealmente não permitiria, já que isso permite ataques de downgrade, mas comprimentos de chave mais curtos são às vezes necessários para interoperabilidade).

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

  Detalhes:

  O modo ECB é quase nunca apropriado porque revela blocos idênticos dentro do texto cifrado conforme demonstrado pelo pinguim ECB, e o modo CTR é frequentemente inadequado porque não realiza autenticação e causa duplicatas se o estado de entrada for repetido. Em muitos casos é melhor escolher um modo de algoritmo de cifra de bloco projetado para combinar sigilo e autenticação, por exemplo, Galois/Counter Mode (GCM) e EAX. Projetos PODEM permitir que usuários habilitem mecanismos quebrados (por exemplo, durante a configuração) onde necessário para compatibilidade, mas então os usuários sabem que estão fazendo isso.

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

  Detalhes:

  Preocupações sobre o modo CBC em SSH são discutidas em CERT: SSH CBC vulnerability.

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

  Detalhes:

  Este critério aplica-se apenas quando o software está aplicando autenticação de usuários usando senhas para usuários externos (também conhecida como autenticação de entrada), como aplicações web do lado do servidor. Não se aplica em casos onde o software armazena senhas para autenticar em outros sistemas (também conhecida como autenticação de saída, por exemplo, o software implementa um cliente para algum outro sistema), já que pelo menos partes desse software devem ter acesso frequentemente à senha não hasheada.

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

  Detalhes:

  Um gerador de números aleatórios criptograficamente seguro pode ser um gerador de números aleatórios de hardware, ou pode ser um gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG) usando um algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Exemplos de chamadas para geradores de números aleatórios seguros incluem o java.security.SecureRandom do Java e o window.crypto.getRandomValues do JavaScript. Exemplos de chamadas para geradores de números aleatórios inseguros incluem o java.util.Random do Java e o Math.random do JavaScript.

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

  Detalhes:

  Um mecanismo ainda mais forte é liberar o software com pacotes assinados digitalmente, já que isso mitiga ataques no sistema de distribuição, mas isso só funciona se os usuários puderem estar confiantes de que as chaves públicas para assinaturas estão corretas e se os usuários realmente verificarão a assinatura.

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

  Detalhes:

  Esses hashes podem ser modificados durante o trânsito.

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

  Detalhes:

  A vulnerabilidade deve ser corrigida e lançada pelo próprio projeto (as correções podem ser desenvolvidas em outro lugar). Uma vulnerabilidade se torna publicamente conhecida (para este propósito) uma vez que tem um CVE com informações lançadas publicamente sem paywall (relatadas, por exemplo, no National Vulnerability Database) ou quando o projeto foi informado e a informação foi liberada ao público (possivelmente pelo projeto). Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente usado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade eles mesmos usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem publicamente reveladas uma vez que a vulnerabilidade seja publicamente conhecida. Nota: isso significa que os usuários podem ficar vulneráveis a todos os atacantes em todo o mundo por até 60 dias. Este critério é frequentemente muito mais fácil de atender do que o que o Google recomenda em Rebooting responsible disclosure, porque o Google recomenda que o período de 60 dias comece quando o projeto é notificado mesmo se o relatório não for público. Observe também que este critério de selo, como outros critérios, aplica-se ao projeto individual. Alguns projetos fazem parte de organizações guarda-chuva maiores ou projetos maiores, possivelmente em múltiplas camadas, e muitos projetos alimentam seus resultados para outras organizações e projetos como parte de uma cadeia de suprimentos potencialmente complexa. Um projeto individual geralmente não pode controlar o resto, mas um projeto individual pode trabalhar para lançar uma correção de vulnerabilidade de forma oportuna. Portanto, focamos apenas no tempo de resposta do projeto individual. Uma vez que uma correção esteja disponível do projeto individual, outros podem determinar como lidar com a correção (por exemplo, eles podem atualizar para a versão mais recente ou podem aplicar apenas a correção como uma solução cherry-picked).

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

  Detalhes:

  Um projeto PODE vazar credenciais "de amostra" para testes e bancos de dados sem importância, desde que não sejam destinadas a limitar o acesso público.

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

  Detalhes:

  Uma ferramenta de análise estática de código examina o código de software (como código-fonte, código intermediário ou executável) sem executá-lo com entradas específicas. Para fins deste critério, avisos do compilador e modos de linguagem "seguros" não contam como ferramentas de análise estática de código (estes tipicamente evitam análise profunda porque a velocidade é vital). Algumas ferramentas de análise estática focam na detecção de defeitos genéricos, outras focam em encontrar tipos específicos de defeitos (como vulnerabilidades), e algumas fazem uma combinação. Exemplos de tais ferramentas de análise estática de código incluem cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (incluindo FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy e HP Enterprise Fortify Static Code Analyzer. Listas maiores de ferramentas podem ser encontradas em lugares como a lista da Wikipedia de ferramentas para análise estática de código, informações da OWASP sobre análise estática de código, lista do NIST de analisadores de segurança de código-fonte e lista de ferramentas de análise estática de Wheeler. Se não houver ferramentas de análise estática FLOSS disponíveis para a(s) linguagem(ns) de implementação usada(s), você pode selecionar 'N/A'.

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

  Detalhes:

  Ferramentas de análise estática que são especificamente projetadas para procurar vulnerabilidades comuns são mais propensas a encontrá-las. Dito isso, usar quaisquer ferramentas estáticas normalmente ajudará a encontrar alguns problemas, então estamos sugerindo mas não exigindo isso para o nível de selo 'passing'.

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

  Detalhes:

  Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente usado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade eles mesmos usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem publicamente reveladas uma vez que a vulnerabilidade seja publicamente conhecida. Observe que o critério vulnerabilities_fixed_60_days exige que todas essas vulnerabilidades sejam corrigidas dentro de 60 dias de se tornarem públicas.

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

  Detalhes:

  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.

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

  Detalhes:

  Exemplos de mecanismos para detectar problemas de segurança de memória incluem Address Sanitizer (ASAN) (disponível no GCC e LLVM), Memory Sanitizer e valgrind. Outras ferramentas potencialmente usadas incluem thread sanitizer e undefined behavior sanitizer. Assertivas generalizadas também funcionariam.

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

  Detalhes:

  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.

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

  Detalhes:

  Se você não está executando análise dinâmica de código e, portanto, não encontrou nenhuma vulnerabilidade dessa forma, escolha "não aplicável" (N/A). Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente utilizado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade por conta própria usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem reveladas publicamente assim que a vulnerabilidade for conhecida publicamente.

Prata

Fundamentos

Pré-requisitos

• O projeto DEVE alcançar um distintivo de nível aprovado. ^{[achieve_passing]}

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]

  Detalhes:

  O DCO é o mecanismo recomendado porque é fácil de implementar, rastreado no código-fonte e o git suporta diretamente um recurso "signed-off" usando "commit -s". Para ser mais eficaz, é melhor que a documentação do projeto explique o que "signed-off" significa para aquele projeto. Um CLA é um acordo legal que define os termos sob os quais obras intelectuais foram licenciadas para uma organização ou projeto. Um contributor assignment agreement (CAA) é um acordo legal que transfere direitos em uma obra intelectual para outra parte; os projetos não são obrigados a ter CAAs, já que ter CAA aumenta o risco de que contribuidores potenciais não contribuam, especialmente se o receptor for uma organização com fins lucrativos. Os CLAs da Apache Software Foundation (a licença de contribuidor individual e o CLA corporativo) são exemplos de CLAs, para projetos que determinam que os riscos desses tipos de CLAs para o projeto são menores do que seus benefícios.

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

  Detalhes:

  É necessário haver alguma forma bem estabelecida e documentada de tomar decisões e resolver disputas. Em projetos pequenos, isso pode ser tão simples quanto "o proprietário do projeto e líder toma todas as decisões finais". Existem vários modelos de governança, incluindo ditador benevolente e meritocracia formal; para mais detalhes, consulte Modelos de governança. Tanto abordagens centralizadas (por exemplo, mantenedor único) quanto descentralizadas (por exemplo, grupo de mantenedores) foram usadas com sucesso em projetos. As informações de governança não precisam documentar a possibilidade de criar um fork do projeto, já que isso é sempre possível para projetos FLOSS.

• O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. {URL de atendimento} ^{[code_of_conduct]}

  Detalhes:

  Os projetos podem ser capazes de melhorar a civilidade de sua comunidade e estabelecer expectativas sobre conduta aceitável adotando um código de conduta. Isso pode ajudar a evitar problemas antes que ocorram e tornar o projeto um lugar mais acolhedor para encorajar contribuições. Isso deve se concentrar apenas no comportamento dentro da comunidade/local de trabalho do projeto. Exemplos de códigos de conduta são o código de conduta do kernel Linux, o Contributor Covenant Code of Conduct, o Código de Conduta Debian, o Código de Conduta Ubuntu, o Código de Conduta Fedora, o Código de Conduta GNOME, o Código de Conduta da Comunidade KDE, o Código de Conduta da Comunidade Python, A Diretriz de Conduta da Comunidade Ruby e O Código de Conduta do Rust.

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

  Detalhes:

  A documentação para governança e papéis e responsabilidades pode estar em um único lugar.

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

  Detalhes:

  Um "bus factor" (também conhecido como "truck factor") é o número mínimo de membros do projeto que precisam desaparecer repentinamente de um projeto ("ser atropelados por um ônibus") antes que o projeto pare devido à falta de pessoal conhecedor ou competente. A ferramenta truck-factor pode estimar isso para projetos no GitHub. Para mais informações, consulte Assessing the Bus Factor of Git Repositories de Cosentino et al.

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

  Detalhes:

  O projeto pode não alcançar o roadmap, e isso é aceitável; o objetivo do roadmap é ajudar usuários e contribuidores potenciais a entender a direção pretendida do projeto. Não precisa ser detalhado.

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

  Detalhes:

  Uma arquitetura de software explica as estruturas fundamentais de um programa, ou seja, os principais componentes do programa, os relacionamentos entre eles e as principais propriedades desses componentes e relacionamentos.

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

  Detalhes:

  Estes são os requisitos de segurança que o software deve atender.

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

  Detalhes:

  A ideia é mostrar aos usuários como começar e fazer o software fazer qualquer coisa. Isso é extremamente importante para que potenciais usuários comecem.

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

  Detalhes:

  A documentação PODE incluir informações sobre diferenças ou mudanças entre versões do software e/ou link para versões antigas da documentação. A intenção deste critério é que um esforço seja feito para manter a documentação consistente, não que a documentação deva ser perfeita.

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

  Detalhes:

  Uma conquista é qualquer conjunto de critérios externos que o projeto trabalhou especificamente para atender, incluindo alguns selos. Esta informação não precisa estar na página inicial do site do projeto. Um projeto usando o GitHub pode colocar conquistas na página inicial do repositório adicionando-as ao arquivo README.

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

  Detalhes:

  Para aplicações web, veja as Diretrizes de Acessibilidade para Conteúdo Web (WCAG 2.0) e seu documento de apoio Understanding WCAG 2.0; veja também informações de acessibilidade do W3C. Para aplicações GUI, considere usar as diretrizes de acessibilidade específicas do ambiente (como Gnome, KDE, XFCE, Android, iOS, Mac e Windows). Algumas aplicações TUI (por exemplo, programas `ncurses`) podem fazer certas coisas para se tornarem mais acessíveis (como a configuração `force-arrow-cursor` do `alpine`). A maioria das aplicações de linha de comando são bastante acessíveis como estão. Este critério é frequentemente N/A, por exemplo, para bibliotecas de programas. Aqui estão alguns exemplos de ações a tomar ou questões a considerar:

  • Forneça alternativas de texto para qualquer conteúdo não textual para que possa ser transformado em outras formas que as pessoas precisam, como letras grandes, braille, fala, símbolos ou linguagem mais simples (diretriz WCAG 2.0 1.1)
  • A cor não é usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. (diretriz WCAG 2.0 1.4.1)
  • A apresentação visual de texto e imagens de texto tem uma razão de contraste de pelo menos 4.5:1, exceto para texto grande, texto incidental e logotipos (diretriz WCAG 2.0 1.4.3)
  • Torne toda a funcionalidade disponível a partir de um teclado (diretriz WCAG 2.1)
  • Um projeto GUI ou baseado na web DEVERIA testar com pelo menos um leitor de tela nas plataformas de destino (por exemplo, NVDA, Jaws ou WindowEyes no Windows; VoiceOver no Mac & iOS; Orca no Linux/BSD; TalkBack no Android). Programas TUI PODEM trabalhar para reduzir o redesenho para evitar leitura redundante por leitores de tela.

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

  Detalhes:

  Localização "refere-se à adaptação de um produto, aplicação ou conteúdo de documento para atender aos requisitos de idioma, cultura e outros de um mercado-alvo específico (um locale)". Internacionalização é o "projeto e desenvolvimento de um produto, aplicação ou conteúdo de documento que permite fácil localização para públicos-alvo que variam em cultura, região ou idioma". (Veja "Localization vs. Internationalization" do W3C.) O software atende a este critério simplesmente sendo internacionalizado. Nenhuma localização para outro idioma específico é necessária, pois uma vez que o software foi internacionalizado, é possível para outros trabalharem na localização.

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

  Detalhes:

  Observe que o uso do GitHub atende a este critério. Este critério aplica-se apenas a senhas usadas para autenticação de usuários externos nos sites do projeto (também conhecida como autenticação de entrada). Se os sites do projeto precisam fazer login em outros sites (também conhecida como autenticação de saída), eles podem precisar armazenar tokens de autorização para esse propósito de forma diferente (já que armazenar um hash seria inútil). Isso aplica o critério crypto_password_storage aos sites do projeto, semelhante a sites_https.

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

  Detalhes:

  Isso está fortemente relacionado a vulnerability_report_process, que exige que haja uma forma documentada de relatar vulnerabilidades. Também está relacionado a vulnerability_report_response, que exige resposta a relatos de vulnerabilidades dentro de um determinado prazo.

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

  Detalhes:

  Na maioria dos casos, isso é feito referenciando algum(ns) guia(s) de estilo existente(s), possivelmente listando diferenças. Esses guias de estilo podem incluir maneiras de melhorar a legibilidade e maneiras de reduzir a probabilidade de defeitos (incluindo vulnerabilidades). Muitas linguagens de programação têm um ou mais guias de estilo amplamente utilizados. Exemplos de guias de estilo incluem guias de estilo do Google e Padrões de Codificação SEI CERT.

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

  Detalhes:

  Isso PODE ser implementado usando ferramenta(s) de análise estática e/ou forçando o código através de reformatadores de código. Em muitos casos, a configuração da ferramenta está incluída no repositório do projeto (já que projetos diferentes podem escolher configurações diferentes). Os projetos PODEM permitir exceções de estilo (e normalmente permitirão); onde ocorrem exceções, elas DEVEM ser raras e documentadas no código em suas localizações, para que essas exceções possam ser revisadas e para que as ferramentas possam tratá-las automaticamente no futuro. Exemplos de tais ferramentas incluem ESLint (JavaScript), Rubocop (Ruby) e devtools check (R).

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

  Detalhes:

  Deve ser fácil habilitar recursos especiais de compilação como Address Sanitizer (ASAN), ou cumprir as melhores práticas de proteção de distribuição (por exemplo, ativando facilmente flags de compilador para fazê-lo).

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

  Detalhes:

  Por exemplo, definir CFLAGS (C) ou CXXFLAGS (C++) deve criar as informações de depuração relevantes se essas linguagens forem usadas, e elas não devem ser removidas durante a instalação. Informações de depuração são necessárias para suporte e análise, e também úteis para medir a presença de recursos de proteção nos binários compilados.

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

  Detalhes:

  As informações de dependência interna do sistema de compilação do projeto precisam ser precisas, caso contrário, mudanças no projeto podem não compilar corretamente. Compilações incorretas podem levar a defeitos (incluindo vulnerabilidades). Um erro comum em sistemas de compilação grandes é usar uma "compilação recursiva" ou "make recursivo", isto é, uma hierarquia de subdiretórios contendo arquivos fonte, onde cada subdiretório é compilado independentemente. A menos que cada subdiretório seja totalmente independente, isso é um erro, porque as informações de dependência estão incorretas.

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

  Detalhes:

  Usuários de GCC e clang podem achar útil a opção -frandom-seed; em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Mais sugestões podem ser encontradas no site reproducible build.

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

  Detalhes:

  Exemplos incluem usar um gerenciador de pacotes (no nível do sistema ou da linguagem), "make install/uninstall" (suportando DESTDIR), um contêiner em formato padrão, ou uma imagem de máquina virtual em formato padrão. O processo de instalação e desinstalação (por exemplo, seu empacotamento) PODE ser implementado por terceiros, desde que seja FLOSS.

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

  Detalhes:

  Isso PODE ser implementado usando um contêiner gerado e/ou script(s) de instalação. Dependências externas normalmente seriam instaladas invocando gerenciador(es) de pacotes do sistema e/ou da linguagem, conforme external_dependencies.

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

  Detalhes:

  Tipicamente isso é feito usando as convenções do gerenciador de pacotes e/ou sistema de compilação. Note que isso ajuda a implementar installation_development_quick.

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

  Detalhes:

  Isso pode ser feito usando uma ferramenta de análise de origem / ferramenta de verificação de dependências / ferramenta de análise de composição de software como OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis e Bundler-audit (para Ruby). Alguns gerenciadores de pacotes incluem mecanismos para fazer isso. É aceitável se a vulnerabilidade dos componentes não puder ser explorada, mas esta análise é difícil e às vezes é mais fácil simplesmente atualizar ou corrigir a parte.

• "O projeto DEVE:
  1. facilitar a identificação e atualização de componentes mantidos externamente reutilizados; ou
  2. 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]}

  Detalhes:

  Uma maneira típica de atender a este critério é usar sistemas de gerenciamento de pacotes do sistema e da linguagem de programação. Muitos programas FLOSS são distribuídos com "bibliotecas de conveniência" que são cópias locais de bibliotecas padrão (possivelmente bifurcadas). Por si só, isso é bom. No entanto, se o programa *deve* usar essas cópias locais (bifurcadas), então atualizar as bibliotecas "padrão" como uma atualização de segurança deixará essas cópias adicionais ainda vulneráveis. Isso é especialmente um problema para sistemas baseados em nuvem; se o provedor de nuvem atualizar suas bibliotecas "padrão", mas o programa não as usar, então as atualizações na verdade não ajudam. Veja, por exemplo, "Chromium: Why it isn't in Fedora yet as a proper package" by Tom Callaway.

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

  Detalhes:

  Este requisito pode ser visto como um subconjunto de test_continuous_integration, mas focado apenas em testes, sem exigir integração contínua.

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

  Detalhes:

  Muitas ferramentas FLOSS estão disponíveis para medir cobertura de testes, incluindo gcov/lcov, Blanket.js, Istanbul, JCov e covr (R). Note que atender a este critério não é uma garantia de que a suíte de testes seja completa, em vez disso, falhar em atender a este critério é um forte indicador de uma suíte de testes pobre.

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

  Detalhes:

  Por exemplo, os resultados do projeto devem ter padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão). Eles também devem ter mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável). Note que em alguns casos os princípios entrarão em conflito, caso em que uma escolha deve ser feita (por exemplo, muitos mecanismos podem tornar as coisas mais complexas, contrariando a "economia de mecanismo" / mantenha simples).

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

  Detalhes:

  Observe que a verificação incorreta de certificado TLS é um erro comum. Para mais informações, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. e "Do you trust this application?" por Michael Catanzaro.

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

  Detalhes:

  Os resultados do projeto incluem tanto o código-fonte quanto quaisquer entregáveis gerados quando aplicável (por exemplo, executáveis, pacotes e contêineres). Os entregáveis gerados PODEM ser assinados separadamente do código-fonte. Estes PODEM ser implementados como tags git assinadas (usando assinaturas digitais criptográficas). Os projetos PODEM fornecer resultados gerados separadamente de ferramentas como git, mas nesses casos, os resultados separados DEVEM ser assinados separadamente.

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

  Detalhes:

  Observe que comparar a entrada com uma lista de "formatos inválidos" (também conhecida como *lista de negação*) normalmente não é suficiente, porque os atacantes muitas vezes podem contornar uma lista de negação. Em particular, os números são convertidos em formatos internos e então verificados se estão entre o mínimo e o máximo (inclusive), e as strings de texto são verificadas para garantir que sejam padrões de texto válidos (por exemplo, UTF-8 válido, comprimento, sintaxe, etc.). Alguns dados podem precisar ser "qualquer coisa" (por exemplo, um carregador de arquivos), mas estes normalmente seriam raros.

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

  Detalhes:

  Os mecanismos de proteção podem incluir cabeçalhos HTTP como Content Security Policy (CSP), flags de compilador para mitigar ataques (como -fstack-protector), ou flags de compilador para eliminar comportamento indefinido. Para nossos propósitos, o privilégio mínimo não é considerado um mecanismo de proteção (privilégio mínimo é importante, mas separado).

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

  Detalhes:

  Um caso de garantia é "um corpo documentado de evidências que fornece um argumento convincente e válido de que um conjunto específico de reivindicações críticas sobre as propriedades de um sistema são adequadamente justificadas para uma dada aplicação em um dado ambiente" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Limites de confiança são fronteiras onde os dados ou a execução muda seu nível de confiança, por exemplo, os limites de um servidor em uma aplicação web típica. É comum listar princípios de projeto seguro (como Saltzer e Schroeer) e fraquezas comuns de segurança na implementação (como o OWASP top 10 ou CWE/SANS top 25), e mostrar como cada um é combatido. O caso de garantia do BadgeApp pode ser um exemplo útil. Isso está relacionado a documentation_security, documentation_architecture e implement_secure_design.

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

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

Nível Básico 1

Geral

Controles

• Quando um usuário tentar ler ou modificar um recurso sensível no repositório autorizado do projeto, o sistema DEVE exigir que o usuário complete um processo de autenticação multifator. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_01_01]}

  Detalhes:

  Imponha autenticação multifator para o sistema de controle de versão do projeto, exigindo que os colaboradores forneçam uma segunda forma de autenticação ao acessar dados sensíveis ou modificar configurações do repositório. Passkeys são aceitáveis para este controle.

• Quando um novo colaborador for adicionado, o sistema de controle de versão DEVE exigir atribuição manual de permissão, ou restringir as permissões do colaborador aos menores privilégios disponíveis por padrão. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_02_01]}

  Detalhes:

  A maioria dos sistemas públicos de controle de versão são configurados desta maneira. Certifique-se de que o sistema de controle de versão do projeto sempre atribua as menores permissões disponíveis aos colaboradores por padrão quando adicionados, concedendo permissões adicionais somente quando necessário.

• Quando uma confirmação direta for tentada no ramo principal do projeto, um mecanismo de aplicação DEVE impedir que a mudança seja aplicada. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_03_01]}

  Detalhes:

  Se o VCS for centralizado, defina proteção de ramo no ramo principal no VCS do projeto. Alternativamente, use uma abordagem descentralizada, como a do kernel Linux, onde as mudanças são primeiro propostas em outro repositório, e mesclar mudanças no repositório principal requer um ato separado específico.

• Quando for feita uma tentativa de excluir o ramo principal do projeto, o sistema de controle de versão DEVE tratar isso como uma atividade sensível e exigir confirmação explícita de intenção. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_03_02]}

  Detalhes:

  Defina proteção de ramo no ramo principal no sistema de controle de versão do projeto para evitar exclusão.

• Quando um pipeline de CI/CD aceitar um parâmetro de entrada, esse parâmetro DEVE ser sanitizado e validado antes de ser usado no pipeline. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_01_01]}
• Quando um pipeline de CI/CD usar um nome de ramo em sua funcionalidade, esse valor de nome DEVE ser sanitizado e validado antes de ser usado no pipeline. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_01_02]}
• Quando o projeto listar um URI como um canal oficial do projeto, esse URI DEVE ser entregue exclusivamente usando canais criptografados. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_03_01]}

  Detalhes:

  Configure os sites do projeto e os sistemas de controle de versão para usar canais criptografados como SSH ou HTTPS para transmissão de dados. Certifique-se de que todas as ferramentas e domínios referenciados na documentação do projeto só possam ser acessados por meio de canais criptografados.

• Quando o projeto listar um URI como um canal oficial de distribuição, esse URI DEVE ser entregue exclusivamente usando canais criptografados. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_03_02]}

  Detalhes:

  Configure o pipeline de lançamento do projeto para buscar dados apenas de sites, respostas de API e outros serviços que usam canais criptografados como SSH ou HTTPS para transmissão de dados.

• O projeto DEVE impedir o armazenamento não intencional de dados sensíveis não criptografados, como segredos e credenciais, no sistema de controle de versão. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_07_01]}

  Detalhes:

  Configure .gitignore ou equivalente para excluir arquivos que possam conter informações sensíveis. Use hooks de pré-commit e ferramentas de varredura automatizadas para detectar e prevenir a inclusão de dados sensíveis em commits.

• Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir guias do usuário para todas as funcionalidades básicas. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_01_01]}

  Detalhes:

  Crie guias do usuário ou documentação para todas as funcionalidades básicas do projeto, explicando como instalar, configurar e usar os recursos do projeto. Se houver quaisquer ações perigosas ou destrutivas conhecidas disponíveis, inclua avisos altamente visíveis.

• Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir um guia para relatar defeitos. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_02_01]}

  Detalhes:

  É recomendado que os projetos usem o rastreador de issues padrão do seu VCS. Se uma fonte externa for usada, certifique-se de que a documentação do projeto e o guia de contribuição expliquem de forma clara e visível como usar o sistema de relatório. É recomendado que a documentação do projeto também estabeleça expectativas sobre como os defeitos serão triados e resolvidos.

• Enquanto ativo, o projeto DEVE ter um ou mais mecanismos para discussões públicas sobre mudanças propostas e obstáculos de uso. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_02_01]}

  Detalhes:

  Estabeleça um ou mais mecanismos para discussões públicas dentro do projeto, como listas de discussão, mensagens instantâneas ou rastreadores de issues, para facilitar a comunicação aberta e feedback.

• Enquanto ativo, a documentação do projeto DEVE incluir uma explicação do processo de contribuição. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_03_01]}

  Detalhes:

  Crie um CONTRIBUTING.md ou diretório CONTRIBUTING/ para delinear o processo de contribuição incluindo as etapas para enviar mudanças e se engajar com os mantenedores do projeto.

• Enquanto ativo, a licença para o código-fonte DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. {Justificativa de N/A} {URL de atendimento} ^{[osps_le_02_01]}

  Detalhes:

  Adicione um arquivo LICENSE ao repositório do projeto com uma licença que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Lançar para o domínio público atende a este controle se não houver outros obstáculos como patentes.

• Enquanto ativo, a licença para os ativos de software lançados DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. {Justificativa de N/A} {URL de atendimento} ^{[osps_le_02_02]}

  Detalhes:

  Se uma licença diferente for incluída com ativos de software lançados, certifique-se de que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Note que a licença para os ativos de software lançados pode ser diferente do código-fonte.

• Enquanto ativo, a licença para o código-fonte DEVE ser mantida no arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ do repositório correspondente. {Justificativa de N/A} {URL de atendimento} ^{[osps_le_03_01]}

  Detalhes:

  Inclua a licença do código-fonte do projeto no arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ do projeto para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

• Enquanto ativo, a licença para os ativos de software lançados DEVE ser incluída no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes. {Justificativa de N/A} {URL de atendimento} ^{[osps_le_03_02]}

  Detalhes:

  Inclua a licença dos ativos de software lançados do projeto no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

• Enquanto ativo, o repositório de código-fonte do projeto DEVE ser publicamente legível em uma URL estática. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_01_01]}

  Detalhes:

  Use um VCS comum como GitHub, GitLab ou Bitbucket. Certifique-se de que o repositório seja publicamente legível. Evite duplicação ou espelhamento de repositórios a menos que documentação altamente visível esclareça a fonte primária. Evite mudanças frequentes no repositório que impactariam a URL do repositório. Certifique-se de que o repositório seja público.

• O sistema de controle de versão DEVE conter um registro publicamente legível de todas as alterações feitas, quem fez as alterações e quando as alterações foram feitas. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_01_02]}

  Detalhes:

  Use um VCS comum como GitHub, GitLab ou Bitbucket para manter um histórico de commits publicamente legível. Evite esmagar ou reescrever commits de uma forma que obscureça o autor de quaisquer commits.

• Quando o sistema de gerenciamento de pacotes suportar, o repositório de código-fonte DEVE conter uma lista de dependências que representa as dependências diretas da linguagem. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_02_01]}

  Detalhes:

  Isso pode assumir a forma de um arquivo de dependências de gerenciador de pacotes ou linguagem que enumera todas as dependências diretas, como package.json, Gemfile ou go.mod.

• Enquanto ativo, a documentação do projeto DEVE conter uma lista de quaisquer bases de código que sejam consideradas subprojetos. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_04_01]}

  Detalhes:

  Documente quaisquer repositórios de código de subprojetos adicionais produzidos pelo projeto e compilados em uma versão de lançamento. Esta documentação deve incluir o status e a intenção da respectiva base de código.

• Enquanto ativo, o sistema de controle de versão NÃO DEVE conter artefatos executáveis gerados. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_05_01]}

  Detalhes:

  Remova artefatos executáveis gerados no sistema de controle de versão do projeto. É recomendado que qualquer cenário em que um artefato executável gerado apareça como crítico para um processo, como testes, ele deve ser gerado no momento da compilação ou armazenado separadamente e buscado durante uma etapa de pipeline específica e bem documentada.

• Enquanto ativo, o sistema de controle de versão NÃO DEVE conter artefatos binários não revisáveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_05_02]}

  Detalhes:

  Não adicione nenhum artefato binário não revisável ao sistema de controle de versão do projeto. Isso inclui binários de aplicativos executáveis, arquivos de biblioteca e artefatos similares. Não inclui recursos como imagens gráficas, arquivos de som ou música e conteúdo similar normalmente armazenado em formato binário.

• Enquanto ativo, a documentação do projeto DEVE conter contatos de segurança. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_02_01]}

  Detalhes:

  Crie um arquivo security.md (ou com nome similar) que contenha contatos de segurança para o projeto.

Nível Básico 2

Geral

Controles

• Quando uma tarefa de CI/CD é executada sem permissões especificadas, o sistema de CI/CD DEVE definir como padrão as permissões da tarefa para as menores permissões concedidas no pipeline. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_04_01]}

  Detalhes:

  Configure as definições do projeto para atribuir as menores permissões disponíveis a novos pipelines por padrão, concedendo permissões adicionais somente quando necessário para tarefas específicas.

• Quando um lançamento oficial é criado, esse lançamento DEVE receber um identificador de versão único. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_02_01]}

  Detalhes:

  Atribua um identificador de versão único a cada versão de lançamento produzida pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit git.

• Quando um lançamento oficial é criado, esse lançamento DEVE conter um registro descritivo de modificações funcionais e de segurança. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_04_01]}

  Detalhes:

  Certifique-se de que todos os lançamentos incluam um registro de alterações descritivo. É recomendado garantir que o registro de alterações seja legível por humanos e inclua detalhes além das mensagens de commit, como descrições do impacto de segurança ou relevância para diferentes casos de uso. Para garantir a legibilidade por máquina, coloque o conteúdo sob um cabeçalho markdown como \"## Changelog\"."

• Quando um pipeline de compilação e lançamento ingere dependências, ele DEVE usar ferramentas padronizadas quando disponíveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_05_01]}

  Detalhes:

  Use ferramentas comuns para o seu ecossistema, como gerenciadores de pacotes ou ferramentas de gerenciamento de dependências para ingerir dependências no momento da compilação. Isso pode incluir o uso de um arquivo de dependências, arquivo de bloqueio ou manifesto para especificar as dependências necessárias, que são então incorporadas pelo sistema de compilação.

• Quando um lançamento oficial é criado, esse lançamento DEVE ser assinado ou contabilizado em um manifesto assinado incluindo os hashes criptográficos de cada ativo. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_06_01]}

  Detalhes:

  Assine todos os ativos de software lançados no momento da construção com uma assinatura criptográfica ou atestados, como assinatura GPG ou PGP, assinaturas Sigstore, proveniência SLSA ou VSAs SLSA. Inclua os hashes criptográficos de cada ativo em um manifesto assinado ou arquivo de metadados.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma descrição de como o projeto seleciona, obtém e rastreia suas dependências. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_06_01]}

  Detalhes:

  É recomendado publicar essas informações juntamente com a documentação técnica e de design do projeto em um recurso publicamente visível, como o repositório de código-fonte, site do projeto ou outro canal.

• Enquanto ativo, a documentação do projeto DEVE incluir uma lista de membros do projeto com acesso a recursos sensíveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_01_01]}

  Detalhes:

  Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto. Isso pode ser tão simples quanto incluir nomes ou identificadores de conta em uma lista de mantenedores, ou mais complexo dependendo da governança do projeto.

• Enquanto ativo, a documentação do projeto DEVE incluir descrições dos papéis e responsabilidades dos membros do projeto. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_01_02]}

  Detalhes:

  Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto.

• Enquanto ativo, a documentação do projeto DEVE incluir um guia para contribuidores de código que inclui requisitos para contribuições aceitáveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_03_02]}

  Detalhes:

  Estenda o conteúdo de CONTRIBUTING.md ou CONTRIBUTING/ na documentação do projeto para delinear os requisitos para contribuições aceitáveis, incluindo padrões de codificação, requisitos de testes e diretrizes de submissão para contribuidores de código. É recomendado que este guia seja a fonte da verdade tanto para contribuidores quanto para aprovadores.

• Enquanto ativo, o sistema de controle de versão DEVE exigir que todos os contribuidores de código afirmem que estão legalmente autorizados a fazer as contribuições associadas em cada commit. {Justificativa de N/A} {URL de atendimento} ^{[osps_le_01_01]}

  Detalhes:

  Inclua um DCO no repositório do projeto, exigindo que os contribuidores de código afirmem que estão legalmente autorizados a confirmar as contribuições associadas em cada commit. Use uma verificação de status para garantir que a afirmação seja feita. Um CLA também satisfaz este requisito. Alguns sistemas de controle de versão, como o GitHub, podem incluir isso nos termos de serviço da plataforma.

• Quando um commit é feito na branch primária, quaisquer verificações de status automatizadas para commits DEVEM passar ou ser manualmente ignoradas. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_03_01]}

  Detalhes:

  Configure o sistema de controle de versão do projeto para exigir que todas as verificações de status automatizadas passem ou exijam reconhecimento manual antes que um commit possa ser mesclado na branch primária. É recomendado que quaisquer verificações de status opcionais NÃO sejam configuradas como um requisito de aprovação ou reprovação que os aprovadores possam ser tentados a ignorar.

• Antes de um commit ser aceito, os pipelines de CI/CD do projeto DEVEM executar pelo menos um conjunto de testes automatizados para garantir que as alterações atendam às expectativas. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_06_01]}

  Detalhes:

  Testes automatizados devem ser executados antes de cada mesclagem na branch primária. O conjunto de testes deve ser executado em um pipeline de CI/CD e os resultados devem ser visíveis a todos os contribuidores. O conjunto de testes deve ser executado em um ambiente consistente e deve ser executado de uma maneira que permita aos contribuidores executar os testes localmente. Exemplos de conjuntos de testes incluem testes unitários, testes de integração e testes de ponta a ponta.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir documentação de design demonstrando todas as ações e atores dentro do sistema. {Justificativa de N/A} {URL de atendimento} ^{[osps_sa_01_01]}

  Detalhes:

  Inclua designs na documentação do projeto que expliquem as ações e atores. Atores incluem qualquer subsistema ou entidade que possa influenciar outro segmento no sistema. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir descrições de todas as interfaces de software externas dos ativos de software lançados. {Justificativa de N/A} {URL de atendimento} ^{[osps_sa_02_01]}

  Detalhes:

  Documente todas as interfaces de software (APIs) dos ativos de software lançados, explicando como os usuários podem interagir com o software e quais dados são esperados ou produzidos. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

• Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma avaliação de segurança para compreender os problemas de segurança potenciais mais prováveis e impactantes que poderiam ocorrer dentro do software. {Justificativa de N/A} {URL de atendimento} ^{[osps_sa_03_01]}

  Detalhes:

  Realizar uma avaliação de segurança informa tanto os membros do projeto quanto os consumidores a jusante que o projeto compreende quais problemas poderiam surgir dentro do software. Compreender quais ameaças poderiam se concretizar ajuda o projeto a gerenciar e tratar riscos. Essa informação é útil para os consumidores a jusante demonstrarem a perspicácia e as práticas de segurança do projeto. Certifique-se de que isso seja atualizado para novos recursos ou mudanças disruptivas.

• Enquanto ativo, a documentação do projeto DEVE incluir uma política para divulgação coordenada de vulnerabilidades (CVD), com um prazo claro para resposta. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_01_01]}

  Detalhes:

  Crie um arquivo SECURITY.md na raiz do diretório, descrevendo a política do projeto para divulgação coordenada de vulnerabilidades. Inclua um método para relatar vulnerabilidades. Estabeleça expectativas sobre como o projeto responderá e tratará problemas relatados.

• Enquanto ativo, a documentação do projeto DEVE fornecer um meio para relato privado de vulnerabilidades diretamente aos contatos de segurança dentro do projeto. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_03_01]}

  Detalhes:

  Forneça um meio para que pesquisadores de segurança relatem vulnerabilidades privadamente ao projeto. Isso pode ser um endereço de e-mail dedicado, um formulário web, ferramentas especializadas do VCS, endereços de e-mail para contatos de segurança ou outros métodos.

• Enquanto ativo, a documentação do projeto DEVE publicar publicamente dados sobre vulnerabilidades descobertas. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_04_01]}

  Detalhes:

  Forneça informações sobre vulnerabilidades conhecidas em um canal público previsível, como uma entrada CVE, postagem em blog ou outro meio. Na medida do possível, essa informação deve incluir versão(ões) afetada(s), como um consumidor pode determinar se está vulnerável e instruções para mitigação ou remediação.

Nível Básico 3

Geral

Controles

• Quando um trabalho recebe permissões em um pipeline de CI/CD, o código-fonte ou configuração DEVE atribuir apenas os privilégios mínimos necessários para a atividade correspondente. {Justificativa de N/A} {URL de atendimento} ^{[osps_ac_04_02]}

  Detalhes:

  Configure os pipelines de CI/CD do projeto para atribuir as menores permissões disponíveis a usuários e serviços por padrão, elevando as permissões apenas quando necessário para tarefas específicas. Em alguns sistemas de controle de versão, isso pode ser possível no nível organizacional ou de repositório. Se não, defina permissões no nível superior do pipeline.

• Quando um lançamento oficial for criado, todos os ativos dentro desse lançamento DEVEM estar claramente associados ao identificador de lançamento ou outro identificador único para o ativo. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_02_02]}

  Detalhes:

  Atribua um identificador de versão único a cada ativo de software produzido pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit do git.

• O projeto DEVE definir uma política para gerenciar segredos e credenciais usadas pelo projeto. A política deve incluir diretrizes para armazenar, acessar e rotacionar segredos e credenciais. {Justificativa de N/A} {URL de atendimento} ^{[osps_br_07_02]}

  Detalhes:

  Documente como segredos e credenciais são gerenciados e usados dentro do projeto. Isso deve incluir detalhes sobre como os segredos são armazenados (por exemplo, usando uma ferramenta de gerenciamento de segredos), como o acesso é controlado e como os segredos são rotacionados ou atualizados. Certifique-se de que informações sensíveis não sejam codificadas diretamente no código-fonte ou armazenadas em sistemas de controle de versão.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a integridade e autenticidade dos ativos de lançamento. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_03_01]}

  Detalhes:

  As instruções no projeto devem conter informações sobre a tecnologia usada, os comandos a serem executados e a saída esperada. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a identidade esperada da pessoa ou processo que criou o lançamento de software. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_03_02]}

  Detalhes:

  A identidade esperada pode estar na forma de IDs de chave usados para assinar, emissor e identidade de um certificado sigstore ou outras formas similares. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma declaração descritiva sobre o escopo e a duração do suporte para cada lançamento. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_04_01]}

  Detalhes:

  Para comunicar o escopo e a duração do suporte para os ativos de software lançados pelo projeto, o projeto deve ter um arquivo SUPPORT.md, uma seção "Support" em SECURITY.md ou outra documentação explicando o ciclo de vida do suporte, incluindo a duração esperada de suporte para cada lançamento, os tipos de suporte fornecidos (por exemplo, correções de bugs, atualizações de segurança) e quaisquer políticas ou procedimentos relevantes para obter suporte.

• Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE fornecer uma declaração descritiva de quando lançamentos ou versões não receberão mais atualizações de segurança. {Justificativa de N/A} {URL de atendimento} ^{[osps_do_05_01]}

  Detalhes:

  Para comunicar o escopo e a duração do suporte para correções de segurança, o projeto deve ter um SUPPORT.md ou outra documentação explicando a política do projeto para atualizações de segurança.

• Enquanto ativo, a documentação do projeto DEVE ter uma política de que colaboradores de código sejam revisados antes de conceder permissões elevadas a recursos sensíveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_gv_04_01]}

  Detalhes:

  Publique uma política aplicável na documentação do projeto que exija que colaboradores de código sejam revisados e aprovados antes de receberem permissões elevadas a recursos sensíveis, como aprovação de merge ou acesso a segredos. É recomendado que a verificação inclua estabelecer uma linhagem justificável de identidade, como confirmar a associação do contribuidor com uma organização confiável conhecida.

• Quando o projeto tiver feito um lançamento, todos os ativos de software compilados lançados DEVEM ser entregues com uma lista de materiais de software. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_02_02]}

  Detalhes:

  É recomendado gerar automaticamente SBOMs no momento da compilação usando uma ferramenta que foi verificada quanto à precisão. Isso permite que os usuários ingiram esses dados de forma padronizada junto com outros projetos em seu ambiente.

• Quando o projeto tiver feito um lançamento compreendendo múltiplos repositórios de código-fonte, todos os subprojetos DEVEM impor requisitos de segurança que sejam tão rigorosos ou mais rigorosos que a base de código principal. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_04_02]}

  Detalhes:

  Quaisquer repositórios de código de subprojeto adicionais produzidos pelo projeto e compilados em um lançamento devem impor requisitos de segurança conforme aplicável ao status e intenção da respectiva base de código. Além de seguir os requisitos correspondentes da Linha de Base OSPS, isso pode incluir exigir uma revisão de segurança, garantir que esteja livre de vulnerabilidades e garantir que esteja livre de problemas de segurança conhecidos.

• Enquanto ativo, a documentação do projeto DEVE documentar claramente quando e como os testes são executados. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_06_02]}

  Detalhes:

  Adicione uma seção à documentação de contribuição que explique como executar os testes localmente e como executar os testes no pipeline de CI/CD. A documentação deve explicar o que os testes estão testando e como interpretar os resultados.

• Enquanto ativo, a documentação do projeto DEVE incluir uma política de que todas as mudanças importantes no software produzido pelo projeto devem adicionar ou atualizar testes da funcionalidade em um conjunto de testes automatizados. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_06_03]}

  Detalhes:

  Adicione uma seção à documentação de contribuição que explique a política para adicionar ou atualizar testes. A política deve explicar o que constitui uma mudança importante e quais testes devem ser adicionados ou atualizados.

• Quando um commit for feito no branch principal, o sistema de controle de versão do projeto DEVE exigir pelo menos uma aprovação humana não-autora das mudanças antes do merge. {Justificativa de N/A} {URL de atendimento} ^{[osps_qa_07_01]}

  Detalhes:

  Configure o sistema de controle de versão do projeto para exigir pelo menos uma aprovação humana não-autora das mudanças antes de fazer merge no branch de lançamento ou principal. Isso pode ser alcançado exigindo que um pull request seja revisado e aprovado por pelo menos um outro colaborador antes que possa ser feito o merge.

• Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma modelagem de ameaças e análise de superfície de ataque para entender e proteger contra ataques em caminhos de código críticos, funções e interações dentro do sistema. {Justificativa de N/A} {URL de atendimento} ^{[osps_sa_03_02]}

  Detalhes:

  Modelagem de ameaças é uma atividade onde o projeto analisa a base de código, processos e infraestrutura associados, interfaces, componentes-chave e "pensa como um hacker" e faz um brainstorming de como o sistema pode ser quebrado ou comprometido. Cada ameaça identificada é listada para que o projeto possa então pensar em como evitar proativamente ou fechar quaisquer lacunas/vulnerabilidades que possam surgir. Certifique-se de que isso seja atualizado para novos recursos ou mudanças críticas.

• Enquanto ativo, quaisquer vulnerabilidades nos componentes de software que não afetam o projeto DEVEM ser contabilizadas em um documento VEX, aumentando o relatório de vulnerabilidade com detalhes de não-explorabilidade. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_04_02]}

  Detalhes:

  Estabeleça um feed VEX comunicando o status de explorabilidade de vulnerabilidades conhecidas, incluindo detalhes de avaliação ou quaisquer mitigações em vigor impedindo que código vulnerável seja executado.

• Enquanto ativo, a documentação do projeto DEVE incluir uma política que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_05_01]}

  Detalhes:

  Documente uma política no projeto que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. Inclua o processo para identificar, priorizar e remediar essas descobertas.

• Enquanto ativo, a documentação do projeto DEVE incluir uma política para abordar violações de SCA antes de qualquer lançamento. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_05_02]}

  Detalhes:

  Documente uma política no projeto para abordar os resultados aplicáveis de Análise de Composição de Software antes de qualquer lançamento, e adicione verificações de status que confirmem a conformidade com essa política antes do lançamento.

• Enquanto ativo, todas as alterações na base de código do projeto DEVEM ser automaticamente avaliadas em relação a uma política documentada para dependências maliciosas e vulnerabilidades conhecidas em dependências, e então bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_05_03]}

  Detalhes:

  Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Análise de Composição de Software em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

• Enquanto ativo, a documentação do projeto DEVE incluir uma política que defina um limite para remediação de resultados de SAST. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_06_01]}

  Detalhes:

  Documente uma política no projeto que defina um limite para remediação de resultados de Teste de Segurança de Aplicação Estática (SAST). Inclua o processo para identificar, priorizar e remediar esses resultados.

• Enquanto ativo, todas as alterações na base de código do projeto DEVEM ser automaticamente avaliadas em relação a uma política documentada para fraquezas de segurança e bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. {Justificativa de N/A} {URL de atendimento} ^{[osps_vm_06_02]}

  Detalhes:

  Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Teste de Segurança de Aplicação Estática (SAST) em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.