Discussão dos Critérios

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades. Mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada.

No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes organizações.

Esta página discute o conjunto de melhores práticas para projetos de Software Livre/Libre e de Código Aberto (FLOSS) desenvolvidas para o selo de Melhores Práticas da Open Source Security Foundation (OpenSSF). Projetos que seguem essas melhores práticas poderão se auto certificar voluntariamente e mostrar que alcançaram o selo relevante. Os projetos podem fazer isso, sem custo algum, usando um aplicativo da web (BadgeApp) para explicar como eles atendem a essas práticas e seus critérios detalhados.

Essas melhores práticas foram criadas para:

encorajar os projetos a seguir as melhores práticas,
ajudar novos projetos a descobrir quais são essas práticas, e
ajudar os usuários a saber quais projetos estão seguindo as melhores práticas (para que os usuários possam preferir tais projetos).

A expressão "melhores práticas" significa "um procedimento ou conjunto de procedimentos que é preferido ou considerado padrão dentro de uma organização, indústria, etc." (fonte: Dictionary.com). Esses critérios são o que acreditamos ser amplamente "preferido ou considerado padrão" na comunidade FLOSS mais ampla.

Para mais informações sobre como esses critérios foram desenvolvidos, consulte o site GitHub do selo de Melhores Práticas OpenSSF.

Você também pode ver os critérios completos.

Estrutura dos Critérios

Os critérios de melhores práticas são divididos em três níveis:

Aprovação concentra-se em melhores práticas que projetos FLOSS bem administrados normalmente já seguem. Obter o selo de aprovação é uma conquista; a qualquer momento, apenas cerca de 10% dos projetos que buscam um selo alcançam o nível de aprovação.
Prata é um conjunto de critérios mais rigoroso do que a aprovação, mas espera-se que seja alcançável por projetos pequenos e de uma única organização.
Ouro é ainda mais rigoroso do que prata e inclui critérios que não são alcançáveis por projetos pequenos ou de uma única organização.

Cada critério tem um nome curto, mostrado como texto sobrescrito dentro de colchetes após o texto dos critérios.

Relacionamento com Outros Projetos

A Linux Foundation também patrocina o Projeto OpenChain, que identifica critérios para um "programa de conformidade de Software Livre e de Código Aberto (FOSS) de alta qualidade." O OpenChain se concentra em como as organizações podem usar melhor o FLOSS e contribuir de volta para os projetos FLOSS, enquanto o selo de Melhores Práticas OpenSSF se concentra nos próprios projetos FLOSS. O selo de Melhores Práticas OpenSSF e o OpenChain trabalham juntos para ajudar a melhorar o FLOSS e como o FLOSS é usado.

Automação dos Critérios

Em alguns casos, testamos e preenchemos automaticamente as informações se o projeto seguir convenções padrão e estiver hospedado em um site (por exemplo, GitHub) com suporte decente de API.

Pretendemos melhorar essa automação no futuro. Melhorias na automação são bem-vindas!

No entanto, priorizamos intencionalmente o "que é importante", mesmo que não possa ser automatizado de forma viável. Adoramos medições automatizadas, mas nem tudo importante é automatizável ou pode ser automatizado de forma viável.

Mudanças ao longo do tempo

Esperamos que estas práticas e seus critérios detalhados sejam atualizados ao longo do tempo. Planejamos adicionar novos critérios mas marcá-los como critérios "futuros", para que os projetos possam adicionar essa informação e manter seu selo.

Feedback é muito bem-vindo via site do GitHub como questões ou pull requests. Há também uma lista de discussão para discussão geral.

Palavras-chave

As palavras-chave "DEVE", "NÃO DEVE", "DEVERIA", "NÃO DEVERIA" e "PODE" neste documento devem ser interpretadas conforme descrito na RFC 2119. O termo adicional SUGERIDO é adicionado. Em resumo, essas palavras-chave têm os seguintes significados:

