Mejora del proceso de notificación de vulnerabilidades con …



Siga estos consejos para una experiencia efectiva y positiva tanto para el mantenedor como para el informador de vulnerabilidades externo.

Los informes de vulnerabilidad llegan a los encargados de mantenimiento de proyectos de código abierto desde todas las direcciones con diferentes niveles de calidad y detalle, desde problemas de proyectos públicos hasta informes enviados por correo electrónico y, a veces, incluso a través de las redes sociales. Esto presenta un desafío considerable para los mantenedores de software de código abierto (OSS). ¿Cómo ingiere, rastrea y clasifica los informes de vulnerabilidades externas de manera coherente, especialmente cuando la mayoría de los OSS son administrados por voluntarios en su tiempo libre?

El ecosistema de investigación de la vulnerabilidad contiene muchos actores diferentes, todos con diferentes motivaciones, que van desde lo comercial hasta lo altruista y todo lo demás.

La interacción eficaz y constante con la comunidad de seguridad puede resultar un desafío. A través del Laboratorio de seguridad de GitHub (divulgación: soy un empleado de GitHub), hemos observado muchos enfoques diferentes para recibir y clasificar informes de vulnerabilidades, que van desde interacciones casuales por correo electrónico hasta sistemas de seguimiento de errores con tickets completos.

Desglosaré la canalización del informe de vulnerabilidades en cinco pasos principales que hacen que la experiencia sea efectiva y positiva tanto para el mantenedor como para el informador de vulnerabilidades externo: recibir, reconocer, verificar, clasificar y publicar.

Recibir informes de vulnerabilidad
Indique claramente cómo y dónde desea recibir los informes de vulnerabilidad, independientemente de los recursos disponibles, para ayudar a evitar fricciones, informes perdidos o la publicación de informes no resueltos.

Establecer un politica de seguridad ayudará a estandarizar y normalizar la forma en que se entregan los informes de vulnerabilidad y cómo desea seguir su seguimiento. Al establecer una política o al hacer que las instrucciones para la presentación de informes estén disponibles (por ejemplo, en el archivo Léame de su proyecto), puede tomar posesión del proceso desde el principio. También encontrará que la mayoría de los reporteros externos de vulnerabilidades están más que felices de seguir instrucciones cuando se les proporciona explícitamente.

Reconocimiento de informes de vulnerabilidad
Una vez que se recibe un informe de vulnerabilidad, ya sea de forma pública o privada, es importante acusar recibo lo antes posible. Incluso si no hay recursos inmediatos disponibles para una investigación adicional, este reconocimiento inicial permite a los informadores de vulnerabilidades poner en cola el estado del informe al last. Dependiendo del estilo de divulgación (completa vs . coordinada), el reportero puede iniciar un reloj en la fecha límite de publicación para los detalles de la vulnerabilidad.

El laboratorio de seguridad de GitHub sigue un proceso de divulgación coordinado en el que los mantenedores tienen 90 días para clasificar de forma privada un informe de vulnerabilidad, después de lo cual los detalles completos del problema se publican en un aviso público. El reconocimiento rápido de un informe recibido le indica al reportero que usted responde y actúa rápidamente, y establece un tono positivo para el resto de la interacción.

Verificación de informes de vulnerabilidad
Involucrar al reportero de vulnerabilidades al verificar el impacto y la veracidad del reporte. Lo más possible es que ya hayan pasado un tiempo considerable considerando la vulnerabilidad en una variedad de escenarios, algunos de los cuales es posible que no haya considerado.

Solicite un contexto adicional sobre cómo creen que podría manifestarse una vulnerabilidad en su proyecto y cualquier prueba de concepto o detalles de configuración para determinar si el problema informado es realmente algo con un impacto de seguridad en su proyecto. A veces, no estará de acuerdo sobre si algo es una vulnerabilidad o de quién es la responsabilidad. La forma más productiva de abordar estos escenarios es mediante un discussion técnico desapasionado.

Recuerde, si bien los informes de vulnerabilidad externos pueden parecer ataques a la calidad del código, los informadores de vulnerabilidades a menudo manejan grandes volúmenes de informes al mismo tiempo y es poco possible que tengan una inversión personalized en su proyecto específico. Ambos comparten el objetivo común de establecer primero si un problema es de hecho una vulnerabilidad y, de ser así, resolverlo. Tratar al reportero como un colaborador, en lugar de un crítico externo, establece un tono efectivo para la interacción.

Informes de evaluación de vulnerabilidades
Después de verificar el informe y llegar a un consenso sobre su impacto, es hora de discutir la remediación. Es posible que usted y el periodista también tengan opiniones diferentes sobre el enfoque, por lo que debe corregir el problema de la manera que considere adecuada, teniendo en cuenta las preocupaciones del periodista. El reportero a menudo tendrá conocimiento de casos de esquina y omisiones de remediación que son fáciles de pasar por alto sin experiencia en investigación de seguridad. Una vez que crea que se solucionó un problema, pídale al informante que revise la solución propuesta en caso de que haya información adicional que pueda resultar en una solución más sólida.

Publicación de informes de vulnerabilidad
Un paso importante, aunque a veces omitido, en el proceso de divulgación es garantizar que el ecosistema en basic se dé cuenta del problema y su solución. No es raro que los proyectos solucionen un problema de seguridad reconocido en la rama de desarrollo true, pero luego no designen explícitamente la confirmación o la versión posterior como una solución o versión de seguridad. Esto puede generar problemas, ya que los consumidores de su proyecto y las dependencias posteriores solo pueden actualizarse en función de las actualizaciones de seguridad disponibles. Asumir que los consumidores intermedios siempre ejecutarán la última versión de su proyecto puede conducir a una proliferación innecesaria de código vulnerable.

El periodista publicará a menudo su propio aviso, pero usted también puede hacerse cargo de este proceso. Por lo normal, el informador de vulnerabilidades o usted mismo solicitará y asignará un número de vulnerabilidades y exposiciones comunes (CVE) en la fase de verificación.

En GitHub, puede publicar un Aviso de seguridad de GitHub (GHSA) para su proyecto, y dado que GitHub es una autoridad de numeración CVE (CNA), el proceso se simplifica. La publicación de una GHSA hace que su aviso esté disponible para el ecosistema de asesoramiento de GitHub y el ecosistema de seguridad de OSS más amplio a través de su CVE. La asignación del CVE y los detalles proporcionados en el mismo ayudan a garantizar que el ecosistema conozca las correcciones de seguridad disponibles para los consumidores intermedios.

Las vulnerabilidades de seguridad a menudo pasan desapercibidas para más de cuatro años antes de ser divulgado. Mejorar la forma en que interactúa con los informes de vulnerabilidad y los informantes puede ayudar a garantizar que los problemas no permanezcan sin resolver durante más tiempo del necesario. Si bien la clasificación eficaz de los informes de vulnerabilidades externos puede parecer abrumadora, incluso los proyectos y los encargados de mantenimiento con recursos limitados pueden crear una canalización estandarizada para recibir, reconocer, verificar, clasificar y publicar informes de vulnerabilidades. Al eliminar la ambigüedad del proceso, puede convertir los informes de vulnerabilidades en una experiencia positiva y colaborativa, beneficiando tanto a la investigación de vulnerabilidades como a las comunidades de desarrolladores y, en última instancia, a la seguridad de OSS.

Bas Alberts es un investigador principal de seguridad en el equipo del Laboratorio de seguridad de GitHub con experiencia en seguridad de la información centrada en delitos. Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia authentic