Skip to main content

Cómo Voltos usa Snyk para proteger su propio producto de seguridad

Escrito por
Headshot of Glenn Gillen

Glenn Gillen

22 de febrero de 2017

0 minutos de lectura

Esta es una publicación invitada de Glenn Gillen. Glenn es uno de los cofundadores de Voltos, un servicio que te ayuda a administrar de forma segura tus aplicaciones y credenciales de servicio, y es colaborador del curso en línea Tiny Security Wins: Quick steps to secure your dev environment. Anteriormente dirigió el ecosistema de complementos de Heroku y es un inversionista activo en startups de herramientas para desarrolladores en etapa inicial.

La mayoría de las empresas afirman públicamente que «nos tomamos muy en serio la seguridad de nuestros clientes», sobre todo porque decir lo contrario sería una mala decisión para su reputación. Para cualquier empresa que esté creando un producto enfocado en la seguridad, es un mantra que todo el equipo debe poner en práctica, ya que no hacerlo terminará por erosionar la confianza de los clientes y llevarnos a la quiebra.

En Voltos ayudamos a los desarrolladores a administrar y compartir las credenciales y la configuración de sus aplicaciones con su equipo y en toda su infraestructura. Perder de vista la seguridad pone en riesgo tanto a nuestros clientes como a nosotros, así que no estamos dispuestos a correr ese riesgo. Algunas de las primeras lecciones de seguridad informática que aprendí fueron no asumir que eres la persona más inteligente, no creer que tienes todas las respuestas, no dar por sentado que cubriste todos los aspectos y, sobre todo, no tener miedo de pedir ayuda.

Cuida tus espaldas con Snyk

Nos mantenemos bastante al día con los últimos anuncios de CVE cuando se publican, aplicamos parches rápidamente, hacemos pruebas y ponemos los cambios en producción. Sin embargo, cualquiera que haya intentado hacerlo sabe que puede requerir muchísimo trabajo. Además, con un ecosistema extenso de dependencias anidadas que se incorporan a través de las comunidades de Node, React y Ruby, el esfuerzo necesario no deja de crecer. Si a eso le sumamos que no es una tarea a la que una sola persona o equipo de la empresa se dedique al 100 %, es fácil imaginar que algo se nos escape.

Y algunas cosas sí se nos han escapado, como la vulnerabilidad de exposición remota de memoria de gravedad media que se muestra arriba.

Informe de vulnerabilidad de seguridad que muestra una exposición remota de memoria de gravedad media en el módulo request, introducida a través de voltos@0.0.15.

Este flujo de trabajo también da por hecho que conocer todas las CVE significa que tienes la mayor seguridad posible. La realidad es que cerca del 85 % de las vulnerabilidades de npm/node en la base de datos de Snyk no tenían una CVE anunciada.

Nos tomó menos de cinco minutos registrarnos en Snyk, analizar nuestras aplicaciones más críticas y encontrar un problema. Bastó un clic para crear un pull request (¡que incluía instrucciones para resolver el problema!). Nos convenció de inmediato.

Una parte integral del flujo de trabajo

Las mejores herramientas son las que se integran de forma discreta en tu flujo de trabajo o mejoran tanto tu productividad que adaptas el flujo a ellas. Cualquiera que haya intentado usar PGP con su correo electrónico sabe lo que suele implicar usar una herramienta enfocada en la seguridad dentro de tu flujo de trabajo. Es una verdadera molestia.

Lo que nos encanta de Snyk es que pasa inadvertido.

Configuración de la integración con GitHub que muestra las pruebas de pull request de Snyk habilitadas y todas las verificaciones aprobadas, sin vulnerabilidades conocidas.

Cada pull request se revisa automáticamente para detectar vulnerabilidades mediante la integración incorporada de GitHub. Como abrimos PRs temprano para conversar sobre las nuevas funciones, se identifican las nuevas vulnerabilidades potenciales en el momento en que se introducen. No una semana después, cuando queremos implementar los cambios y tenemos que buscar alternativas a las apuradas. No después de que el código ya llegó a producción. Ni como parte de una auditoría de seguridad trimestral, cuando los clientes llevan tres meses expuestos.

También analizamos nuestros repositorios con regularidad, independientemente de los cambios en el código, y Slack nos notifica por correo electrónico sobre las vulnerabilidades que se descubrieron desde nuestra última confirmación. Esto ha sido muy útil para las bases de código que se han vuelto más estables y tienen menos desarrollo activo; es muy fácil pasar por alto aquello que funciona silenciosamente en segundo plano, aunque pueda representar un gran riesgo.

Análisis puntual

A veces no queremos seguir nuestro flujo de trabajo habitual con pull requests de GitHub para analizar la seguridad de nuestro código. Quizás se trate de un proyecto personal, una prueba rápida en una nueva rama que todavía no estamos listos para compartir, o simplemente queramos analizar un lenguaje distinto del predeterminado que configuramos para el repositorio. La CLI de Snyk nos permite ejecutar ese análisis cuando lo necesitamos, sin obligarnos a seguir un único flujo de trabajo en todas las ocasiones.

Predicar con el ejemplo

Estado de seguridad de Snyk que indica que no se conocen vulnerabilidades, con una marca de verificación verde y un enlace a Detalles

Sin duda, contar con un tercero que nos ayude a detectar vulnerabilidades aporta un valor considerable. Sin embargo, creo que uno de los aspectos más valiosos es el refuerzo cultural sutil de la seguridad como algo que valoramos.

Cada pull request que alguien abre recibe esa pequeña marca verde de verificación. Es un recordatorio constante de que debes tener en cuenta la seguridad en todo lo que haces, en todo momento.

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.

Publicado en: