Acerca de divulgar las vulnerabilidades en la industria
La divulgación de vulnerabilidades es un área en donde la colaboración entre los reporteros de vulnerabilidades, tales como los investigadores de seguridad, y los mantenedores de proyectos es muy importante. Ambas partes necesitan trabajar en conjunto desde el momento en el que se encuentra una vulnerabilidad de seguridad potencialmente dañina, justo hasta que la vulnerabilidad se divulgue al público en general, idealmente con la disponibilidad de un parche. Habitualmente, cuando alguien deja saber, en privado, a un mantenedor sobre una vulnerabilidad de seguridad, este desarrolará una corrección, la validará y notificacá a los usuarios sobre el proyecto o paquete.
El reporte inicial de una vulnerabilidad se hace en privado y los detalles completos solo se publican una vez que el mantenedor reconoce el problema e idealmente generó remediaciones o un parche disponible, algunas veces con un retraso para dar más tiempo para que se instalen los parches. Para obtener más información, consulte la serie de hojas de referencia rápida de OWASP sobre divulgación de vulnerabilidades en el sitio web de OWASP Cheat Sheet Series.
Mejores prácticas para los reporteros de vulnerabilidades
Es una buena práctica reportar las vulnerabilidades a los mantenedores en privado. Cuando sea posible, como reportero de vulnerabilidades, te recomendamos evitar:
- Divulgar la vulnerabilidad públicamente sin dar oportunidad a los mantenedores para remediarla.
- Saltarse a los mantenedores.
- Divulgar la vulnerabilidad antes de que se encuentre disponible una versión corregida del código.
- Esperar que se te recompense por reportar un problema cuando no existe un programa público de recompensas.
Es aceptable que los reporteroes de vulnerabilidades divulguen una vulnerabilidad públicamente después de cierto tiempo, si han tratado de contactar a los mantenedores y no han recibido respuesta o si los contactaron y se les pidió esperar demasiado para divulgarla.
Recomendamos a los reporteros de vulnerabilidades que declaren claramente las condiciones de su política de divulgación como parte de su proceso de reporte. Aún si la vulnerabilidad no se apega a una política estricta, es una buena idea establecer expectativas claras para los mantenedores con respecto a los periodos de tiempo para cuando se pretende divulgar una vulnerabilidad. Para obtener un ejemplo de directiva de divulgación, consulte la directiva de divulgación de Security Lab en el sitio web GitHub Security Lab.
Mejores prácticas para los mantenedores
Como mantenedor, es una buena práctica indicar claramente cómo y dónde quieres recibir los reportes de las vulnerabilidades. Si esta información no está disponible claramente, los reporteros de las vulnerabilidades no sabrán cómo contactarte y podrían recurrir a extrar las direcciónes de correo electrónico de los desarrolladores desde los historiales de confirmación de git para intentar encontrar un contacto de seguridad adecuado. Esto puede causar fricciones, reportes perdidos, o que se publiquen reportes sin resolución.
Los mantenedores deben divulgar las vulnerabilidades oportunamente. Si hay una vulnerabilidad de seguridad en tu repositorio, te recomendamos que:
- Trates a la vulnerabilidad como un problema de seguridad en vez de como un error simple, tanto en tu respuesta como en tu divulgación de esta. Por ejemplo, necesitarás mencionar explícitamente que el problema es una vulnerabilidad de seguridad en las notas de lanzamiento.
- Reconoce la recepción del reporte de vulnerabilidades tan pronto como sea posible, incluso si no hay recursos inmediatos disponibles para la investigación. Esto deja ver que eres rápido para responder y actuar, e instaura un tono positivo para el resto de la interacción entre quien reporta la vulnerabilidad y tú.
- Involucra a quien reporta la vulnerabilidad cuando verifiques el impacto y la veracidad del reporte. Es probable que quien reporta la vulnerabilidad ya haya pasado tiempo considerándola en diversos escenarios, algunos de los cuales podrías aún no haber considerado.
- Remedia el problema conforme lo consideres necesario, tomando en consideración cualquier preocupación o consejo que te proporcione quien reporta la vulnerabilidad. A menudo, quien reporta la vulnerabilidad tendrá conocimiento de ciertos casos límite y atajos de remediación que pueden omitirse fácilmente sin tener un antecedente de investigación de seguridad.
- Reconoce siempre a quien reporta la vulnerabilidad cuando des crédito por el descubrimiento.
- Busca publicar una solución tan pronto como puedas.
- Asegúrate de que pones al tanto a todo el ecosistema sobre el problema y su remediación cuando divulgues la vulnerabilidad. No es raro encontrarse con casos en donde un problema de seguridad reconocido se fija en la rama de desarrollo actual de un proyecto, pero la confirmación de un lanzamiento subsecuente no se marca explícitamente como una corrección o lanzamiento de seguridad. Esto puede causar problemas con los consumidores en niveles inferiores.
El publicar los detalles de una vulnerabilidad de seguridad no da una mala imagen a los mantenedores. Las vulnerabilidades de seguridad están presentes en todas partes dentro del software, y los usuarios confiarán en los mantenedores que tengan un proceso claro y establecido para divulgar vulnerabilidades de seguridad en su código.
Acerca de los informes y la divulgación de vulnerabilidades en proyectos en GitHub
Hay dos procesos disponibles en GitHub:
- Proceso estándar: los informadores de vulnerabilidades se comunican con los mantenedores del repositorio, mediante la información de contacto ubicada en la directiva de seguridad del repositorio. A continuación, los mantenedores del repositorio crean un aviso de borrador del repositorio si es necesario.
- Informes de vulnerabilidades privados: los informadores de vulnerabilidades divulgan los detalles de vulnerabilidades directamente y de forma privada a los mantenedores del repositorio proponiendo un borrador de asesoramiento de repositorio y proporcionando detalles de sus conclusiones.
Proceso estándar
El proceso para notificar y revelar vulnerabilidades para proyectos en GitHub es el siguiente:
Si reportas una vulnerabilidad (por ejemplo, si eres un investigador de seguridad) y te gustaría proceder, revisa primero si existe una política de seguridad para el repositorio en cuestión. Para más información, consulta Agregar una política de seguridad a tu repositorio. Si esta existe, síguela para entender el proceso antes de contactar al equipo de seguridad de este repositorio.
Si no existe una política de seguridad en vigor, la forma más eficiente de establecer un medio de comunicación privado con los mantenedores es crear una propuesta que solicite un conteacto preferente para asuntos de seguridad. No sirve de nada que la propuesta sea visible al público inmediatamente, así que no debería incluir ningún tipo de información sobre el error. Una vez que se haya establecido la comunicación, puedes sugerir a los mantenedores que definan una política de seguridad para su uso futuro.
Nota:
_Solo para npm_: si recibimos un informe de malware en un paquete npm, intentaremos ponernos en contacto con usted de forma privada. Si no tratas la propuesta de forma oportuna, la divulgaremos. Para obtener más información, consulte [Notificación de malware en un paquete npm](https://docs.npmjs.com/reporting-malware-in-an-npm-package) en el sitio web de la documentación de npm.
Si ha encontrado una vulnerabilidad de seguridad en GitHub, notifique la vulnerabilidad a través de nuestro proceso de divulgación coordinada. Para obtener más información, consulte el sitio web GitHub Security Bug Bounty .
Si eres un mantenedor, puedes tomar la responsabilidad del proceso desde el inicio de la red de comunicación si configuras una política de seguridad para tu repositorio o, de otra forma, poner las instrucciones de reporte de seguridad claramente disponibles, por ejemplo, en el archivo README de tu proyecto. Para obtener información sobre cómo agregar una directiva de seguridad, consulte Agregar una política de seguridad a tu repositorio. Si no hay políticas de seguridad, es probable que alguien que reporta una vulnerabilidad intente enviarte un correo electrónico o contactarte en privado de alguna otra forma. Como alternativa, alguien podría abrir una propuesta (pública) con detalles de un problema de seguridad.
Como mantenedor, para revelar una vulnerabilidad en el código, primero debe crear un borrador de aviso de seguridad en el repositorio del paquete en GitHub. 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.
Para empezar, consulta Creación de un aviso de seguridad de repositorio.
Informes de vulnerabilidades privados
Los propietarios y administradores de repositorios públicos pueden habilitar informes de vulnerabilidades privados en sus repositorios. Consulta Configuración de informes de vulnerabilidades privadas para un repositorio.
Los informes de vulnerabilidades privadas proporcionan una manera segura y estructurada de que los investigadores de seguridad revelen de forma privada los riesgos de seguridad a los mantenedores de repositorios directamente dentro de GitHub. Cuando se notifica una vulnerabilidad, los mantenedores de repositorios reciben una notificación inmediata, lo que les permite revisar y responder sin el riesgo de divulgación pública prematura.
Sin instrucciones claras sobre cómo ponerse en contacto con los mantenedores, los investigadores de seguridad pueden sentirse obligados a revelar vulnerabilidades públicamente, como publicar en redes sociales, abrir problemas públicos o ponerse en contacto con los mantenedores a través de canales informales, lo que puede exponer a los usuarios a riesgos innecesarios.
Para los investigadores de seguridad, las ventajas de usar informes de vulnerabilidades privados son:
- Una forma clara y estructurada de ponerse en contacto con los mantenedores
- Un proceso más suave para la divulgación y la discusión de los detalles de vulnerabilidad
- La capacidad de analizar los detalles de vulnerabilidad de forma privada con el mantenedor del repositorio
- Reducción del riesgo de que los detalles de vulnerabilidad estén en el ojo público antes de que haya una corrección disponible
Para los mantenedores, las ventajas de usar informes de vulnerabilidades privados son:
- Recepción de informes en la misma plataforma donde se resuelven
- Investigadores de seguridad que crean o inician el informe de asesoramiento en nombre de los mantenedores
- Riesgo reducido de que las vulnerabilidades sean conocidas públicamente antes de que esté disponible una solución.
- La oportunidad de analizar los detalles de vulnerabilidades de forma privada con investigadores de seguridad y colaborar en la revisión
Los investigadores de seguridad también pueden usar la API REST para notificar de forma privada las vulnerabilidades de seguridad. Consulta Puntos de conexión de API de REST para avisos de seguridad de repositorios.
Nota:
Si el repositorio que contiene la vulnerabilidad no tiene habilitada la notificación de vulnerabilidades privada, tanto los investigadores de seguridad como los mantenedores de repositorios deben seguir las instrucciones descritas en la sección Proceso estándar anterior.
Pasos siguientes
Si es investigador de seguridad, consulte Creación de informes privados de una vulnerabilidad de seguridad para obtener información sobre cómo notificar de forma privada una vulnerabilidad a un mantenedor de repositorios.
Si es un mantenedor de repositorios, consulte Configuración de informes de vulnerabilidades privadas para un repositorio para habilitar informes de vulnerabilidades privados para el repositorio o Creación de una configuración de seguridad personalizada para administrarlo en toda la organización.