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

Licença FLOSS

Documentação

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

Outro

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

Controle de Mudanças

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

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

Numeração de versão única

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

Notas de lançamento

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

Relatórios

Processo de relato de bugs

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

Processo de relato de vulnerabilidades

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

Qualidade

Sistema de compilação funcional

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

Conjunto de testes automatizados

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

Teste de novas funcionalidades

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

Sinalizadores de aviso

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

Segurança

Conhecimento de desenvolvimento seguro

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

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

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

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

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

Vulnerabilidades conhecidas publicamente corrigidas

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

Outras questões de segurança

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

Análise

Análise estática de código

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

Análise dinâmica de código

  • É SUGERIDO que pelo menos uma ferramenta de análise dinâmica seja aplicada a qualquer grande lançamento de produção proposto do software antes de seu lançamento. [dynamic_analysis]
  • É SUGERIDO que se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) seja rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). {N/A permitido} [dynamic_analysis_unsafe]
  • É SUGERIDO que o projeto use uma configuração para pelo menos alguma análise dinâmica (como testes ou fuzzing) que habilite muitas asserções. Em muitos casos, essas asserções não devem ser habilitadas em builds de produção. [dynamic_analysis_enable_assertions]
  • Todas as vulnerabilidades exploráveis de severidade média e superior descobertas com análise dinâmica de código DEVEM ser corrigidas em tempo hábil após serem confirmadas. {N/A permitido} [dynamic_analysis_fixed]

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]
  • O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave). {URL de atendimento} [governance]
  • O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. {URL de atendimento} [code_of_conduct]
  • O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma. {URL de atendimento} [roles_responsibilities]
  • O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS). {URL de atendimento} [access_continuity]
  • O projeto DEVERIA ter um "bus factor" de 2 ou mais. {URL de atendimento} [bus_factor]

Documentação

  • O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano. {URL de atendimento} [documentation_roadmap]
  • O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A). {Justificativa de N/A} {URL de atendimento} [documentation_architecture]
  • O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança"). {N/A permitido} {URL de atendimento} [documentation_security]
  • O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software. {Justificativa de N/A} {URL de atendimento} [documentation_quick_start]
  • O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume. {Justificativa de N/A} {Justificativa de atendimento} [documentation_current]
  • A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada. {URL de atendimento} [documentation_achievements]

Acessibilidade e internacionalização

  • O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo. {Justificativa de N/A} {Justificativa de atendimento} [accessibility_best_practices]
  • O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [internationalization]

Outro

  • Se os sites do projeto (site, repositório e URLs de download) armazenam senhas para autenticação de usuários externos, as senhas DEVEM ser armazenadas como hashes iterados com um salt por usuário usando um algoritmo de extensão de chave (iterado) (por exemplo, Argon2id, Bcrypt, Scrypt ou PBKDF2). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [sites_password_security]

Controle de Mudanças

Versões anteriores

  • O projeto DEVE manter as versões mais antigas do produto mais frequentemente usadas ou fornecer um caminho de atualização para versões mais recentes. Se o caminho de atualização for difícil, o projeto DEVE documentar como realizar a atualização (por exemplo, as interfaces que mudaram e etapas sugeridas detalhadas para ajudar na atualização). {Justificativa de N/A} {Justificativa de atendimento} [maintenance_or_update]

Relatórios

Processo de relato de bugs

  • O projeto DEVE usar um rastreador de questões para rastrear questões individuais. {Justificativa de N/A} {Justificativa de atendimento} [report_tracker]

Processo de relato de vulnerabilidades

  • O projeto DEVE dar crédito ao(s) relator(es) de todos os relatórios de vulnerabilidade resolvidos nos últimos 12 meses, exceto para o(s) relator(es) que solicitarem anonimato. Se não houve vulnerabilidades resolvidas nos últimos 12 meses, selecione "não aplicável" (N/A). {Justificativa de N/A} {URL de atendimento} [vulnerability_report_credit]
  • O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades. {URL de atendimento} [vulnerability_response_process]

Qualidade

Padrões de codificação

  • O projeto DEVE identificar os guias de estilo de codificação específicos para as linguagens primárias que utiliza, e exigir que as contribuições geralmente estejam em conformidade com eles. {Justificativa de N/A} {URL de atendimento} [coding_standards]
  • O projeto DEVE aplicar automaticamente seu(s) estilo(s) de codificação selecionado(s) se houver pelo menos uma ferramenta FLOSS que possa fazer isso na(s) linguagem(ns) selecionada(s). {Justificativa de N/A} {Justificativa de atendimento} [coding_standards_enforced]

Sistema de compilação funcional

  • Os sistemas de compilação para binários nativos DEVEM honrar as variáveis de compilador e vinculador (ambiente) relevantes passadas para eles (por exemplo, CC, CFLAGS, CXX, CXXFLAGS e LDFLAGS) e passá-las para invocações de compilador e vinculador. Um sistema de compilação PODE estendê-las com flags adicionais; ele NÃO DEVE simplesmente substituir valores fornecidos pelos seus próprios. Se nenhum binário nativo estiver sendo gerado, selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [build_standard_variables]
  • O sistema de compilação e instalação DEVERIA preservar informações de depuração se elas forem solicitadas nas flags relevantes (por exemplo, "install -s" não é usado). Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [build_preserve_debug]
  • O sistema de compilação do software produzido pelo projeto NÃO DEVE compilar recursivamente subdiretórios se houver dependências cruzadas nos subdiretórios. Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [build_non_recursive]
  • O projeto DEVE ser capaz de repetir o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. Se nenhuma compilação ocorrer (por exemplo, linguagens de script onde o código fonte é usado diretamente em vez de ser compilado), selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [build_repeatable]

Sistema de instalação

  • O projeto DEVE fornecer uma maneira de instalar e desinstalar facilmente o software produzido pelo projeto usando uma convenção comumente utilizada. {Justificativa de N/A} {Justificativa de atendimento} [installation_common]
  • O sistema de instalação para usuários finais DEVE honrar convenções padrão para selecionar o local onde os artefatos compilados são escritos no momento da instalação. Por exemplo, se instalar arquivos em um sistema POSIX, ele DEVE honrar a variável de ambiente DESTDIR. Se não houver sistema de instalação ou convenção padrão, selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [installation_standard_variables]
  • O projeto DEVE fornecer uma maneira para desenvolvedores em potencial instalarem rapidamente todos os resultados do projeto e ambiente de suporte necessário para fazer alterações, incluindo os testes e ambiente de teste. Isso DEVE ser realizado com uma convenção comumente utilizada. {Justificativa de N/A} {Justificativa de atendimento} [installation_development_quick]

Componentes mantidos externamente

  • O projeto DEVE listar dependências externas de uma forma processável por computador. {Justificativa de N/A} {URL de atendimento} [external_dependencies]
  • Os projetos DEVEM monitorar ou verificar periodicamente suas dependências externas (incluindo cópias de conveniência) para detectar vulnerabilidades conhecidas, e corrigir vulnerabilidades exploráveis ou verificá-las como não exploráveis. {Justificativa de N/A} {Justificativa de atendimento} [dependency_monitoring]
  • "O projeto DEVE:
    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]
  • O projeto DEVERIA evitar usar funções e APIs obsoletas ou desatualizadas onde alternativas FLOSS estejam disponíveis no conjunto de tecnologia que usa (sua "pilha de tecnologia") e para uma supermaioria dos usuários que o projeto suporta (para que os usuários tenham acesso pronto à alternativa). {Justificativa de N/A} {Justificativa de atendimento} [interfaces_current]

Conjunto de testes automatizados

  • Uma suíte de testes automatizada DEVE ser aplicada a cada check-in em um repositório compartilhado para pelo menos um branch. Esta suíte de testes DEVE produzir um relatório sobre sucesso ou falha do teste. {Justificativa de atendimento} [automated_integration_testing]
  • O projeto DEVE adicionar testes de regressão a uma suíte de testes automatizada para pelo menos 50% dos bugs corrigidos nos últimos seis meses. {Justificativa de N/A} {Justificativa de atendimento} [regression_tests_added50]
  • O projeto DEVE ter suíte(s) de teste automatizada(s) FLOSS que forneçam pelo menos 80% de cobertura de instruções se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. {Justificativa de N/A} {Justificativa de atendimento} [test_statement_coverage80]

Teste de novas funcionalidades

  • O projeto DEVE ter uma política escrita formal de que, à medida que uma nova funcionalidade importante é adicionada, testes para a nova funcionalidade DEVEM ser adicionados a uma suíte de testes automatizada. {Justificativa de N/A} {Justificativa de atendimento} [test_policy_mandated]
  • O projeto DEVE incluir, em suas instruções documentadas para propostas de mudança, a política de que testes devem ser adicionados para novas funcionalidades importantes. {Justificativa de N/A} {Justificativa de atendimento} [tests_documented_added]

Sinalizadores de aviso

  • Os projetos DEVEM ser maximamente rigorosos com avisos no software produzido pelo projeto, onde for prático. {Justificativa de N/A} {Justificativa de atendimento} [warnings_strict]

Segurança