O termo DEVE é um requisito absoluto, e NÃO DEVE é uma proibição absoluta.
O termo DEVERIA indica um critério que é normalmente exigido, mas podem existir razões válidas em circunstâncias particulares para ignorá-lo. No entanto, as implicações completas devem ser compreendidas e cuidadosamente ponderadas antes de escolher um curso diferente.
O termo SUGERIDO é usado em vez de DEVERIA quando o critério deve ser considerado, mas as razões válidas para não fazê-lo são ainda mais comuns do que para DEVERIA.
O termo PODE fornece uma maneira de algo poder ser feito, por exemplo, para deixar claro que a implementação descrita é aceitável.

Frequentemente, um critério é declarado como algo que DEVERIA ser feito, ou é SUGERIDO, porque pode ser difícil de implementar ou os custos para fazê-lo podem ser altos.

Obtendo um selo

Para obter um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser considerados (deve ser classificado como atendido ou não atendido, mas justificativa não é necessária a menos que observado de outra forma). Uma resposta de N/A ("não aplicável"), onde permitido, é considerada o mesmo que sendo atendida. Em alguns casos, especialmente nos níveis mais altos, justificativa e/ou URL podem ser necessários.

Alguns critérios têm marcações especiais que influenciam isso:

{N/A permitido} - "N/A" ("Não aplicável") é permitido.
{N/A justificativa} - "N/A" ("Não aplicável") é permitido e requer justificativa.
{Justificativa de atendimento} - "Atendido" requer justificativa.
{URL de atendimento} - "Atendido" requer justificativa com URL.
{Futuro} - a resposta a este critério atualmente não tem efeito, mas pode ser necessária no futuro.

Um projeto deve alcançar o nível anterior para alcançar o próximo nível. Em alguns casos, critérios DEVERIA tornam-se DEVE em selos de nível superior, e alguns critérios SUGERIDO em níveis inferiores tornam-se DEVERIA ou DEVE em selos de nível superior. Os níveis superiores também exigem mais justificativa, porque queremos que outros entendam como os critérios estão sendo atendidos.

Os (muitos) critérios criptográficos nem sempre se aplicam, porque alguns softwares não têm necessidade de usar diretamente capacidades criptográficas. Nesses casos, responda N/A.

Existe um critério de aprovação implícito - todo projeto DEVE ter um site público com URL estável. Isso é necessário para criar uma entrada de selo em primeiro lugar.

Terminologia

Se você não está familiarizado com desenvolvimento de software ou com a execução de um projeto FLOSS, materiais como Producing Open Source Software por Karl Fogel podem ser úteis para você.

Aqui estão alguns termos-chave:

Um projeto é uma entidade ativa que tem membro(s) do projeto e produz resultado(s) do projeto. Seu(s) membro(s) usam sites de projeto para coordenar e disseminar resultado(s). Um projeto não precisa ser uma entidade legal formal.
Os membros do projeto são o grupo de uma ou mais pessoas ou empresas que trabalham juntas para tentar produzir resultados do projeto. Alguns projetos FLOSS podem ter diferentes tipos de membros, com diferentes papéis, mas isso está fora do nosso escopo.
Resultados do projeto são o que os membros do projeto trabalham juntos para produzir como seu objetivo final. Normalmente isso é software, mas os resultados do projeto podem incluir outras coisas também. Os critérios que se referem a "software produzido pelo projeto" estão se referindo aos resultados do projeto.
Sites do projeto são os sites dedicados a apoiar o desenvolvimento e disseminação dos resultados do projeto, e incluem o site do projeto, repositório e sites de download onde aplicável (consulte sites_https).
O site do projeto, também conhecido como página inicial do projeto, é a página principal na world wide web (WWW) que um novo usuário normalmente visitaria para ver informações sobre o projeto; pode ser o mesmo que o site do repositório do projeto (isso é frequentemente verdade no GitHub).
O repositório do projeto gerencia e armazena os resultados do projeto e o histórico de revisões dos resultados do projeto. Isso também é chamado de repositório de código-fonte do projeto, porque apenas exigimos o gerenciamento e armazenamento das versões editáveis, não dos resultados gerados automaticamente (em muitos casos, os resultados gerados não são armazenados em um repositório).
Um mecanismo de segurança do projeto é um mecanismo de segurança fornecido pelo software entregue pelo projeto.

