Divulgación responsable: el CEO y el CTO de CodeCov comparten lo aprendido de la brecha de seguridad

En enero de 2021, CodeCov sufrió un ataque a la cadena de suministro que expuso variables de entorno de sus clientes. En los meses siguientes, la comunidad de seguridad de aplicaciones examinó a fondo los detalles de la brecha y sus implicaciones técnicas para determinar qué salió mal y cómo combatir ataques similares en el futuro. Sin embargo, otro resultado interesante de la brecha fueron las conclusiones sobre un tema un poco menos atractivo: la divulgación responsable.

En octubre de 2021, Jerrod Engelberg, CEO de CodeCov, y Eli Hooten, CTO, participaron en el pódcast The Secure Developer para ofrecer una perspectiva interna de lo ocurrido. Su conversación con Guy arrojó luz sobre lo que implica estar en el centro de un incidente y planteó preguntas interesantes sobre cómo responder mejor a incidentes similares.

Escucha hoy el episodio completo

El incidente de seguridad de CodeCov

Antes de profundizar en las implicaciones de este episodio, repasemos rápidamente lo ocurrido. CodeCov es una herramienta de cobertura de código que genera informes legibles por máquinas mientras los desarrolladores ejecutan pruebas. El uploader de CodeCov procesa estos informes y distribuye los datos de cobertura relevantes. Los informes legibles por máquinas llegan al uploader de CodeCov a través de un proveedor de integración continua, como Github, Gitlab o Bitbucket, lo que sitúa a CodeCov en el centro de la cadena de suministro de software.

En el momento del incidente, CodeCov usaba un script curl|bash (también conocido como “curl pipe bash”, “curl bash piping”, etc.) para cargar informes a su servidor, alojado en un bucket de CDN con permisos `private write, public read`. El atacante logró extraer una credencial de una capa comprimida de la imagen Docker empresarial de CodeCov y acceder al bucket de CDN, donde realizó modificaciones maliciosas al script bash. El script alterado se incorporó al pipeline de CI de cada cliente que hizo una solicitud de extracción o de fusión durante el periodo entre la brecha y la revocación de las credenciales. Esto permitió a los atacantes infiltrarse en los entornos de los clientes donde se ejecutaba CI, imprimir las variables de entorno y enviarlas a un servidor de terceros para usarlas más adelante.

El impacto de este ataque varió según el cliente. Si el cliente gestionaba su CI en un repositorio público, probablemente no tenía nada importante almacenado en sus variables de entorno. Sin embargo, si usaba un repositorio privado, donde su CI interactuaba estrechamente con la pila tecnológica y almacenaba información secreta, la brecha era motivo de gran preocupación.

Como ocurre con cualquier ataque a la cadena de suministro, lo único seguro era que la información se había filtrado. No había forma de saber qué planeaban hacer los atacantes con las variables de entorno robadas, así que el equipo tuvo que actuar con rapidez y decisión.

La respuesta de CodeCov

Engelberg resumió así el principio de divulgación de CodeCov: “Si aunque sea un cliente no logra enterarse por nosotros y no toma las medidas adecuadas, ya es un cliente de más”. En la práctica, sin embargo, aplicar este principio presentó un desafío. Al iniciar sesión en CodeCov, los clientes pueden hacerlo con una dirección de correo electrónico o mediante un proveedor de identidad social (como OAuth, Github o Bitbucket), lo que mantiene privada su información de contacto. Una opción conveniente que más tarde se convirtió en un factor crítico del proceso de divulgación.

Para los clientes que crearon una cuenta directamente con CodeCov o compartieron su información de contacto, la solución fue sencilla. Se enviaron notificaciones por correo electrónico a todas las direcciones disponibles para avisarles de la brecha y animarlos a tomar medidas. Por desgracia, la mayoría de los usuarios de CodeCov no pertenecía a este grupo. Para responder a esta situación, el equipo de CodeCov hizo todo lo necesario para llegar a los demás clientes.

