Panel de Discusión: Pruebas de Seguridad de Aplicaciones

Así que, hola a todos. Gracias por unirse a nosotros hoy en la mesa redonda sobre seguridad de aplicaciones y como mencionamos, las pruebas de seguridad de aplicaciones son uno de los temas muy importantes y manténganse atentos. Tenemos unos invitados realmente increíbles con nosotros como panelistas. Y voy a pedirles a todos los panelistas que se presenten uno por uno. Y antes de eso, permítanme presentarme. Mi trabajo diario es en una de las empresas multinacionales. Aparte de eso, en mi tiempo libre me dedico a trabajos pro bono, donde soy uno de los miembros de la Junta Directiva global de OWASP, y también dirijo algunas iniciativas de diversidad en InfoSec

Genial. Gracias, Pedona. Soy Scott Gerlach, CSO y cofundador de StackHawk, que es una herramienta de seguridad de aplicaciones dinámica enfocada en desarrolladores. Seré breve porque sé que estamos un poco ajustados de tiempo y quiero llegar a este contenido realmente genial. Gracias. Sam, te toca a ti.

Hola, soy Sam y soy un consultor independiente de seguridad de aplicaciones durante el día, y en mi tiempo libre, al igual que ustedes, hago trabajo pro bono y voluntariado para OWASP. Soy líder del capítulo de OWASP en Londres y también lidero un par de proyectos de OWASP. Eso es todo por mi parte. Gracias. Te toca a ti, Liren.

Hola a todos. Mi nombre es Yaron. Soy un defensor de desarrolladores en Snyk, donde ayudamos a los desarrolladores a construir software de código abierto de manera segura. Eso es todo. Te toca a ti, Bar.

Hola a todos. Soy Bar. Soy investigador de seguridad, hacker, desarrollador y arquitecto de software. Soy el CTO y cofundador de Neuralegion. Realizamos pruebas de seguridad de aplicaciones sin falsos positivos para desarrolladores. Es genial estar aquí. Gracias.

Esta vez comenzaré con Bar, así que iremos en orden inverso. Muy bien, en primer lugar, creo que es un tema interesante para discutir. DevOps en general se trata de conectar dos comunidades. Se trata de conectar a las personas de operaciones y las personas de desarrollo. Solían ser rivales antes y creo que es muy importante y una muy buena idea tratar de crear algún tipo de puente entre esas dos secciones. DevSecOps más específicamente se trata de introducir la seguridad en la conversación. Se trata de ver cómo esos conceptos de seguridad, herramientas y otras técnicas pueden ayudar a habilitar y no interrumpir a los desarrolladores y al personal de operaciones con lo que hacen. Sí, eso es genial. Lyrin, te toca a ti.

Sí, creo que DevOps ha estado ahí para permitirnos, la forma en que lo veo es que está sentando las bases para permitirnos escalar lo que significa operaciones. Así es como veo que realmente ayuda y cobra vida con DevSecOps. Para mí, significa que no se trata solo de automatización, se trata de establecer la infraestructura, poner todo, la automatización que se necesita para que los desarrolladores luego automatizar la seguridad dentro de ella. No se trata de usar una herramienta específica, una u otra, o en una etapa específica, se trata de construir ese flujo de trabajo, esa infraestructura, todo lo que luego se une y fluye de manera muy fluida. Así es como veo DevSecOps. Sí, totalmente cierto. Sam, te toca a ti.

Sí, para mí, creo que DevSecOps en primer lugar es una filosofía, es una cultura. Es una cultura de introducir la seguridad como código en todo, asegurarse de que las personas traten la seguridad como su responsabilidad, como su trabajo. Así que no se trata solo de herramientas, no se trata solo de automatización, se trata de una mentalidad, seguridad primero, eso es lo que realmente debería ser DevSecOps. Es una mentalidad global para todos nosotros. Sí, es cierto. Scott, te toca a ti.

Sí, estoy a punto de meterme en problemas aquí. Siento que necesito un meme de 'cómo empezó y cómo va' para esto. Porque creo que lo que todos dijeron es la visión de DevSecOps, ¿verdad? La seguridad es parte del desarrollo y operación de aplicaciones. Y tenemos que seguir incorporando la seguridad para que las personas sigan hablando.

Ahora, cuando hablamos de DevSecOps y hablamos de que las pruebas de seguridad se están convirtiendo en una parte integral del pipeline de DevOps. Entonces, desde tu perspectiva, ¿cuánta importancia tiene la automatización y cuánta relevancia tiene? Porque todos dicen que tenemos cultura, tenemos herramientas, tenemos de todo en torno a DevOps y ahora también estamos hablando de cultura. Así que ¿cuánto papel juega la automatización en eso? Y creo que podemos empezar con Liron.