Conhecimento de desenvolvimento seguro

  • O projeto DEVE implementar princípios de projeto seguro (de "know_secure_design"), quando aplicável. Se o projeto não está produzindo software, selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [implement_secure_design]

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

  • Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos ou modos com fraquezas sérias conhecidas (por exemplo, o algoritmo de hash criptográfico SHA-1 ou o modo CBC em SSH). {N/A permitido} {Justificativa de atendimento} [crypto_weaknesses]
  • O projeto DEVERIA suportar múltiplos algoritmos criptográficos, para que os usuários possam mudar rapidamente se um for quebrado. Algoritmos de chave simétrica comuns incluem AES, Twofish e Serpent. Alternativas comuns de algoritmos de hash criptográfico incluem SHA-2 (incluindo SHA-224, SHA-256, SHA-384 E SHA-512) e SHA-3. {N/A permitido} {Justificativa de atendimento} [crypto_algorithm_agility]
  • O projeto DEVE suportar o armazenamento de credenciais de autenticação (como senhas e tokens dinâmicos) e chaves criptográficas privadas em arquivos que são separados de outras informações (como arquivos de configuração, bancos de dados e logs), e permitir que os usuários as atualizem e substituam sem recompilação de código. Se o projeto nunca processar credenciais de autenticação e chaves criptográficas privadas, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_credential_agility]
  • O software produzido pelo projeto DEVERIA suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVERIAM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_used_network]
  • O software produzido pelo projeto DEVERIA, se suportar ou usar TLS, suportar pelo menos a versão TLS 1.2. Observe que o predecessor do TLS era chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_tls12]
  • O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado TLS por padrão ao usar TLS, incluindo em sub-recursos. Se o software não usar TLS, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_certificate_verification]
  • O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado antes de enviar cabeçalhos HTTP com informações privadas (como cookies seguros). Se o software não usar TLS, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_verification_private]

Lançamento seguro

  • O projeto DEVE assinar criptograficamente os lançamentos dos resultados do projeto destinados ao uso generalizado, e DEVE haver um processo documentado explicando aos usuários como eles podem obter as chaves públicas de assinatura e verificar a(s) assinatura(s). A chave privada para essa(s) assinatura(s) NÃO DEVE estar em site(s) usado(s) para distribuir diretamente o software ao público. Se os lançamentos não forem destinados ao uso generalizado, selecione "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [signed_releases]
  • É SUGERIDO que no sistema de controle de versão, cada tag de versão importante (uma tag que faz parte de um lançamento principal, lançamento menor ou corrige vulnerabilidades publicamente observadas) seja criptograficamente assinada e verificável conforme descrito em signed_releases. {Justificativa de atendimento} [version_tags_signed]

Outras questões de segurança

  • Os resultados do projeto DEVEM verificar todas as entradas de fontes potencialmente não confiáveis para garantir que sejam válidas (uma *lista de permissões*), e rejeitar entradas inválidas, se houver quaisquer restrições sobre os dados. {Justificativa de N/A} {Justificativa de atendimento} [input_validation]
  • Mecanismos de proteção DEVERIAM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. {Justificativa de N/A} {Justificativa de atendimento} [hardening]
  • O projeto DEVE fornecer um caso de garantia que justifique por que seus requisitos de segurança são atendidos. O caso de garantia DEVE incluir: uma descrição do modelo de ameaças, identificação clara dos limites de confiança, um argumento de que os princípios de projeto seguro foram aplicados e um argumento de que fraquezas comuns de segurança na implementação foram combatidas. {URL de atendimento} [assurance_case]

Análise

Análise estática de código

  • O projeto DEVE usar pelo menos uma ferramenta de análise estática com regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. {Justificativa de N/A} {Justificativa de atendimento} [static_analysis_common_vulnerabilities]

Análise dinâmica de código

  • Se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) DEVE ser rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). {Justificativa de N/A} {Justificativa de atendimento} [dynamic_analysis_unsafe]

Ouro

Fundamentos

Pré-requisitos

Supervisão do projeto

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

Outro

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

Controle de Mudanças

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

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

Qualidade

Padrões de codificação

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

Sistema de compilação funcional

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

Conjunto de testes automatizados

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

Segurança

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

  • O software produzido pelo projeto DEVE suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVEM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_used_network]
  • O software produzido pelo projeto DEVE, se suportar ou usar TLS, suportar pelo menos a versão 1.2 do TLS. Observe que o predecessor do TLS foi chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). {N/A permitido} {Justificativa de atendimento} [crypto_tls12]

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

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

Outras questões de segurança

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

Análise

Análise dinâmica de código

  • O projeto DEVE aplicar pelo menos uma ferramenta de análise dinâmica a qualquer lançamento de produção proposto do software produzido pelo projeto antes de seu lançamento. {Justificativa de N/A} {Justificativa de atendimento} [dynamic_analysis]
  • O projeto DEVERIA incluir muitas asserções em tempo de execução no software que produz e verificar essas asserções durante a análise dinâmica. {Justificativa de N/A} {Justificativa de atendimento} [dynamic_analysis_enable_assertions]

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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • Enquanto ativo, a documentação do projeto DEVE conter contatos de segurança. {Justificativa de N/A} {URL de atendimento} [osps_vm_02_01]

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

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