Resumen del panel: Cómo romper los malos hábitos de seguridad con Corey Quinn

El 8 de diciembre, Clinton Herget y Simon Maple, CTO de campo en Snyk, tuvieron la oportunidad de conversar con Corey Quinn, director de Economía de la Nube en The Duckbill Group, conductor de pódcast, curador de «Last Week in AWS» y personalidad mordaz de Twitter.

La conversación tomó varios giros divertidos: desde quejarse de la fila de una hora para comprar café en AWS re:Invent hasta que Corey proclamara que «los SBOM son una fantasía» (hay más contexto… sigue leyendo). En este blog repasaremos algunos de los momentos más destacados, pero si quieres escuchar todas las ocurrencias de Corey Quinn durante la conversación, mira el panel completo aquí.

Conclusiones de AWS re:Invent 2022

Como AWS re:Invent 2022 acaba de terminar, Corey y Clinton dedicaron unos minutos a compartir sus principales conclusiones. Corey hizo hincapié en que es importante priorizar conocer gente en lugar de asistir a sesiones.El día de AWS re:Invent tiene un número limitado de horas, y Corey prefiere aprovecharlas para conocer a personas de AWS en vez de sentarse en sesiones. Después de todo, las sesiones están disponibles a pedido después de la conferencia, pero no se puede conversar en persona con expertos de AWS.

A Clinton le entusiasmaron los detalles anunciados sobre el compromiso de Amazon Web Services con el Open Cybersecurity Schema Framework (OCSF). Al estandarizar un marco de seguridad, AWS está sentando las bases de un lenguaje interoperable y legible por máquinas para describir la seguridad de las aplicaciones. Clinton considera que este es el primer paso hacia una mejor conversación en toda la industria sobre los riesgos compartidos.

Una mirada al pasado: los horrores de la seguridad en AWS en 2022

Corey Quinn y Clinton Herget también repasaron 2022 y reflexionaron sobre algunos «horrores» de la seguridad en AWS que sin duda deben abordarse en el nuevo año. Entre los más importantes se encontraban:

La desconexión entre los entornos de desarrollo y producción

Según Clinton, uno de los problemas más importantes del desarrollo de software actual es la brecha entre los entornos de desarrollo y producción. Como todo en la nube es código, cualquier tipo de solución a los riesgos de seguridad debe aplicarse en el código. Dice: «Como operador, recibo una alerta roja intermitente que me asusta y dice: “Hay Log4J en un pod de un clúster de EKS; tienes que solucionarlo”. ¿Y luego qué? No hay una forma automatizada y legible por máquinas de saber qué archivo y qué repositorio de Git hay que modificar a raíz de esa notificación».

Demasiada confianza implícita en la cadena de suministro de software

Además, en 2022 los equipos de desarrollo de software cometieron el error de confiar demasiado en los componentes de su cadena de suministro de software. En vez de dar por sentado que cada pieza de software de código abierto y sus dependencias son seguras, los equipos deben verificar que los componentes de terceros realmente sean seguros.

SBOM que no profundizan lo suficiente

Corey también señaló que las listas de materiales de software (SBOM) actuales no son suficientes. En su opinión, no reflejan adecuadamente la naturaleza interconectada de las aplicaciones modernas. Puedes seguir las dependencias transitivas por un laberinto de «una dependencia de una dependencia de una dependencia», y así sucesivamente, sin llegar a entender por completo el nivel de riesgo de terceros en tu aplicación.

Soluciones para los desafíos de seguridad actuales

Clinton y Corey también hablaron sobre cómo las empresas deberían pensar en estos «horrores de 2022» y responder a ellos de cara al nuevo año. Conversaron sobre lo siguiente:

Complementar los SBOM con otras prácticas recomendadas

Entonces, ¿cuál es la solución para mejorar las prácticas actuales relacionadas con los SBOM? Corey Quinn bromeó diciendo que «para solucionarlo, en realidad hay que aplicar parches a los seres humanos».

En otras palabras, documentar todo el contenido de tu cadena de suministro de software no resolverá los problemas de seguridad; lo que sí lo hará es transformar la cultura organizacional y darles a las personas las herramientas para resolver problemas de seguridad. Una parte importante de esto consiste en reducir las alertas de seguridad: minimizar el ruido para que tu equipo pueda clasificar lo que realmente importa en tu SBOM.

Clinton también agregó que las organizaciones no deberían avergonzarse tanto de usar código abierto. Cuando entienden que su uso es aceptable —y no representa un riesgo potencial para el éxito de su negocio—, las organizaciones pueden ser mucho más transparentes sobre qué componentes compartidos usan y dónde.

Comprender a fondo los procesos actuales de tu organización

¿Cómo se relacionan tu IaC, la nube y el código fuente? ¿Cómo trabaja tu equipo de seguridad con tus desarrolladores, y viceversa? ¿Qué contexto tiene en cuenta cada una de estas personas a diario? Clinton y Corey destacaron la importancia de dar un paso atrás y responder estas preguntas. Esto marca una gran diferencia en cómo cada unidad de negocio percibe y aborda los riesgos.

Corey también mencionó que «duda mucho en terminar dando consejos que vayan más allá de “comprende el contexto en el que trabajas y toma decisiones que tengan sentido para ti”». Por eso, las organizaciones deben hacer preguntas más profundas y descubrir cuáles son las prácticas recomendadas de seguridad que mejor les funcionan.

Trabajar con el contexto de tu equipo de desarrollo, no en su contra

La seguridad suele ser una disciplina reactiva. Corey comentó que, aunque los esfuerzos de seguridad son necesarios, no impulsan el negocio de forma tangible. Por eso, a menudo quedan relegados. Si la mayoría de los departamentos piensa así sobre la seguridad, los equipos deben hacer que las prácticas de seguridad sean lo más fáciles de implementar posible.

El ciclo de vida del desarrollo de software (SDLC) debe protegerse con la menor cantidad posible de trabajo manual. Esto es especialmente importante cuando se trata de darles a los desarrolladores las herramientas para aplicar las prácticas recomendadas de seguridad: se trata de conectarse con su contexto y entender con qué trabajan a diario.

Año nuevo, nuevas oportunidades de seguridad en AWS

Esto es solo una pequeña parte de lo que conversaron Corey y Clinton. Mencionaron muchísimas oportunidades de seguridad en AWS para 2023: desde centrarse más en la seguridad que prioriza a los desarrolladores hasta aumentar la transparencia de las cadenas de suministro de software, y mucho más.

No te pierdas la conversación completa aquí. También puedes obtener más información sobre cómo la plataforma de seguridad para desarrolladores de Snyk puede ayudarte a hacer crecer tu programa de seguridad en 2023.