Sí, claro. Cuando hablamos de la importancia de la automatización y la seguridad en el pipeline, necesitamos entender que cuando decimos pipeline de DevOps, básicamente estamos hablando de poder entregar algo, ¿verdad? Básicamente, si no puedes entregar algo, si el pipeline está bloqueado, básicamente no estás entregando, no estás lanzando algo que necesitas para los clientes. Por cierto, eso podría ser una corrección, una corrección de seguridad o una corrección para una regresión. Así que ese es un aspecto muy importante. Y automatizar la seguridad en eso significa que ahora estás dando a la organización, al negocio, a la empresa, una forma de poder enviar algo rápidamente de manera segura. Así que eso es algo obvio. Pero lo que creo que estamos pasando por alto aquí es que muchas veces, cuando hablamos de DevOps, ese pipeline es algo que, muchas veces, también desde mi experiencia como desarrollador anteriormente, ha sido mucha magia que ocurre detrás de escena, ¿verdad? La gente simplemente fusiona algo, hay una solicitud de extracción que se fusiona majestuosamente, va a producción, está ahí. Pasó por muchas automatizaciones y pruebas de regresión y pruebas visuales y pruebas de seguridad y pruebas de rendimiento, muchas cosas. Así que tener la seguridad automatizada en eso, eso básicamente te da más salvaguardias y la capacidad de entregar rápidamente de manera segura. Y tienes que hacerlo a lo largo del ciclo de vida de la aplicación, ¿verdad? Tienes que hacer algo cuando piensas en las aplicaciones de hoy en día, esto es más como un mundo de seguridad de aplicaciones nativas en la nube, porque no son solo tus dependencias, es tu contenedor y luego es tu YAML de Kubernetes. Muchas cosas que básicamente están presentes cuando realmente haces clic en ese botón de fusión y algo mágicamente va a producción. Y luego esa automatización de seguridad que está básicamente en todo el proceso, eso es lo que creo que va a cambiar la vida en términos de cómo integras la seguridad en el ciclo de vida de DevOps. Sí, estoy totalmente de acuerdo contigo en eso.

Ahora, también quiero conocer la perspectiva de Barr en este aspecto, porque él trabaja con herramientas, trabaja con seguridad del producto, así que quiero conocer la perspectiva de Barr sobre cómo la automatización está ayudando a sus equipos y al trabajo que está haciendo en torno a la seguridad del producto.

Creo que lo más obvio es que la automatización es clave, ¿verdad? No podemos esperar que nada funcione en este paradigma de DevOps, DevSecOps, sin tener automatización. Creo que eso es algo que muchas empresas pasan por alto, es que los desarrolladores, aunque realmente queremos, como nuestro sueño, es que cada desarrollador sea este tipo de superhéroe para la seguridad, que sepa todo sobre seguridad, pueda ejecutar sus herramientas, realizar pruebas manuales, verificar todo, y eso no es cómo va a funcionar. Y creo que incluso de la mejor manera ni siquiera deberíamos esperar eso. Los desarrolladores están aquí para crear cosas increíbles. Están aquí para construir. Y creo que utilizando la automatización y brindando a los desarrolladores las herramientas adecuadas a través de esta automatización, no para convertirlos en expertos en seguridad, sino para permitirles ver esos conceptos de seguridad, esos errores, porque la seguridad al final son solo errores. Entonces, darles lo que saben, que son errores, pero de una manera de seguridad, ahí es donde realmente apuntamos. Y ahí es donde la seguridad y GitHub y todas esas increíbles nuevas integraciones están sucediendo. Y realmente, creo que ese es el punto principal.

Sí, cierto, cierto. Y acabo de darme cuenta de que hay algo que quiero preguntar a todos los panelistas. Pero antes de eso, quiero preguntarle a Scott o a Sam si quieren agregar algo, basado en su experiencia con DevSecOps.

Sí, creo que algo importante sobre la automatización es, en primer lugar, que debe estar presente, ¿verdad? Porque obviamente, si no automatizas las herramientas de seguridad

