Procedimientos recomendados para escribir asesorías de seguridad del repositorio

Acerca de las asesorías de seguridad para repositorios

Las asesorías de seguridad del repositorio permiten a los mantenedores de repositorios públicos analizar y corregir de forma privada una vulnerabilidad de seguridad en un proyecto. Después de colaborar en una corrección, los mantenedores de repositorios pueden publicar el aviso de seguridad para revelar públicamente la vulnerabilidad de seguridad a la comunidad del proyecto. Al publicar avisos de seguridad, los mantenedores de repositorios facilitan a su comunidad la actualización de las dependencias de paquetes y la investigación del impacto de las vulnerabilidades de seguridad. Para obtener más información, consulte Acerca de las asesorías de seguridad de repositorio.

Se recomienda usar la sintaxis usada en GitHub Advisory Database (especialmente el formato de versión) al escribir una asesoría de seguridad del repositorio o realizar una contribución de la comunidad a una asesoría de seguridad global.

Si sigues la sintaxis de GitHub Advisory Database, especialmente al definir versiones afectadas:

• Al publicar la asesoría del repositorio, podemos agregar dicha asesoría a GitHub Advisory Database como una asesoría "revisada por GitHub", sin necesidad de solicitar más información.
• Dependabot tendrá la información para identificar con precisión los repositorios afectados y enviarles alertas de Dependabot alerts para notificarles.
• Es menos probable que los miembros de la comunidad sugieran ediciones a tu asesoría para corregir la información incorrecta o la falta de esta.

Puedes agregar o editar una asesoría de repositorio mediante el formulario Borrador de asesoría de seguridad. Para más información, consulta Creación de un aviso de seguridad de repositorio.

Puedes sugerir una mejora en una asesoría global existente mediante el formulario Mejorar la asesoría de seguridad. Para más información, consulta Edición de avisos de seguridad en la base de avisos de GitHub.

Ecosistema

Debes asignar la asesorías a uno de nuestros ecosistemas admitidos mediante el campo Ecosistema. Para obtener más información sobre los ecosistemas que admitimos, consulte Exploración de los avisos de seguridad en GitHub Advisory Database.

Nombre del paquete

Se recomienda usar el campo Nombre del paquete para especificar qué paquetes se ven afectados porque se requiere información de paquete para las asesorías "revisados por GitHub" en GitHub Advisory Database. La información del paquete es opcional para las asesorías de seguridad de nivel de repositorio, pero la inclusión temprana de esta información simplifica el proceso de revisión cuando publica la asesoría de seguridad.

Versiones afectadas

Se recomienda usar el campo Versiones afectadas para especificar qué versiones se ven afectadas porque se requiere esta información para las asesorías "revisadas por GitHub" en GitHub Advisory Database. La información de la versión es opcional para las asesorías de seguridad de nivel de repositorio, pero la inclusión temprana de esta información simplifica el proceso de revisión cuando publicas la asesoría de seguridad.

Para obtener más información sobre GitHub Advisory Database, consulte https://github.com/github/advisory-database.

Glosario

•           **Intervalo de versiones vulnerables (VVR):** el intervalo de versiones que son vulnerables a un error de software determinado.
  

•           **Operador**: cualquier símbolo que indique el límite de un intervalo de versiones vulnerable.
  

•           **Formato de vulnerabilidad de código abierto (OSV):** formato con el que los datos de GitHub Advisory Database buscan ser compatibles.
  

Sintaxis de versión

• Los números más bajos representan versiones anteriores a las que representan los números más altos. por ejemplo, 1.0.0 es una versión inferior a la 2.0.0
• Las primeras letras del alfabeto son versiones anteriores de las últimas. Por ejemplo, 2.0.0-a es una versión anterior a 2.0.0-b.
• Todas las letras que aparecen después de un número se consideran parte de una versión preliminar, por lo que las versiones con letras después de los números son versiones anteriores a los números sin letras en el número de versión. Por ejemplo, 2.0.0-alpha, 2.0.0-beta y 2.0.0-rc son anteriores a 2.0.0.
• Una versión corregida no puede ser anterior al número más alto de VVR. Por ejemplo, se publica una versión vulnerable y el mantenedor recomienda cambiar a una versión anterior. El mantenedor no puede etiquetar esa versión inferior como una versión corregida o revisada en el campo Fixed porque esa versión es anterior a la versión vulnerable.

