Seguridad de código abierto con Guy Podjarny, autor de O’Reilly
Hayley Denbraver
30 de agosto de 2019
0 minutos de lecturaLa semana pasada, Guy Podjarny, cofundador de Snyk, participó en una charla en vivo para hablar sobre su libro de O’Reilly Securing Open Source Libraries. En esta publicación resumimos algunas de las ideas más interesantes del seminario web. Si todavía no tuviste oportunidad de escucharlo, también puedes ver la grabación aquí. Además, Snyk te ofrece una copia del libro gratis.
¿Por qué es importante la seguridad del código abierto?
La conversación comenzó con una pregunta muy importante: ¿por qué deberíamos preocuparnos por la seguridad del código abierto? Guy explica que, a su juicio, hoy en día el mercado subestima los riesgos asociados con las bibliotecas de código abierto. La gran mayoría del código que implementa un equipo de desarrollo no es código propio, sino bibliotecas de código abierto. Esto es una excelente noticia, porque significa que los equipos no tienen que reinventar la rueda, pero también implica heredar los riesgos presentes en los componentes de código abierto.
En parte, este riesgo refleja la cantidad de bibliotecas de código abierto en comparación con el código original de tu aplicación. También se debe a que los componentes de código abierto son objetivos especialmente atractivos para los ataques. Los atacantes suelen ir primero por lo más fácil, y el código abierto ofrece un alto retorno de la inversión porque una vulnerabilidad puede explotarse contra muchas víctimas.
¿Cómo está abordando actualmente la industria este problema?
Una parte de la industria todavía no aborda este problema. Es posible que las personas se enteren de un exploit especialmente malicioso y lo atiendan de forma aislada. Pero no cuentan con una lista de materiales de código abierto. No hacen un seguimiento de qué componentes usan ni dónde. Tampoco supervisan realmente estos componentes en relación con la base de datos de vulnerabilidades.
Otros tienen en cuenta la seguridad al decidir qué bibliotecas de código abierto usar. Esto suele ocurrir antes de incorporar una biblioteca, pero no necesariamente se le da seguimiento con el paso del tiempo. Es posible que se descubran nuevas vulnerabilidades o que una versión actualizada introduzca otras, pero no existe un proceso para supervisar estos cambios.
Por último, algunas empresas invierten continuamente en encontrar y corregir vulnerabilidades de seguridad en el código abierto. Gran parte del libro explica cómo llevar esto a la práctica de la mejor manera. Empecemos por hablar de lo que ocurre cuando se divulga una nueva vulnerabilidad en una biblioteca de código abierto.
Una carrera contra el tiempo
Al considerar un proyecto, deberíamos asumir que tiene errores. No escribimos código perfecto ni escribimos o usamos código en condiciones óptimas. Esto también se aplica a los errores de seguridad. Por eso, es prudente asumir que cualquier proyecto de código abierto que incorpores tiene una vulnerabilidad de seguridad. Es posible que la comunidad aún no la haya encontrado.
Cuando se encuentra y divulga una vulnerabilidad, comienza una carrera. La comunidad se apresura a publicar una corrección y lograr que las personas la apliquen. Los actores maliciosos se apresuran a explotar la vulnerabilidad donde puedan. Como ya se conoce, ni siquiera tienen que encontrarla: solo necesitan ponerse en marcha. En cuanto se divulga la vulnerabilidad, el riesgo de seguridad asociado aumenta considerablemente. Los atacantes se aprovechan de la falta de buenas prácticas de seguridad. Los equipos quieren reducir al mínimo el tiempo entre la divulgación de una vulnerabilidad y su corrección. Nunca lograrás cerrar esa brecha por completo, pero no es lo mismo tardar una hora que un día, una semana, un mes o un año.
Entonces, ¿cómo pueden los equipos cerrar esta brecha? ¿Y qué papel desempeña cada persona?
DevSecOps en la práctica
DevSecOps es un término aspiracional que se escucha mucho en la industria. En realidad, se trata de colaborar entre distintas disciplinas para alcanzar un objetivo común: un producto funcional y seguro. Los pasos que da cada persona para contribuir a ese objetivo varían según trabaje en seguridad o en desarrollo.
La labor de una persona de seguridad es mantener protegida a su organización mediante la gestión consciente y deliberada de los riesgos potenciales. Por eso, debe comprender la postura de riesgo actual de la organización y poder priorizar qué riesgos atender primero. Sin embargo, si se espera que un profesional de seguridad se encargue directamente de corregirlos, el enfoque no será escalable y podría causar problemas, porque esa persona no conoce la base de código tan bien como el equipo de desarrollo.
En DevSecOps, los profesionales de seguridad cumplen un papel similar al de los ingenieros de confiabilidad de sistemas (SRE) en DevOps. Tienen una visión general del estado del sistema y establecen políticas. Además de sus responsabilidades de gobernanza, los integrantes del equipo de seguridad educan y empoderan a los desarrolladores con quienes trabajan para que se hagan responsables de sus tareas cotidianas. Su trabajo, desde la gobernanza hasta la automatización, permite que los desarrolladores tomen las decisiones de seguridad adecuadas y actúen en consecuencia.
Si el flujo de trabajo está bien configurado, la mayor parte de ese trabajo puede hacerse sin la intervención del equipo de seguridad. Si un profesional de seguridad ha definido buenas políticas y ha proporcionado a los desarrolladores buenas herramientas y capacitación, el trabajo diario puede continuar con poca o ninguna interferencia del equipo de seguridad.
El objetivo es corregir
¿Y cuál es el objetivo de un equipo DevSecOps? Corregir las vulnerabilidades.
Saber que tienes vulnerabilidades y dónde están es información útil, pero queremos trabajar para tener sistemas más seguros en general, y eso significa corregirlas. Si los desarrolladores no tienen las herramientas que necesitan ni el apoyo adecuado del equipo de seguridad o de la gerencia, a veces nos quedamos en encontrar la vulnerabilidad en lugar de corregirla.
Entonces, ¿cómo mantenemos el impulso y no solo encontramos los problemas, sino que también los corregimos? En muchas organizaciones, la corrección no ocurre hasta después de la clasificación de prioridades, que a su vez se realiza antes de involucrar al equipo de desarrollo. Clasificar las prioridades significa revisar la gravedad y el riesgo de la vulnerabilidad, pero no necesariamente qué tan fácil es corregirla. Una vez que termina este proceso, el equipo de desarrollo descubre que algunos problemas se corrigen fácilmente, mientras que otros son sistémicos y difíciles de resolver.
En el caso de muchas vulnerabilidades, corregirlas será más fácil que clasificarlas. La clasificación es necesaria cuando la corrección no es sencilla, pero si es fácil, ve directo al grano y corrígela. Si has invertido en facilitar la corrección, puedes resolver muchas de estas vulnerabilidades sin tener que clasificarlas primero.
La escala es otro obstáculo para corregir vulnerabilidades. Por lo general, los equipos usan muchos componentes y muchos de ellos son vulnerables, así que puede ser difícil abordar las vulnerabilidades a gran escala. Un buen plan de gobernanza puede ayudar, porque permite determinar fácilmente cuándo el equipo debe dejar todo para atender un problema emergente y cuándo puede incorporar la corrección de vulnerabilidades a su calendario habitual.
Guy resume el objetivo así: queremos encontrar y corregir los problemas que ya están en el proyecto y luego prevenir y responder a los problemas futuros. Encontrar. Corregir. Prevenir. Responder. En resumen, son cuatro acciones que hay que llevar a cabo a escala.
Detén la hemorragia
Empecemos. ¿Pero por dónde comenzamos?
La clasificación de prioridades suele asociarse con la medicina de emergencia. Imagina a un paciente que llega para recibir atención después de sufrir un accidente automovilístico grave. Puede tener varios problemas: quizás lleva una semana con un resfriado, tiene alergias estacionales o incluso una enfermedad crónica más grave. Vale la pena atender todos estos problemas con un médico, pero ninguno importa durante los primeros momentos después de que trasladan al paciente tras el accidente. Lo importante es detener la hemorragia. Los médicos hacen lo posible para evitar que el estado del paciente empeore y, una vez que está estable, pueden atender los demás problemas.
Cuando un equipo comienza a abordar la seguridad del código abierto, la tarea puede resultar abrumadora. Es posible que el proyecto ya tenga varios problemas. En ese caso, conviene recordar que primero hay que detener la hemorragia. Puedes abordar los problemas actuales después de evitar que la situación empeore. Enfócate en los cambios. Si sabes que tu proyecto tiene siete vulnerabilidades, abres un PR con nuevo trabajo y luego aparecen ocho, solo tienes que prevenir o corregir esa vulnerabilidad adicional para estabilizar el proyecto. Corrige los problemas de seguridad que aparecen en los cambios entre el código anterior y el nuevo. Una vez establecido este flujo de trabajo, puedes empezar a abordar los problemas de seguridad heredados.
Detén la hemorragia, pero no te detengas ahí. Prevén y responde. Encuentra y corrige. Atiende los problemas de seguridad continuos del código abierto y evita que surjan nuevos. Usa el código abierto con confianza, responsabilidad y seguridad.
