Práticas recomendadas para gravar avisos de segurança do repositório

Observação

Se você é um pesquisador de segurança, deve entrar em contato diretamente com os mantenedores para pedir que criem consultorias de segurança ou emitam CVEs em seu nome em repositórios que você não administra. No entanto, se os relatórios de vulnerabilidade privados estiverem habilitados para o repositório, será possível relatar uma vulnerabilidade de maneira privada por conta própria. Para saber mais, confira Como relatar de modo privado uma vulnerabilidade de segurança.

Sobre os avisos de segurança para repositórios

Os avisos de segurança do repositório permitem que os mantenedores dos repositórios públicos discutam e corrijam de modo privado as vulnerabilidades de segurança em um projeto. Depois de colaborar em uma correção, os responsáveis pelo repositório podem publicar o aviso de segurança para divulgar publicamente a vulnerabilidade de segurança na comunidade do projeto. Ao publicar avisos de segurança, os responsáveis pelo repositório facilitam para a comunidade a atualização das dependências do pacote e a pesquisa sobre o impacto das vulnerabilidades de segurança. Para obter mais informações, consulte Sobre os avisos de segurança do repositório.

Recomendamos que você use a sintaxe usada no GitHub Advisory Database, principalmente a formatação de versão, ao criar um aviso de segurança de repositório, ou faça uma contribuição da comunidade para um aviso de segurança global.

Se você seguir a sintaxe do GitHub Advisory Database, principalmente ao definir as versões afetadas:

Ao publicar o aviso de repositório, podemos adicioná-lo ao GitHub Advisory Database como uma consultoria "revisada pelo GitHub", sem precisar solicitar mais informações.
O Dependabot terá as informações para identificar com precisão os repositórios afetados e enviar Dependabot alerts para notificá-los.
Os membros da comunidade são menos propensos a sugerir edições ao aviso para corrigir informações ausentes ou incorretas.

Adicione ou edite um aviso de repositório usando o formulário Rascunho de aviso de segurança. Para saber mais, confira Criando uma consultoria de segurança do repositório.

Sugira um aprimoramento para um aviso global existente usando o formulário Aprimorar o aviso de segurança. Para saber mais, confira Editando consultorias de segurança no banco de dados consultivo do GitHub.

Ecossistema

Você precisa atribuir o aviso a um dos ecossistemas com suporte usando o campo Ecossistema. Para obter mais informações sobre os ecossistemas que apoiamos, consulte Como procurar avisos de segurança no GitHub Advisory Database.

Captura de tela da área "Produtos afetados" do formulário de aviso de segurança. O campo "Ecossistema" é realçado com um contorno laranja escuro.

Nome do pacote

Recomendamos que você use o campo Nome do pacote para especificar quais pacotes são afetados porque as informações do pacote são necessárias para avisos revisados pelo "GitHub" no GitHub Advisory Database. As informações do pacote são opcionais para avisos de segurança no nível do repositório, mas a inclusão dessas informações já simplifica o processo de revisão quando você publica o aviso de segurança.

Versões afetadas

Recomendamos que você use o campo Versões afetadas para especificar quais versões são afetadas porque essas informações são necessárias para avisos "revisados pelo GitHub" no GitHub Advisory Database. As informações de versão são opcionais para avisos de segurança no nível do repositório, mas a inclusão dessas informações já simplifica o processo de revisão quando você publica o aviso de segurança.

Para obter mais informações sobre GitHub Advisory Database, consulte https://github.com/github/advisory-database.

Glossário

          **Vulnerable Version Range (VVR):** o intervalo de versões que são vulneráveis a um bug de software específico.

          **Operador**: qualquer símbolo que indique o limite de um intervalo de versão vulnerável.

          **Formato de vulnerabilidade de código aberto (OSV):** formato com o qual os dados do GitHub Advisory Database buscam ser compatíveis.

Sintaxe da versão

Números menores representam versões anteriores aos números maiores. por exemplo, 1.0.0 é uma versão inferior a 2.0.0
As letras mais antigas do alfabeto são versões anteriores às letras mais recentes. Por exemplo, 2.0.0-a é uma versão anterior à 2.0.0-b.
Quaisquer letras que venham depois de um número são consideradas parte de uma versão prévia, portanto, qualquer versão com letras após os números é uma versão anterior àquela com números sem letras. Por exemplo, 2.0.0-alpha, 2.0.0-beta e 2.0.0-rc são anteriores a 2.0.0.
Uma versão fixa não pode ser menor que o maior número no VVR. Por exemplo, uma versão vulnerável é lançada e o responsável pela manutenção recomenda o downgrade. O responsável pela manutenção não pode rotular essa versão inferior como uma versão corrigida ou com patch no campo Fixed porque essa versão é menor que a versão vulnerável.