Não-critérios

Os critérios:

não exigem nenhuma tecnologia, produto ou serviço específico. Por exemplo, eles não exigem git, GitHub ou GitLab. Os critérios fornecem orientação e ajuda para casos comuns, já que essas informações podem ajudar as pessoas a entender e atender aos critérios. Existe alguma automação especial para projetos que usam git ou GitHub, para ajudar usuários nesses casos comuns, mas eles não são exigidos. Assim, à medida que novas ferramentas e capacidades se tornam disponíveis, os projetos podem mudar rapidamente para elas. Como exceções, os critérios exigem uma página web do projeto e TLS.
não exigem ou proíbem nenhuma linguagem de programação em particular. Eles exigem que medidas adicionais sejam tomadas para certos tipos de linguagens de programação, mas isso é diferente.
nunca exigem o uso de software proprietário, serviço proprietário ou tecnologia proprietária, já que muitos desenvolvedores de software livre rejeitariam tais critérios. Os projetos podem usá-los e depender deles.
não exigem desenvolvimento ativo ou discussão de usuários dentro de um projeto. Alguns projetos altamente maduros raramente mudam e, portanto, podem ter pouca atividade. Os critérios exigem, no entanto, que o projeto seja responsivo se vulnerabilidades forem relatadas ao projeto.
não exigem taxas para obter um selo.
não exigem que todos os critérios sejam implementados de uma vez; a maioria dos projetos os implementa ao longo do tempo.

O nível de passagem não inclui critérios que seriam impraticáveis para um projeto de uma única pessoa, por exemplo, algo que requer uma quantidade significativa de dinheiro. Muitos projetos FLOSS são pequenos, e não queremos privá-los de direitos.

Identificando um projeto

Nosso aplicativo dá a cada entrada de projeto um id único, mas isso não ajuda as pessoas que estão procurando o projeto. Para nossos propósitos, o nome real de um projeto é a URL do seu repositório, e quando isso não está disponível, a URL da "página inicial" do projeto. Limitamos a taxa de alterações na URL do repositório para prevenir alguns absurdos. Os projetos normalmente têm um nome legível por humanos, mas esses nomes não são únicos o suficiente.

Por que ter critérios?

O artigo Open badges for education: what are the implications at the intersection of open systems and badging? identifica três razões gerais para sistemas de selos (todas são válidas para este):

Selos como motivador de comportamento. Esperamos que, ao identificar as melhores práticas, encorajemos os projetos a implementar essas melhores práticas se já não o fazem.
Selos como ferramenta pedagógica. Alguns projetos podem não estar cientes de algumas das melhores práticas aplicadas por outros, ou como elas podem ser aplicadas na prática. O selo os ajudará a conhecê-las e formas de implementá-las.
Selos como um sinalizador ou credencial. Usuários potenciais querem usar projetos que estão aplicando as melhores práticas para produzir consistentemente bons resultados; os selos facilitam para os projetos sinalizarem que estão seguindo as melhores práticas e facilitam para os usuários verem quais projetos estão fazendo isso.

Por que autocertificação?

Optamos por usar a autocertificação, porque isso torna possível que um grande número de projetos (mesmo os pequenos) participem. Existem milhões de projetos FLOSS, e pagar terceiros para avaliar independentemente cada um deles não é escalável. Existe o risco de que os projetos possam fazer declarações falsas, mas achamos que o risco é pequeno, os usuários podem verificar as declarações por si mesmos e as declarações falsas podem ser substituídas. Também usamos automação para substituir declarações falsas quando podemos confiar nos resultados.