Después de informar del incidente a las autoridades federales, CodeCov hizo divulgaciones públicas; los medios tecnológicos difundieron y amplificaron los anuncios sobre la brecha, y la empresa inundó la aplicación con notificaciones. Aunque se tomaron todas las medidas razonables para garantizar que se avisara a su base de usuarios, vale la pena considerar las circunstancias que llevaron a una respuesta tan amplia.

Si CodeCov hubiera exigido que todos los usuarios compartieran información personal, como una dirección de correo electrónico, habría sido sencillo contactar a todos después de la brecha. Ofrecer a los clientes la opción de usar un proveedor de identidad social les permitió mantener más privados sus datos personales, pero también creó obstáculos importantes cuando se necesitaba una comunicación urgente. ¿Habría sido distinto el proceso de divulgación de CodeCov si avisar a los usuarios hubiera sido tan simple como enviar un correo masivo? Lo más probable es que no. Como dijo Hooten: “Creo que sabrás que lo estás haciendo bien cuando la respuesta sea obvia, aunque el camino a seguir sea doloroso o difícil”. Los valores fundamentales de CodeCov habrían llevado a su equipo a actuar con transparencia de todos modos.

Reducir el impacto en el negocio mediante la transparencia

Ninguna empresa puede salir completamente ilesa de un incidente de seguridad, pero CodeCov logró reducir el impacto negativo mediante una comunicación constante y transparente. A pesar de actuar con rapidez, perdió algunos clientes. Como explicó Engelberg, hubo “clientes que dijeron: ‘Oye, no podemos usarte en este momento’. O personas que defendían nuestro producto dijeron: ‘Oye, me encanta usarlo, pero impusieron una moratoria y ya no puedo usarlo’”. Sin la divulgación transparente del equipo, la pérdida de clientes habría sido mucho mayor. Es mucho más fácil corregir vulnerabilidades que recuperar la confianza.

Al igual que Snyk, CodeCov es una aplicación centrada en los desarrolladores, y ellos necesitan datos, no discursos. Al ceñirse a los hechos y pedir ayuda a la comunidad de seguridad en general, CodeCov mantuvo su credibilidad y su compromiso con los desarrolladores incluso en plena crisis.

Más allá de la brecha

La brecha de seguridad de CodeCov reveló verdades que van mucho más allá de un solo incidente. La naturaleza del ataque pone de relieve posibles dificultades que afectan a toda la industria. La principal es un problema de distribución de referencia. A medida que el software de código abierto se vuelve cada vez más vital para el ciclo de desarrollo, sus dependencias inherentes también se incorporan. Los beneficios del código abierto son innegables. La clave está en determinar cómo podemos usarlo de forma segura.

Para reforzar la seguridad después de la brecha, CodeCov agregó medidas como sumas de verificación SHA y verificación de firmas. Se animó a los usuarios a aprovechar estas verificaciones para asegurarse de que los scripts que descargaban provinieran directamente de CodeCov. Sin embargo, no hay forma de exigir el uso de estas verificaciones. Como explicó Engelberg: “Hasta que esto sea de confianza cero [...], siempre existe este intercambio, ¿verdad? Podemos hacerlo cada vez más sofisticado, pero sin duda es algo en lo que pienso mucho a medida que avanzamos y consideramos qué podría venir después”.

Podemos informar a los usuarios sobre los riesgos potenciales y darles herramientas para auditar el código, pero no podemos obligar a nadie a tomar medidas adicionales. El acuerdo de confianza entre la empresa y el cliente está profundamente arraigado en la cultura del desarrollo. Nuestra tarea como industria es determinar el mejor plan para mitigar los riesgos.

¿Quieres saber más sobre la brecha de CodeCov y lo que reveló sobre la industria? Visita The Secure Developer para escuchar el pódcast completo. Engelberg y Hooten abrieron las puertas de CodeCov y compartieron información de primera mano sobre la preparación interna en seguridad, consejos para CEO y CTO, cómo la empatía cambió el rumbo de la crisis y mucho más.