Operadores suportados

          `>=` para “maior ou igual a esta versão”.

```
          `>` para “maior que esta versão”.
```
Aviso

Embora GitHub suporte o uso do operador >, não é recomendável usar esse operador, pois ele não é compatível com o formato OSV.

          `=` para "igual a esta versão".

          `<=` para “versão menor ou igual a esta”.

          `<` para “menos do que esta versão”.

Especificando as versões afetadas em GitHub

É importante definir claramente as versões afetadas em um aviso. GitHub oferece diversas opções no campo Versões afetadas para que você especifique intervalos de versões vulneráveis.

Para exemplos que mostram como as versões afetadas são definidas em alguns avisos existentes, consulte Exemplos.

Uma cadeia de caracteres de versão afetada válida consiste em uma das seguintes opções:
- Uma sequência de operadores com limite inferior.
- Uma sequência de operadores com limite superior.
- Uma sequência de operadores com limites superior e inferior. O limite inferior deve vir primeiro, seguido por uma vírgula e um único espaço, e depois o limite superior.
- Uma sequência de versão específica usando o operador de igualdade (=).
- Cada sequência de operador deve ser especificada como o operador, um espaço único e depois a versão. Para obter mais informações sobre operadores válidos, consulte Operadores compatíveis acima.
- A versão deve começar com um número seguido por qualquer número de números, letras, pontos, traços ou sublinhados (qualquer coisa que não seja um espaço ou vírgula). Para obter mais informações sobre a formatação de versão, consulte Sintaxe de versão acima.
Observação

As cadeias de caracteres de versão afetadas não podem conter espaços em branco no início ou no final.
Os operadores com limite superior podem ser inclusivos ou exclusivos, ou seja, <= ou <, respectivamente.
Os operadores com limite inferior podem ser inclusivos ou exclusivos, ou seja, >= ou >, respectivamente. No entanto, se você publicar um aviso de repositório e se tornar um aviso global, uma regra diferente se aplicará: as cadeias de caracteres com limite inferior só poderão ser inclusivas, ou seja, >=. O operador exclusivo de limite inferior (>) só é permitido quando a versão é 0, por exemplo > 0.
Uso adequado dos espaços
- Utilize um espaço entre o operador e o número da versão.
- Não use um espaço em >= ou <=.
- Não utilize espaço entre um número e uma vírgula em >= lower bound, <= upper bound.
- Utilize um espaço entre a vírgula e o operador de limite superior.
Observação

Limitação do limite inferior:
- Isso se deve a incompatibilidades com o esquema OSV.
- Aplicável somente quando você faz uma sugestão em um aviso existente no GitHub Advisory Database.
Não é possível especificar vários intervalos de versão afetados no mesmo campo, como > 2.0, < 2.3, > 3.0, < 3.2. Para especificar mais de um intervalo, você precisa criar uma nova seção Produtos afetados para cada intervalo clicando no botão + Adicionar outro produto afetado.
Se o intervalo de versão afetada incluir apenas um limite superior ou inferior:
- O valor implícito será sempre > 0 se o limite inferior não for especificado explicitamente.
- O valor implícito será sempre infinito se o limite superior não for especificado explicitamente.

Definir um limite superior apenas em um VVR

Se você definir apenas um limite superior, use <= ou <.
O GitHub Advisory Database utiliza o banco de dados PyPA como uma de suas fontes de dados. No entanto, GitHub não corresponde exatamente ao formato VVR do PyPA (os avisos de segurança do PyPA costumam usar >= 0, <= n or >= 0, < n para se referir a intervalos de versões que possuem apenas um limite superior).
Não é necessário incluir >= 0 em um intervalo que tenha apenas um limite superior.

Definir um limite inferior apenas em um VVR

A equipe de curadoria de recomendações não recomenda definir limites inferiores apenas para recomendações relacionadas a malware. Isso ocorre porque, se uma versão corrigida for lançada, os usuários da versão corrigida continuarão a receber alertas desnecessários Dependabot alerts até que o aviso seja atualizado manualmente.
Use >= 0 para todas as versões

          `> 0` geralmente não é utilizado.

Especificando apenas uma versão afetada

          `= n` para a única versão afetada

Lembre-se de que o = não incluirá automaticamente nenhuma pré-visualização pública ou privada. apenas a versão especificada.

