Procedimientos recomendados para escribir asesorías de seguridad del repositorio

Cualquier usuario con permisos de administrador puede crear y editar un aviso de seguridad.

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 más información, consulta 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 más información sobre los ecosistemas que apoyamos, consulta 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 publicas 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, consulta 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 letras anteriores del alfabeto representan versiones anteriores a las que representan las letras posteriores del alfabeto. Por ejemplo, 2.0.0-a es una versión anterior a 2.0.0-b.
• Las letras que vienen 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 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 tener un número inferior el número más alto del 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 menor que la versión vulnerable.

Operadores admitidos

• >= para «posterior o igual que esta versión».

• > para «posterior a esta versión».

  Warning

  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 «inferior o igual que esta versión».

• < para «inferior 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, vea 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 más información sobre operadores válidos, consulta Operadores compatibles arriba.

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

  Note

  Las cadenas de la versión afectadas no pueden contener espacios iniciales ni 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 espacios

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

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

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

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

  Note

  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.
• Uso de >= 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 comunes

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

  • < n solo se debe usar cuando n no es vulnerable.
  • En este caso, el 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 ramificaciones, linux y windows. Al lanzar 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ás marcar 2.0.0-linux, la primera ramificación 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.

Ejemplos

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) 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) 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, consulta commit 27eca84 en el repositorio xwiki/xwiki-platform . La página XWiki Platform Old Core de la plataforma XWiki 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 ramificación en números de versión

Google Guava tiene dos ramificaciones, android y jre, en sus versiones. Guava vulnerable al uso inseguro del directorio temporal (GHSA-7g45-4rm6-3mm3) y Divulgación de información en Guava (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, y la lógica interpretará como revisado todo lo que sea posterior a 32.0.0-android por orden alfabético.