Cierto, Scott. Sí, todos dijeron cosas increíbles, solo quiero agregar un poco. La automatización es obviamente muy importante, pero algo que dijo Lirian es realmente importante, y es no hacer que cosas en bloque sucedan en CICD. Si tu desarrollador no puede fuera de CICD, comprender o ejecutar el proceso o tener control sobre lo que está sucediendo con las herramientas de security o las herramientas de QA, o lo que sea, y no puede reproducir lo que está a punto de suceder en CICD, es cuando comienzas a introducir esa pregunta, ¿cómo puedo resolver esto porque sigue bloqueándome y no entiendo qué está haciendo? Así que asegurarse de que esas cosas estén disponibles fuera de CICD y sean accesibles y todas esas cosas buenas, y creo que es tan importante como la automatización. En las bibliotecas de Apache Strux, es una pequeña vulnerabilidad que probablemente pueda implementar. Una pequeña vulnerabilidad que probablemente pueda implementar sin ella. Sí, recuerdo eso. Y mencionaste la forma correcta en que los desarrolladores están tratando de encontrar formas de evadir la security porque ellos son los superhéroes del desarrollo y estamos tratando de convertirlos en superhéroes de security. Pero en lugar de eso, podríamos convertirlos en campeones de security y luego podemos pedirles ayuda. Ahora, Scott, una pregunta para ti sobre lo mismo, como los desarrolladores están trabajando rigurosamente para asegurarse de que las aplicaciones que se desarrollan sean como ellos las han imaginado o como los clientes las han imaginado. Entonces, cuando se trata de pruebas de security, a veces, todos sabemos que se convierte en una carga o algo que sobrecarga a los desarrolladores. Y todos hemos sido desarrolladores así que podemos entender esa presión. Entonces, ¿hay alguna herramienta enfocada en el desarrollador que esté disponible o hay algo en lo que el equipo de security pueda ayudar a los desarrolladores para que sea útil, para que el pipeline de CICD sea más rápido o más fácil para los desarrolladores para que no sientan que hay algo que les está presionando, sino que sientan que es parte de mi trabajo diario y está totalmente bien hacerlo? Esa es una gran pregunta. Creo que hay muchos logotipos en este panel aquí y allá y aquí que son excelentes, excelentes ideas sobre dónde puedes comenzar. Sabemos que hay algunas herramientas de código abierto que hacen cosas similares a todos los productos que representamos aquí, pero tener ese enfoque comercial en el usuario y asegurarse de que las cosas funcionen como se supone que deben funcionar es realmente bueno. Pero la parte más importante es simplemente comenzar, ¿verdad? Es elegir algunas cosas, ya sea SCA o análisis de código estático o DAST, o cualquier otra cosa, elegir una y iterar desde allí si estás comenzando. Si tu equipo de seguridad de aplicaciones tiene dificultades para obtener resultados para solucionar porque el valor está en solucionar errores de security, no en encontrar errores de security. Y estás tratando de reorganizar, comienza pequeño. Ese siempre es mi consejo para las personas que están luchando como equipo de seguridad de aplicaciones, simplemente comienza con una herramienta en un proyecto y itera a partir de ahí. Asegúrate de que las cosas funcionen correctamente y continúa impulsando la adopción por parte de los desarrolladores. Entonces, Liren, ¿quieres agregar algo más? Sí, me gustaría intentarlo. Es algo que me apasiona. Estoy de acuerdo con ambos. Creo que tanto Scott como Bar mencionaron esto de una manera en la que la eficiencia o efectividad del desarrollador para moverse rápido y de manera inteligente también es muy importante. No creo que nadie espere que los desarrolladores sean los próximos expertos en security increíbles de la empresa. Si lo son, eso es increíble, pero no es una exigencia.

No podemos hacer eso. Pero en cambio, lo que podemos hacer es ayudarles a solucionar los problemas. Así que tomaré dos ejemplos prácticos de lo que esto significa para que podamos relacionarlo con un ejemplo en lugar de una discusión abstracta aquí. Y eso es, por ejemplo, si usas Container, y tiene 500 vulnerabilidades, en ese punto, ¿qué haces con esa información? Tradicionalmente, security diría, lo solucionaremos. Pero, ¡hey!, ese tag de imagen de nodo tiene 500 stacks base diferentes que podrías usar, ¿verdad? Alia dice, ¿debería usar Slim o Buster o diferentes versiones de Linux o diferentes versiones de Node.js, a cuál debería moverme realmente? Así que creo que una herramienta de seguridad centrada en el desarrollador es aquella que te ayuda a tomar esa decisión, te dice qué imágenes base alternativas podrías probar para hacerlo. De manera similar, si hablamos de AppSec moviéndonos un poco más abajo desde el nativo de la nube aquí sobre los contenedores a tal vez, por ejemplo, desarrolladores de Java, una de las cosas que los desarrolladores... Veo frustración en los desarrolladores cuando necesitan escanear las dependencias y tienen este problema de, bueno, tal vez no use esa dependencia. Tal vez esa función vulnerable en la dependencia no sea llamable, ¿verdad? En el código, tal vez mi código aún no lo llama, está empaquetado, pero no se está llamando. Así que creo que si tenemos una herramienta que te ayuda y te dice que hay una vulnerabilidad alcanzable desde tu código a esa dependencia vulnerable, eso te ayuda a tomar una decisión. Ahora tienes cien dependencias que son vulnerables en tu archivo POM, pero sabes cuáles priorizar para solucionar primero. Esa es la forma en que ICS básicamente ayuda a los desarrolladores a solucionar los problemas.