The Secure Developer: resumen de 2021

Si los últimos años fueron un ejercicio de adaptación, 2021 nos dio tiempo para reflexionar sobre nuestro desempeño. El impacto de la pandemia que dominó 2020 dio paso a una perspectiva más equilibrada sobre los desafíos que hemos superado en nuestra vida personal y profesional.

Como presentador de The Secure Developer, Guy Podjarny (fundador y presidente de Snyk) nos ofreció una mirada interna a la evolución de la seguridad de las aplicaciones. Los 22 episodios de este año reunieron a 23 invitados de distintas industrias para compartir sus perspectivas únicas. En el episodio de fin de año, Guy conversó con Simon Maple, Field CTO de Snyk, sobre los temas, consejos y expectativas de futuro que surgieron en los episodios de este año.

Temas comunes en la industria

A lo largo del año, los invitados de The Secure Developer plantearon innumerables puntos interesantes. Al reflexionar, Guy y Simon encontraron tres temas destacados que se repitieron en la mayoría de los episodios del podcast.

Contratar desarrolladores para los equipos de seguridad

El primero fue el cambio hacia la contratación de desarrolladores (o personas con experiencia en ingeniería de software) para formar equipos de seguridad. Históricamente, los equipos de seguridad estaban integrados por especialistas con conocimientos específicos que, pese a toda su experiencia, no participaban en las tareas cotidianas de desarrollo. La seguridad era un punto de control adicional para los desarrolladores, no una parte integral de su trabajo.

Integrar desarrolladores al equipo de seguridad ofrece una gran ventaja. Como explicó Daniel Bryant (director de DevRel en Ambassador Labs): «Los desarrolladores [...] cada vez son más responsables de todo el proceso. Mencionaste las pruebas y la observabilidad. Además, a los desarrolladores les gusta interactuar con las herramientas de cierta manera. Hay que llegar [...] a los ingenieros donde están». (ep. 90)

Una cosa es intentar enseñar empatía a los equipos de seguridad y explicarles la perspectiva de los desarrolladores y los desafíos que enfrentan. Cuando contratas a un desarrollador desde el principio, esa empatía ya está presente. No hace falta capacitar ni traducir, porque el equipo de seguridad entiende de forma natural la perspectiva del desarrollador. Esto aumenta la participación y abre oportunidades para que los equipos de desarrollo y seguridad se integren de manera más eficaz.

Seguridad enfocada en los desarrolladores

Otro tema importante de 2021 fue la necesidad de que los equipos de seguridad se adapten al desarrollo, y no al revés. Hace apenas unos años, los equipos de seguridad mitigaban las vulnerabilidades enumerando los problemas al final del ciclo de desarrollo. La separación entre los equipos de desarrollo y seguridad hacía que los desarrolladores sintieran que les dejaban todos los problemas al final de cada ciclo, y relegaba a los profesionales de seguridad a un rol regulatorio (y a menudo crítico).

En los últimos años, las empresas se dieron cuenta de que la seguridad debe integrarse en las prácticas de SDLC existentes y adaptarse a las necesidades de los desarrolladores. Una vez más, vemos la importancia de la empatía y la colaboración entre desarrolladores y profesionales de seguridad. Dev Akhawe (director de Seguridad en Figma) lo destacó al hablar de cómo abordaría los problemas de seguridad con los desarrolladores. Cuando lideraba la implementación de llaves de seguridad en Figma, «solía disculparme y decir: “Lo siento. Todavía no implementamos las llaves de seguridad”. Hay que tener cuidado con el phishing. [El] truco, probablemente, como que ha sido muy eficaz: ese truco mental de recordar que, en realidad, es responsabilidad del equipo de seguridad asegurarse de que los sistemas que usamos y los que desarrollamos no se comporten de forma inesperada. En lugar de decirles a los desarrolladores que tienen que hacer estas cien cosas». (ep. 88)

Este cambio no ha sido unilateral. En el mundo de las herramientas para desarrolladores, cada vez se reconoce más que «la seguridad no es algo que va por separado. Todas las herramientas para desarrolladores tienen cierta responsabilidad de integrar la seguridad en sus flujos de trabajo». A medida que entrelazamos el desarrollo y la seguridad, queda claro que, aunque «la seguridad se adapta a las herramientas y prácticas de desarrollo [...], los líderes de desarrollo están adoptando la seguridad y pensando en la responsabilidad que implica».

Seguridad a escala

El tercer tema fue la importancia de mantener una buena higiene de seguridad a escala. La capacidad de proteger sistemas al ritmo de la industria es esencial para el éxito de una empresa. Esto significa hacer bien lo básico, no prepararse para ciberataques dignos de una película. En AppSec, cerrar las puertas y ventanas suele ser suficiente para reforzar las defensas de una empresa frente a ataques de bajo nivel y prepararla para actuar con eficacia ante una vulnerabilidad grave. «Poder hacer [lo básico] a escala y con rapidez es muy difícil. Casi todos los programas e iniciativas... de este año se han enfocado en la idea de hacer bien lo esencial a escala y con rapidez».

Cuando los desarrolladores conocen los fundamentos para mantener seguros sus sistemas, pueden preparar estrategias para enfrentar problemas mayores, como la reciente vulnerabilidad Log4Shell. Mientras algunas empresas se apresuraban a averiguar qué había ocurrido y cómo les afectaba, otras (con una estructura y una higiene de seguridad integrales) pudieron seguir operando casi con normalidad. «Lo que hemos visto en Snyk es [...] un gran aumento de personas que agregan proyectos. Así que creo que también ha generado [...] cierta urgencia; incluso a quienes iban por buen camino les recordó que necesitan tener [...] visibilidad de todos sus proyectos. No pueden hacerlo de forma gradual, y esa es una de las diferencias clave entre desarrollo y seguridad». (ep. 106) Aunque las herramientas de desarrollo suelen usarse localmente y ampliarse caso por caso, las soluciones de seguridad necesitan una cobertura amplia e inmediata para ser eficaces. Ningún enfoque es incorrecto, pero Log4Shell y otros incidentes similares nos enseñaron que es arriesgado abordar las herramientas de seguridad como si fueran una solución de desarrollo.