Operadores compatibles

•           `>=` para "posterior o igual a esta versión".
  

•           `>` para "posterior a esta versión".
  

  Advertencia

  Aunque GitHub admite el uso del operador >, no se recomienda usar este operador porque no es compatible con el formato OSV.

•           `=` para "igual que esta versión".
  

•           `<=` para "anterior o igual a esta versión".
  

•           `<` para "anterior a esta versión".
  

Especificación de versiones afectadas en GitHub

Es importante definir claramente las versiones afectadas para un aviso. GitHub proporciona varias opciones en el campo Versiones afectadas para especificar intervalos de versiones vulnerables.

Para obtener ejemplos en los que se muestran cómo se definen las versiones afectadas en algunos avisos existentes, consulte Ejemplos.

• Una cadena de versión afectada válida consta de uno de los siguientes elementos:

  • Una secuencia de operador de límite inferior.

  • Una secuencia de operador de límite superior.

  • Una secuencia de operadores de límite superior e inferior. Primero debe aparecer el límite inferior, seguido de una coma y un único espacio y, después, el límite superior.

  • Una secuencia de versión específica mediante el operador de igualdad (=).

  • Cada secuencia de operador debe especificarse como operador, un único espacio y, a continuación, la versión. Para obtener más información sobre los operadores válidos, consulte Operadores compatibles arriba.

  • La versión debe comenzar por un número, seguido de cualquier número de cifras, letras, puntos, guiones o caracteres de subrayado (cualquier elemento que no sea un espacio o coma). Para obtener más información sobre el formato de versión, consulte Sintaxis de versión arriba.

  Nota:

  Las cadenas de versión afectadas no pueden contener espacios iniciales o finales.

• Los operadores de límite superior pueden ser inclusivos o exclusivos, es decir <= o <, respectivamente.

• Los operadores de límite inferior pueden ser inclusivos o exclusivos, es decir >= o >, respectivamente. Sin embargo, si publicas la asesoría del repositorio y la graduamos en una asesoría global, se aplica una regla diferente: las cadenas de límite inferior solo pueden ser inclusivas, es decir >=. El operador de límite inferior exclusivo (>) solo se permite cuando la versión es 0, por ejemplo > 0.

• Uso adecuado de los espacios

  • Use un espacio entre un operador y un número de versión.

  • No use un espacio en >= o <=.

  • No use un espacio entre un número y una coma en >= lower bound, <= upper bound.

  • Use un espacio entre una coma y el operador de límite superior.

  Nota:

  La limitación de límite inferior:

  • Se debe a incompatibilidades con el esquema OSV.
  • Solo se aplica cuando se realiza una sugerencia sobre una asesoría existente en GitHub Advisory Database.

• No se pueden especificar varios intervalos de versiones afectados en el mismo campo, como > 2.0, < 2.3, > 3.0, < 3.2. Para especificar más de un intervalo, crea una nueva sección Productos afectados para cada intervalo haciendo clic en el botón + Agregar otro producto afectado.

  

• Si el intervalo de versiones afectado incluye solo un límite superior o inferior:

  • El valor implícito siempre es > 0 si el límite inferior no se especifica explícitamente.
  • El valor implícito siempre es infinito si el límite superior no se especifica explícitamente.

Establecimiento de un límite superior solo en un VVR

• Si solo establece un límite superior, use <= o <.
• En GitHub Advisory Database se usa la base de datos PyPA como uno de sus orígenes de datos. Pero GitHub no coincide exactamente con el formato VVR de PyPA (los avisos de seguridad de PyPa suelen usar >= 0, <= n o >= 0, < n para hacer referencia a intervalos de versiones que solo tienen un límite superior).
• No es necesario incluir >= 0 en un intervalo que solo tiene un límite superior.

Establecimiento de un límite inferior solo en un VVR

• El equipo de gestión de avisos no recomienda establecer límites inferiores en avisos que no sean de malware. Esto se debe a que, si alguna vez se publica una versión corregida, los usuarios de la versión corregida seguirán recibiendo Dependabot alerts innecesarias hasta que el aviso se actualice de forma manual.
• Use >= 0 para todas las versiones

•           `> 0` por lo general no se usa.
  

Especificación de una única versión afectada

•           `= n` para la única versión afectada
  