Erros comuns

Evite usar o intervalo de versões vulnerável < n e depois afirmar n+1 que ela foi corrigida.
- ```
          `< n` só deve ser usado quando `n` não estiver vulnerável.
```
- Neste caso, o VVR deve ser <= n ou < n+1.
Evite usar apenas um número ao descrever versões corrigidas com números de versão oficiais que contenham letras. Suponha que seu software tenha duas ramificações, linux e windows. Ao lançar as versões 2.0.0-linux e 2.0.0-windows, usar < 2.0.0 como a versão vulnerável fará com que as versões 2.0.0-linux e 2.0.0-windows sejam marcadas como vulneráveis, porque a lógica de versionamento interpreta -linux e -windows como versões de pré-lançamento. Você precisará marcar 2.0.0-linux, a ramificação mais antiga do alfabeto, como a primeira versão corrigida para evitar que 2.0.0-linux e 2.0.0-windows sejam consideradas vulneráveis.

Exemplos

Assessoria com múltiplos VVRs e múltiplas operadoras

          [A autenticação TLS do Etcd Gateway aplica-se apenas aos endpoints detectados nos registros DNS SRV (GHSA-wr2v-9rpq-c35q).](https://github.com/advisories/GHSA-wr2v-9rpq-c35q) possui duas faixas de versões vulneráveis:

          `< 3.3.23`, que possui um limite superior sem limite inferior e utiliza o operador `<`.

          `>= 3.4.0-rc.0, <= 3.4.9`, que tem um limite superior e um limite inferior e usa os operadores `>=` e `<=`.

Aviso que demonstra a relação entre um pré-lançamento e um lançamento regular

          [A plataforma XWiki permite XSS através do nome XClass em propriedades de string (GHSA-wcg9-pgqv-xm5v)](https://github.com/advisories/GHSA-wcg9-pgqv-xm5v) possui quatro intervalos de versões vulneráveis:

>= 1.1.2, < 14.10.21
>= 15.0-rc-1, < 15.5.5
>= 15.6-rc-1, < 15.10.6
= 16.0.0-rc-1

Três desses VVRs incluem versões preliminares na gama de versões vulneráveis. No último VVR, o = 16.0.0-rc-1 mostra que apenas 16.0.0-rc-1 é vulnerável, enquanto a versão regular que veio depois dele, o 16.0.0, não é. A lógica considera 16.0.0-rc-1 e 16.0.0 como versões separadas, sendo 16.0.0-rc-1 uma versão anterior à 16.0.0.

O patch para essa vulnerabilidade foi publicado em 24 de janeiro de 2024, para a versão 16.0.0. Para obter mais informações, consulte commit 27eca84 no repositório xwiki/xwiki-platform . A página XWiki Platform Old Core no site MVN Repository mostra que a versão 16.0.0-rc-1 foi publicada em 22 de janeiro de 2024, antes de a correção ser adicionada ao XWiki, e que a 16.0.0 foi publicada em 29 de janeiro de 2024, após a correção ter sido implementada.

Aviso com nomes de ramificações em números de versão

          [O Google Guava](https://mvnrepository.com/artifact/com.google.guava/guava) tem duas ramificações `android` e `jre`, em suas versões lançadas.               [Guava vulnerável ao uso inseguro de diretório temporário (GHSA-7g45-4rm6-3mm3)](https://github.com/advisories/GHSA-7g45-4rm6-3mm3) e [Divulgação de informações em Guava (GHSA-5mg8-w23w-74h3)](https://github.com/advisories/GHSA-5mg8-w23w-74h3) são avisos sobre vulnerabilidades que afetam o Guava. Ambos os avisos definem `32.0.0-android` como a versão corrigida.

A lógica de intervalo de versões interpreta as letras após 32.0.0 como pré-lançamentos, portanto, se você definir a versão corrigida como 32.0.0, ambas 32.0.0-android e 32.0.0-jre serão marcadas incorretamente como vulneráveis.
A lógica de intervalo de versões interpreta letras posteriores no alfabeto como sendo de uma versão posterior às letras anteriores no alfabeto; portanto, se você definir a versão corrigida para 32.0.0-jre, a 32.0.0-android será marcada incorretamente como vulnerável.

A melhor maneira de indicar que tanto 32.0.0-android quanto 32.0.0-jre são corrigidas é usar 32.0.0-android como a versão corrigida, e a lógica interpretará tudo depois 32.0.0-android no alfabeto como corrigido.