Lo más destacado de los episodios de 2021

Log4Shell quizá haya sido nuestra lección más reciente, pero no es lo único que nos enseñó 2021. Aquí tienes algunos episodios que no te puedes perder.

La filtración de Codecov (#1022)

Guy conversó con CodeCov y su CEO, Jerrod Engelberg, y CTO, Eli Hooten, sobre cómo gestionaron la brecha de seguridad de 2021. El episodio estuvo lleno de ideas sobre cómo afrontar las prioridades contrapuestas durante un incidente de seguridad. Engelberg y Hooten comenzaron explicándole a Guy cómo reaccionaron internamente. Engelberg dijo: «Si aunque sea un cliente no logra comunicarse con nosotros [...] y tomar las medidas adecuadas, ya es un cliente de más». A partir de ahí, la conversación pasó de la ética de la divulgación a los riesgos implícitos que debemos gestionar como industria. «Siempre hay un acuerdo tácito, ¿verdad? Podemos hacer que ese acuerdo sea cada vez más sofisticado, pero sin duda es algo en lo que pienso mucho», dijo Engelberg.

Contenedores, procesos y el futuro de la seguridad (#103)

Liz Rice, directora de Open Source en Isovalent, nos presentó eBPF y compartió sus ideas sobre la importancia de las redes nativas de la nube. «Estamos viendo una adopción muy rápida de las tecnologías de nube. Creo que usar la nube será un requisito básico para cualquier empresa. Sin duda, ya no hablaremos de quienes la adoptan primero», dijo Rice.

Seguridad de aplicaciones en el sector público (#86, #95):

Varios episodios abordaron la creciente adopción de DevSecOps por parte de los gobiernos y las similitudes con las empresas de software privadas. Robert Wood, de CMS para Medicare y Medicaid, participó en el ep. 95; mientras que Nicolas Chaillan, CSO de la Fuerza Aérea de EE. UU., participó en el ep. 86. Ambos invitados afrontaban la necesidad de llevar organizaciones históricamente independientes hacia la mentalidad de plataforma necesaria para DevOps. Para Wood, esto significa «darle sentido a esta enorme cantidad de datos que tenemos porque, por lo general, todas estas actividades de seguridad funcionan en compartimentos aislados. Cada una opera de forma independiente o... genera perspectivas, pero no datos que luego puedan conectarse con otra cosa para generar perspectivas aún más valiosas».

La conversación de Chaillan con Guy destacó una de las diferencias claras entre DevOps en los sectores público y privado. Para los gobiernos, las desventajas de estar a la vanguardia son más evidentes que las ventajas, lo que genera una menor tolerancia al riesgo y una adopción más lenta, características de las organizaciones gubernamentales. Chaillan cree que «la ciberseguridad va a evolucionar. Creo que se enfocará mucho en la capacidad de monitoreo continuo. El gran riesgo está en las dependencias o los productos que usas y de los que sabes poco».

Temas de interés para 2022

Al asimilar todo lo que aprendimos este año, también podemos mirar nuestra bola de cristal para ver qué nos depara 2022. Guy les pide a todos sus invitados que hagan justamente eso y formulen hipótesis sobre el futuro de nuestra industria para cerrar cada episodio. Para terminar el año, Simon pudo invertir los papeles y pedirle a Guy su lista de temas y expectativas. A nivel de la industria, tres áreas serán fundamentales: la cadena de suministro, la nube y el desarrollo de formas de medir la seguridad a medida que se descentraliza cada vez más.

Seguridad de la cadena de suministro

La necesidad de proteger la cadena de suministro quedó demostrada con SolarWinds, CodeCov, Log4Shell y otros incidentes. «Hemos creado una red de dependencias entre servicios, componentes y personas, y tenemos que controlarla». A medida que las empresas se interconectan cada vez más, debemos colaborar como industria para definir y abordar los riesgos de la cadena de suministro.

Seguridad en la nube

Tradicionalmente, la seguridad en la nube se ha considerado una extensión de la seguridad de TI. Sin embargo, es probable que cada vez se reconozca más que la nube es software y necesita herramientas de seguridad a nivel de software para proteger la información confidencial.

Cuantificar AppSec

Medir la seguridad es importante porque necesitamos una forma de relacionar directamente la actividad del código con el riesgo. A medida que DevOps siga evolucionando, estos datos serán una parte esencial de la estrategia empresarial. Correlacionar las medidas de disponibilidad con las medidas del éxito empresarial permite que la seguridad siga ganando alcance e importancia.

En términos más generales, Guy espera que volvamos a pensar en la aplicación como un todo: una sola entidad con muchas partes móviles. Nos acercamos rápidamente a un punto en el que será imposible abordar cada vulnerabilidad de forma aislada. Por eso, la visión fragmentada de la seguridad no funcionará. Debemos considerar las aplicaciones y la cadena de suministro en su conjunto, y crear la taxonomía y las herramientas necesarias para hablar de seguridad a un nivel más alto.

En Snyk, nuestro objetivo es crear herramientas que hagan que la seguridad sea algo natural. Aligeramos la carga de los desarrolladores y les permitimos encontrar y corregir vulnerabilidades en solo 5 minutos. Súmate a tu equipo de seguridad de aplicaciones y descubre lo que puedes lograr hoy.