• Ten en cuenta que = no incluirá automáticamente ninguna versión preliminar pública o privada, solo la versión especificada.

Errores frecuentes

• Evita usar el intervalo de versiones vulnerables < n y, a continuación, afirmar que se ha revisado n+1.

  •           `< n` solo se debe usar cuando `n` no es vulnerable.
    

  • En este caso, el valor de VVR debería ser <= n o < n+1.

• Evita usar solo un número al describir versiones corregidas con números de versión oficiales que tengan letras. Supongamos que el software tiene dos ramas, linux y windows. Al publicar 2.0.0-linux y 2.0.0-windows, usar < 2.0.0 como versión vulnerable marcará 2.0.0-linux y 2.0.0-windows como vulnerable porque la lógica de versión interpreta -linux y -windows como versiones preliminares. Deberá marcar 2.0.0-linux, la primera rama por orden alfabético, como la primera versión revisada para evitar que 2.0.0-linux y 2.0.0-windows se consideren vulnerables.

Examples

Aviso con varios VVR y varios operadores

          [La autenticación TLS de Etcd Gateway solo se aplica a los puntos de conexión detectados en los registros SRV de DNS (GHSA-wr2v-9rpq-c35q)](https://github.com/advisories/GHSA-wr2v-9rpq-c35q) y tiene dos intervalos de versiones vulnerables:

•           `< 3.3.23`, que tiene un límite superior sin límite inferior y usa el operador `<`.
  

•           `>= 3.4.0-rc.0, <= 3.4.9`, que tiene un límite superior y un límite inferior y usa los operadores `>=` y `<=`.
  

Aviso que muestra la relación entre una versión preliminar y una versión normal

          [La plataforma XWiki permite XSS a través del nombre XClass en propiedades de cadena (GHSA-wcg9-pgqv-xm5v)](https://github.com/advisories/GHSA-wcg9-pgqv-xm5v) y tiene cuatro intervalos de versiones vulnerables:

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

Tres de estos VVR incluyen versiones preliminares en el intervalo de versiones vulnerables. El último VVR, = 16.0.0-rc-1, muestra que solo 16.0.0-rc-1 es vulnerable, mientras que la versión normal que apareció después, 16.0.0, no lo es. La lógica considera 16.0.0-rc-1 y 16.0.0 como versiones independientes, y 16.0.0-rc-1 como versión anterior a 16.0.0.

La revisión de esta vulnerabilidad se publicó el 24 de enero de 2024 para la versión 16.0.0. Para obtener más información, consulte commit 27eca84 en el repositorio de xwiki/xwiki-platform . La página XWiki Platform Old Core del sitio del repositorio de MVN muestra que 16.0.0-rc-1 se publicó el 22 de enero de 2024, antes de que la corrección se agregara a XWiki y 16.0.0 se publicó el 29 de enero de 2024, después de confirmar la corrección.

Aviso con nombres de rama en números de versión

          [Google Guava](https://mvnrepository.com/artifact/com.google.guava/guava) tiene dos ramas, `android` y `jre`, en sus versiones.               [Guava vulnerable al uso inseguro del directorio temporal (GHSA-7g45-4rm6-3mm3)](https://github.com/advisories/GHSA-7g45-4rm6-3mm3) y [Divulgación de información en Guava (GHSA-5mg8-w23w-74h3)](https://github.com/advisories/GHSA-5mg8-w23w-74h3) son avisos sobre las vulnerabilidades que afectan a Guava. Ambos avisos establecen `32.0.0-android` como la versión revisada.

• La lógica del intervalo de versiones interpreta las letras después de 32.0.0 como versiones preliminares, por lo que si establece la versión revisada en 32.0.0, tanto 32.0.0-android como 32.0.0-jre se marcarían incorrectamente como vulnerables.
• La lógica del intervalo de versiones interpreta las letras posteriores del alfabeto como una versión posterior a la que representan las letras anteriores del alfabeto, por lo que si establece la versión revisada en 32.0.0-jre, 32.0.0-android se marcaría incorrectamente como vulnerable.

La mejor manera de indicar que 32.0.0-android y 32.0.0-jre son versiones revisadas es marcar 32.0.0-android como versión revisada; de este modo la lógica interpretará como revisado todo lo que sea posterior a 32.0.0-android por orden alfabético.