Automatizar Pruebas de Seguridad de Aplicaciones Web usando GitHub Actions (del equipo de StackHawk)

Bienvenido al taller de Test.js. Invitados y asistentes, es genial ver a todos aquí. Quería darles la bienvenida a nuestro pequeño espectáculo, lo que haremos hoy es. Automatizar las pruebas de seguridad de aplicaciones web utilizando Java y React. Es un navegador web.

Es útil tener Discord, la aplicación de Discord, vamos a chatear mucho en Discord, y les contaré sobre eso en un minuto. Pero básicamente lo que vamos a hacer es hacer un fork de un repositorio para una aplicación de ejemplo, una aplicación de node.js. Y lo que haremos en este taller es pedirles que envíen preguntas aplicación de ejemplo, una aplicación de node.js. Y someteremos eso a una rutina de construcción y pruebas automatizada utilizando las acciones de GitHub, que es el sistema de CI/CD de GitHub integrado en GitHub, y es gratuito para su uso por cualquier persona hasta, como, 2000 minutos al mes, algo así.

Así que construiremos esa aplicación, y luego la someteremos a una serie de pruebas, una variedad de diferentes pruebas de seguridad. Y nuevamente, lo único que realmente necesitas es un navegador web, porque todo lo que vamos a hacer es a través de la interfaz web de GitHub para que podamos crear archivos, hacer un fork de un repositorio, crear archivos, los archivos que necesitamos, ejecutar las pruebas que necesitamos utilizando las acciones de GitHub y demás. Lo que realmente necesitas para unirte a nosotros es unirte a nuestro Discord. Y unirte al canal de pruebas de seguridad de aplicaciones web de octubre de 2022 en Discord. Entonces, voy a publicar ese enlace aquí para todos. Así que, si puedes ir al primer enlace que proporciono, el discord.gg.xnmb.. Haz clic en ese enlace y deberías unirte a nuestro servidor de Discord. Y luego, en el canal general, simplemente da un pulgar arriba a nuestro mensaje de bienvenida. Eso te permitirá ver el resto de los canales. Luego, una vez que estés allí, únete a ese canal de pruebas de seguridad de aplicaciones web de octubre de 2022. Y luego, cuando estés en ese canal de pruebas de seguridad de aplicaciones web, danos un pulgar arriba también, para que sepamos que estás ahí.

Ya tenemos una pregunta. Esto es genial. Parece que no puedo revisar los repositorios. No te preocupes por eso. Solo puedes ver el repositorio a través de nuestro sitio web. Solo estamos siguiendo el readme que está allí. Te mostraré cómo se ve eso. Cuando llegues al repositorio de GitHub de esta masterclass de GitHub actions, lo único que realmente necesitas de allí es este readme, y puedes hacer clic en los enlaces para acceder a la información allí.

Lo primero que haremos al crear la aplicación es hacer un fork de otro repositorio. Muy bien. Parece que hay personas uniéndose al servidor de Discord. Un enlace de GitHub en la ventana del panel de discusión. Creo que nos referimos a esta ventana. Así que déjame darte este enlace. Aquí está el libro de trabajo o guía para la masterclass que seguiremos. Si algo de esto no funciona, aún deberías poder seguir el curso. Nuevamente, lo único que necesitas es un navegador web y acceso a GitHub, es decir, una cuenta de GitHub. Voy a comenzar. Siéntete libre de hacer preguntas y ayudarse mutuamente en el chat de Discord. Y Mimi, si puedes ayudar a las personas que tengan problemas, eso sería genial. Voy a comenzar con una diapositiva. Gracias.

Muy bien. Aquí vamos. Nos encantan las preguntas, por favor déjanos un mensaje en Discord. Nos encanta ayudar. Mi nombre es Zachary Conger. Soy un arquitecto de soluciones de StackHawk. Tengo algunos hobbies. Realmente me gusta DevSecOps y toda esta masterclass trata sobre las rutinas y prácticas de DevSecOps. Es una masterclass realmente divertida. Todo lo que aprendas aquí será muy útil tanto en tu vida laboral como en tus proyectos personales en casa, para trabajar en tus propias aplicaciones. Asegurarlas, construirlas automáticamente, ese tipo de cosas.

Quiero contarte un poco sobre la empresa para la que trabajo, StackHawk. Es una de las herramientas que utilizaremos al final de esta masterclass. Tenemos una herramienta de escaneo de seguridad llamada DAST, que es una utilidad de escaneo de seguridad dinámica. Esto significa que se ejecuta contra tu aplicación en ejecución. En realidad, sondea tu aplicación en ejecución en busca de vulnerabilidades enviando solicitudes maliciosas y analizando las respuestas. Esta clase de utilidad DAST ha sido una de las más difíciles de automatizar en CI/CD. Creemos que hemos resuelto esa dificultad. Algunas cosas sobre nosotros, estamos más cerca del código. Somos una herramienta orientada a los desarrolladores, fácil de automatizar en CI/CD. Tenemos una gran cobertura para aplicaciones web y APIs. Y tenemos una configuración muy sencilla que solo requiere un archivo de configuración YAML. Hablaremos más sobre eso más adelante en la masterclass.

Nuestra agenda de hoy será utilizar GitHub Actions para construir automáticamente una aplicación de nodo. Luego agregaremos una serie de pruebas a ese proceso de construcción que vamos a configurar. La primera será una herramienta llamada Dependabot. Es otra herramienta de GitHub que se puede utilizar para escanear tus dependencias y buscar vulnerabilidades en esas dependencias. Luego, en el tercer paso, agregaremos CodeQL, que es otra utilidad de GitHub. Eso escaneará tu base de código y buscará patrones vulnerables en el código real de la aplicación y marcará cualquier cosa que parezca peligrosa. Y luego, el paso final será agregar StackHawk, que es nuestro escáner DaaST, y es un escáner dinámico. Lo usaremos para escanear una instancia de la aplicación en ejecución en el pipeline. Al final de este pipeline de construcción, se construirá tu aplicación, se probarán las dependencias en busca de vulnerabilidades, se probará el código en busca de vulnerabilidades y, finalmente, se probarán las vulnerabilidades en tiempo de ejecución. Muy bien, el primer paso será configurar nuestras GitHub Actions.

GitHub Actions es un sistema de CI/CD que está integrado en GitHub, todos lo tienen disponible siempre y cuando tengan una cuenta de GitHub, es gratuito, por lo que en tu cuenta gratuita de GitHub puedes utilizarlo para tus propios repositorios de código. Utiliza un lenguaje de configuración YAML sencillo y tiene un gran mercado de lo que ellos llaman acciones, y las acciones son como los plugins de Jenkins, si alguna vez has utilizado Jenkins, son básicamente pequeños paquetes de funcionalidad que facilitan mucho la creación de un pipeline de construcción que hace cosas realmente interesantes. Puedes usarlo para construir aplicaciones Java o aplicaciones de nodo, puedes usarlo para ejecutar todo tipo de pruebas y demás. Es impulsado por eventos, por lo que realmente puedes crear pipelines muy complicados y sofisticados utilizando esto, puedes acceder a él a través de la API. Tiene una gestión integrada de secretos, que es realmente importante para las pruebas de seguridad y para la seguridad en general, porque hay algunas cosas que quieres que se integren en tu pipeline de CI/CD a veces, como contraseñas o claves de API, pero no quieres poner eso en tu repositorio de GitHub porque eso puede ser una vulnerabilidad de seguridad en sí misma. Para otras personas, podría entrar en contacto con personas a las que no quieres que sepan cuáles son esos secretos. Y finalmente, es gratuito, por lo que puedes usarlo, obtienes 2000 minutos de tiempo de construcción gratis al mes, lo cual es realmente generoso. Para comenzar, simplemente hagámoslo. Si ya has iniciado sesión en GitHub, vamos a hacer un fork de esta aplicación llamada Vulnode Express en el repositorio Kaka y proporcionaremos un enlace para eso. Mimi está dejando un enlace en Discord y probablemente también deberíamos dejarlo en el chat de Zoom, solo para asegurarnos. Cuando llegues aquí, lo que vamos a hacer es simplemente hacer un fork de esta aplicación. Desde esta página principal del repositorio de código de Vulnode Express, verás, por supuesto, todos los archivos allí. Este botón aquí que dice Fork, simplemente haz clic en eso y vas a hacer un fork de esta aplicación a tu propio repositorio o a tu propia organización. Mi organización se llama EConger, tú podrías tener un par o tu propia personal, solo asegúrate de apuntar a tu propio repositorio y haz clic en Crear Fork. Entonces, nuevamente, desde este repositorio, hago clic en el botón Fork y luego ingreso el nombre del repositorio que quiero copiar. Haremos clic en Crear Fork. Y en solo unos segundos, deberías tener un fork en tu propia organización.

Entonces ahora lo he copiado de Kaka a mi propia organización, EConger. Se llama Vulnode Express, y me dice que esto fue bifurcado de Kaka, Vulnode Express. Y Mimi, avísame si hay alguna pregunta si necesitas que retroceda o repase algo. Claro. Creo que hasta ahora todo está bien. Estoy respondiendo algunas preguntas en el chat. Y, a todos, si pueden dar un pulgar hacia arriba a cada paso en Discord a medida que lo completen, solo para que sepamos que están bien y para que podamos adaptar el ritmo para saber si necesitamos ir más despacio o aclarar algo en el camino. Genial. Muy bien. Entonces, a partir de aquí, lo que vamos a hacer es volver a este manual. Ya hemos bifurcado la aplicación Vuln Node Express. Ahora vamos a ir a la sección de código y vamos a crear este nuevo archivo. El archivo se llama, está en el directorio .github /workflows/build and test.yaml. Y vamos a copiar el contenido de este archivo y simplemente pegarlo allí. Así que en realidad voy a copiar y pegar desde aquí, lo primero que voy a hacer es crear este archivo. Para hacerlo desde la bifurcación de Vuln Node Express que creé, ve a añadir archivo, crear nuevo archivo y pega el nombre de ese archivo y debería completarlo automáticamente. Entonces .github. Recuerda el punto al principio de esa barra workflows/build and test. Esta estructura de directorios, por cierto, es especial para GitHub. GitHub coloca muchos archivos diferentes que puede buscar en el proceso de operaciones de GitHub. Y este directorio especial .github/workflows, cualquier archivo que GitHub encuentre allí, lo considerará como un flujo de trabajo de GitHub Actions. Y tratará de ejecutarlo. Así que cuando vea este archivo del que estoy a punto de copiar el contenido, simplemente haz clic en copiar y pégalo allí. Entonces, cuando vea este archivo, tratará de determinar si en realidad es un flujo de trabajo. Y si lo es, tratará de respetarlo y hacer lo que el flujo de trabajo dice que debe hacer. Y permíteme describir exactamente lo que el flujo de trabajo dice que hará. Entonces, el flujo de trabajo se llama Build and Test, es un flujo de trabajo de GitHub Actions. Y este flujo de trabajo de construcción y pruebas se activará cada vez que haya un envío a la rama principal, o cualquier solicitud de extracción en absoluto. Así que si hacemos solicitudes de extracción a la rama principal o cualquier otra rama, todo este flujo de trabajo debería iniciarse. ¿Qué hace este flujo de trabajo? Tiene un trabajo, y podrías tener varios trabajos, pero este solo tiene un trabajo llamado Build and Test. Y se ejecuta en una instancia de Ubuntu 20.04, que es una máquina virtual completa, tiene alrededor de 7 GB de memoria, tiene algo de espacio en disco adicional y tiene una gran cantidad de herramientas diferentes, por lo que en general es un servidor muy bien poblado que tiene muchas herramientas diferentes que podrían serte útiles para construir y probar código. Luego vamos a pasar por una serie de pasos de pruebas, y estos pasos utilizan acciones y las acciones nuevamente son como estos complementos, estos paquetes de funcionalidad que proporciona GitHub. El primero se llama Checkout v3, y cualquier cosa que comience con actions, si es una acción de GitHub, esta es en realidad una acción creada por GitHub, por lo que es una de sus acciones estándar y todo lo que hace es verificar tu base de código y averiguar el lugar correcto para verificar tu base de código. Tengo una pregunta, ¿puedo repetir cómo encontrar la ruta de ese archivo que estás mostrando ahora mismo? ¿Este archivo? Entonces, si estás en la lectura, está en el paso uno y se llama .github/workflows/build and test y simplemente vas a crear ese archivo desde la interfaz de GitHub y volveré y lo repasaré en un momento. Así que gracias por esa pregunta. De todos modos, verificamos el código y luego vamos a instalar Node.js14x para poder construir nuestra aplicación de Node.js y nuevamente estamos usando una acción oficial de GitHub llamada set up node y simplemente pasa por la dificultad de instalar la versión correcta de Node, lo cual puede ser un problema para instalar la versión correcta de NPM. Luego vamos a instalar las dependencias y esto va a pasar por NPM install, tal como dice, y luego vamos a ejecutar pruebas unitarias si las hay y spoiler, en realidad no tenemos pruebas unitarias, pero si las tuviéramos, eso es lo que haría este paso. Ahora, si me desplazo hasta el final y hago clic en confirmar nuevo archivo, habremos creado ese archivo en .github/workflows. El archivo build and test ahora está allí y ahora deberías poder ir a acciones y ver que ese flujo de trabajo se está ejecutando. Este sería un buen punto de control si nos puedes informar si estás viendo que tu propio flujo de trabajo se está ejecutando. Debería llamarse crear build and test. Voy a entrar en build and test. Este es el mensaje de confirmación que hicimos, y si entro aquí, puedes ver que el único trabajo que tiene llamado build and test se está ejecutando y puedes hacer clic allí y ver más detalles sobre lo que está haciendo. Así que, configuró el trabajo, verificó un poco de código, generando un montón de basura. Instaló Node.js y NPM además de ejecutar un solo paso, por lo que está instalando dependencias, y eso es realmente todo lo que va a hacer. Y luego, ejecutará pruebas unitarias, pero no tenemos ninguna, por lo que ese paso debería ser bastante rápido. Entonces, voy a retroceder y simplemente repasar ese proceso que acabo de hacer una vez más. Entonces, tenemos el manual de la masterclass, y solo estoy copiando y pegando desde él. Y luego, voy a seleccionar tu repositorio bifurcado, este debería ser el nombre de tu organización, cualquiera que sea tu nombre en Github, bulnodexpress. Estoy añadiendo un archivo. El nombre de ese archivo es .github/workflows /build and test.yaml.

Y una vez que hagas eso y comiences a completarlo, haré clic en Continuar desde aquí, luego puedes hacer clic en Confirmar nuevo archivo para crearlo. Y solo con haber confirmado eso, habrás cumplido uno de los, en realidad ejecutarás ese flujo de trabajo porque una vez que confirmas algo en la rama principal, este flujo de trabajo indica que GitHub debe ejecutarlo realmente. Entonces, una vez que pongas este archivo, y veremos que tiene un trabajo que debe hacer, leerá los pasos y los ejecutará en Github Actions. Así que para este punto, si has pasado por todo eso generalmente toma un par de minutos, pero deberías tener un trabajo completo, debería haberse completado correctamente, y tendrás una marca de verificación verde. Nuevamente, para ver tus acciones en ejecución, ve a la pestaña Actions, los flujos de trabajo que has configurado para este repositorio, y podrás ver las ejecuciones individuales. A medida que ejecutemos más trabajos aquí, verás cómo esta lista se llena con más y más confirmaciones que inician más y más compilaciones.

Muy bien. ¿Cómo les va a todos? Está vivo. Excelente. Genial. ¿Está vivo para todos los demás? Denos un pulgar hacia arriba. Impresionante. ¿Aparece dos veces? Eso es interesante. Si hicieron dos confirmaciones, creo que podrían haber hecho dos confirmaciones, lo cual está bien. Cada vez que hagas una confirmación en la rama principal, verás otra ejecución de acción. No importa cuán pequeño sea el cambio. Incluso puedes hacer confirmaciones vacías, y eso hará que se ejecute el flujo de trabajo.

Esto es genial. Es genial ver a todos participando aquí. Siempre es increíble cuando hay participación. Muy bien, eso es GitHub Actions. Entonces tenemos un flujo de trabajo simple y ahora vamos a agregar algunas pruebas de seguridad a todo esto. Ahora quiero retroceder por un momento y hablar sobre estos tipos de pruebas de seguridad que vamos a hacer y las características de cada uno de ellos y los problemas que están diseñados para resolver y cuáles son los pros y los contras de cada enfoque. Y básicamente, lo que voy a concluir es que es realmente bueno tener todas estas herramientas en juego si puedes, pero algunas son mejores que otras para brindarte información realmente útil y accionable que realmente puedes usar para priorizar dónde quieres enfocar tus esfuerzos, especialmente en un entorno de equipo.

El primer tipo de prueba de seguridad que vamos a hacer es el más fácil posible y eso es el análisis de composición de software. La forma en que funciona el análisis de composición de software, también conocido en la industria como SCA, es que realmente solo mira tus dependencias. Hay muchas herramientas diferentes que hacen esto y pueden operar desde tu repositorio de artefactos como NPM. El servicio en la nube de NPM tiene una función incorporada para esto. JFrog artifactory también tiene una función incorporada. También hay herramientas que se ejecutan en tu código base y pueden revisar tu archivo de dependencias y examinarlo en profundidad para averiguar si estás utilizando dependencias que tienen vulnerabilidades conocidas, básicamente. Cuando se ejecutan estas utilidades, generalmente son muy rápidas y muy fáciles de actuar. De hecho, muchas de estas utilidades te proporcionarán soluciones. La que vamos a usar se llama Dependabot, está integrada en GitHub. Cuando encuentra vulnerabilidades en tus dependencias, generalmente abrirá una solicitud de extracción en tu código y dirá: `Oye, tengo una solución para esto. Todo lo que tienes que hacer es aceptar esta solicitud de extracción`. Y cuando abre esa solicitud de extracción en nuestro caso, dado que hemos configurado GitHub Actions para reconstruir la aplicación, en realidad va a pasar por la fase de compilación y prueba y asegurarse de que el cambio que está tratando de hacer esté bien y no rompa tu código. Eso es Dependabot, eso es SCA.

La siguiente forma de prueba se llama Prueba de Seguridad de Aplicación Estática (SAST). Y esta es una forma más sofisticada de análisis de código que realmente analiza tu código estático. Para analizar todo tu código, por lo que depende del lenguaje. Necesita comprender tu código. La que vamos a usar hoy se llama CodeQL. Es este pequeño icono aquí y CodeQL comprende Node.js, así como Java, TypeScript, C Sharp, comprende muchos lenguajes. Lo que hará es intentar compilarlo y indexarlo en una forma que se pueda buscar. Y analizará ese código en busca de patrones que parezcan vulnerabilidades. Por ejemplo, puede buscar variables ingresadas por el usuario. Y si ve una variable ingresada por el usuario y usas ese valor ingresado para crear una consulta SQL, entonces se asegurará de buscar y asegurarse de que hayas sanitizado esa variable antes de usarla en la consulta. Para que el usuario no pueda inyectar caracteres maliciosos que podrían usarse para hacer cosas malas en tu base de datos SQL. Lo bueno de herramientas como esta, sobre las utilidades de SaaS en general, es que pueden brindarte información muy específica sobre dónde está el problema en tu código. Pueden señalar el archivo exacto y las líneas de código exactas donde está el problema. Y encuentra tus errores que has escrito, no solo errores en tus dependencias. El problema es que tiene una alta tasa de falsos positivos. Es algo difícil de hacer para probar estas cosas. Y cuando encuentra hallazgos, incluso si son hallazgos precisos, lo que te están mostrando son posibles vulnerabilidades. Realmente no pueden demostrar que estas posibles vulnerabilidades realmente existen en la aplicación en tiempo de ejecución. Entonces, los pros son que puedes llegar al archivo en línea donde está el problema, y esa es mucha información realmente útil para los desarrolladores.

Contras, podrían no ser errores reales. Por lo tanto, es difícil priorizar las correcciones basándose en los resultados que se obtienen de SaaST. Finalmente, las Pruebas de Seguridad de Aplicaciones Dinámicas, o DaaST, es el tipo de herramienta que proporciona StackHawk. Hay muchos ejemplos de esto en el mundo real. awasp.zap es un tipo de utilidad de código abierto que es completamente gratuita para su uso. Hay otra llamada burp.sweep que quizás hayas oído hablar. Es una herramienta DaaST muy conocida que la mayoría de las personas en este espacio conocen. La forma en que funciona esta utilidad, o este tipo de utilidades, es que operan en un código en ejecución. Por lo tanto, debes poner en marcha tu aplicación y luego ejecutar el escáner contra esa aplicación. Enviará entradas y buscará salidas. Lo que intenta hacer es demostrar que puede explotar, por ejemplo, un ataque de inyección SQL. Entonces, intentará realizar un ataque de inyección SQL y recopilará pruebas de que ese ataque fue exitoso. Y luego, si cree que ha encontrado vulnerabilidades, te dirá qué vulnerabilidades encontró. Y te mostrará los detalles de esas entradas y salidas para que puedas recrear el problema, y con suerte solucionarlo y poder verificar que lo has solucionado. Nuevamente, encuentra tus errores. Tiende a tener una precisión muy baja, encuentra tus errores, tiende a tener muy pocos falsos positivos. Y cuando encuentra problemas, generalmente ha confirmado las vulnerabilidades. En realidad, ha intentado explotar esas vulnerabilidades y ha demostrado que podría explotar esas vulnerabilidades. Esas son las cosas que vamos a probar y comenzaremos con SCA. Y voy a hacer una pausa por un momento y ver si hay alguna pregunta.

Tenemos una pregunta. Es sobre el enlace de Discord. Así que déjame dártelo. Estoy copiando el enlace de Discord en el chat de Zoom. Únete allí, dale un pulgar arriba en la página general. Y luego, por favor únete a nuestro canal de pruebas de seguridad de aplicaciones web de octubre de 2022. Ahí lo tienes.

De acuerdo, genial. Continuando, nuestro siguiente paso es Dependabot. Este será muy fácil de configurar. Volvamos a... En realidad, déjame contarte brevemente sobre Dependabot. Dependabot es un servicio gratuito para todos los repositorios de GitHub. Viene habilitado de forma predeterminada en cualquier repositorio público. Así que si creas un repositorio público, debería estar habilitado de forma predeterminada. También es fácil de agregar a repositorios privados, y eso es lo que haremos ahora. Como lo bifurcamos, no se habilitó de forma predeterminada. Quiere que lo habilites explícitamente, así que lo haremos. Y ese es exactamente el mismo proceso que se utiliza para un repositorio privado. También es gratuito en repositorios privados. Puedes usarlo en cualquier código tuyo. Como mencionamos, encuentra bibliotecas con vulnerabilidades, y emite automáticamente solicitudes de extracción para cualquier corrección que pueda hacer. Y esas solicitudes de extracción, por supuesto, pasarán por cualquier automatización que tengas. Por lo tanto, esas solicitudes de extracción iniciarán el flujo de trabajo de GitHub Actions que ya configuramos. En la práctica, tiene algunos falsos positivos. Definitivamente debes seguir siempre sus consejos y mantenerte actualizado. Pero a veces son falsos positivos, en el sentido de que tu base de código puede que no use suficiente de la biblioteca para exponer la vulnerabilidad que se sabe que está presente en las vulnerabilidades que encuentra o en las bibliotecas que sabe que son vulnerables. De acuerdo. Sigamos adelante. Entonces, lo que vamos a hacer es ir a... Veo cómo lo describí aquí, porque hay un par de formas diferentes de acceder a esto. Vamos a la sección Configuración del repositorio. Vamos a encontrar la sección de Security y Análisis de Código. Y luego vamos a habilitar el gráfico de dependencias, las alertas de dependencias y las actualizaciones de seguridad confiables. Entonces, desde tu repositorio clonado o bifurcado, ve a la pestaña Configuración, y luego encuentra la sección de Security y Análisis de Código. Vamos a activar el gráfico de dependencias. Esta es la función que permitirá a GitHub buscar y encontrar tu archivo de dependencias. Y en este caso, es el... ¿cómo se llama? El archivo Package.json y el archivo package-lock.json, para que pueda entender qué dependencias estamos intentando incluir. Luego, vamos a activar las alertas confiables para que nos avise cuando encuentre vulnerabilidades. Y luego vamos a activar las actualizaciones de seguridad confiables, para que GitHub pueda abrir solicitudes de extracción para cualquier vulnerabilidad que encuentre. Si quieres, también puedes activar las actualizaciones de versión, para que no solo busque bibliotecas vulnerables, sino que también busque, hey, ¿hay una nueva versión de alguna de estas bibliotecas que has incluido? Personalmente, no lo activo, pero si quieres, encontrará muchas más cosas en ese caso. Por ahora, omitamos el escaneo de código, volveremos a eso en un momento. Así que si has hecho esto, y nuevamente, el camino para llegar aquí es, ve a configuración, y luego a Security y Análisis de Código, y luego activa el gráfico de dependencias, las alertas de dependencias y las actualizaciones de seguridad confiables. Y si has hecho eso, entonces deberías ver algunas actualizaciones de seguridad porque es tan rápido, ya pudo determinar que tengo un montón de bibliotecas problemáticas. Así que ve a tu pestaña de Security, donde deberías tener un distintivo que dice 18 o algo así, en mi caso son 18. Y luego vamos a ir a la sección de Dependabot aquí. Y podemos ver cuáles son esos problemas. Y realmente hay bastantes problemas críticos y de alta security.

Voy a hacer una pausa por un momento y ver dónde están todos. Hay un par de chats en Zoom. Parece que estamos bien. Genial. Parece que mucha gente se está poniendo al día aquí. Esto es genial.

De acuerdo, entonces, hay un par de cosas que debemos tener en cuenta en esta página. Primero, tenemos alertas para los problemas que encontramos. Tenemos una vulnerabilidad de polución de prototipos en Minimist. Tengo una biblioteca llamada Minimist, que es un paquete de npm. Hay una vulnerabilidad crítica en eso. Aquí, ves esta indicación de solicitud de extracción, así que ya se ha abierto una solicitud de extracción para ese problema. Y en un segundo, iré allí y te mostraré cómo se ve eso. Y no vamos a fusionar esas solicitudes de extracción ahora mismo, pero más adelante, después de la masterclass, siéntete libre de intentar fusionar algunas de esas solicitudes de extracción. Ayer mismo hice esta masterclass y descubrí que todas esas solicitudes de extracción eran bastante seguras de aplicar. Pero te mostraré cómo se ve en un momento. Así que puedes ingresar a estas y te darán aún más detalles normalmente y enlazarán a otra información sobre estos problemas, y obviamente, debes abordar cualquier problema crítico en tu propio código y también los problemas importantes. Los problemas moderados y bajos también son buenos para mantenerse al día, pero no son tan importantes.

Voy a hacer clic en uno de estos. Esto me muestra qué solicitud de extracción se abrió para intentar solucionar esta vulnerabilidad. Y puedes ver que realmente creó una solicitud de extracción, y ahora tengo un montón de solicitudes de extracción. Intentó fusionar esto en la base de código, y luego ejecutó las pruebas que eran aplicables. Puedes mostrar todas las comprobaciones. Y este es nuestro flujo de trabajo que usamos. Y este es el flujo de trabajo que configuramos en nuestro primer paso. Lo ejecutó y encontró que no hubo problemas. Nada se rompió. Todas las pruebas tuvieron éxito. Así que podrías fusionar esto. No lo haré, pero si lo haces, volverá a activar ese flujo de trabajo e intentará ejecutar todas esas pruebas. Volviendo a toda la sección de solicitudes de extracción, puedes ver que hay un montón de solicitudes de extracción. Todas tienen esta etiqueta 'dependency'. Y todas fueron abiertas por Dependabot. Y para completar lo que estamos viendo aquí, si voy a acciones, puedes ver todas estas nuevas acciones, ejecuciones de flujo de trabajo. Cada una de estas ha intentado, ya sabes, actualizar el código en función de los cambios de la solicitud de extracción. Y luego ejecutó el flujo de trabajo nuevamente. Construyó nuestra aplicación Node Express, intentó ejecutar todas las pruebas unitarias. Eso es básicamente todo. Como puedes ver, es realmente muy fácil de trabajar con esto. Ahora quiero pasar al siguiente paso, a menos que haya algún obstáculo que necesitemos abordar. Estoy seguro de que Mimi me lo hará saber si hay algo crítico que necesite retroceder y repetir. Sí, parece que no hay preguntas en este momento. Así que creo que podemos seguir adelante. Genial. Siguiente paso, CodeQL. Nuevamente, esta es la utilidad SAST. Es un motor de análisis de código. Y lo que hará es compilar nuestro código, en realidad, en nuestro caso, como es JavaScript, ni siquiera necesita compilarlo.

Y va a intentar ejecutar el código y buscar patrones vulnerables. Veremos si encuentra algo. Un par de cosas sobre CodeQL, es gratuito para su uso en repositorios públicos y nuestro repositorio es público ya que lo bifurcamos de un repositorio público. Por lo tanto, vamos a poder activarlo de forma gratuita y utilizarlo. Si deseas usarlo en repositorios privados, debes utilizar la licencia de seguridad de GitHub y eso tiene un costo adicional. Pero si tienes repositorios públicos, tus propios proyectos personales, puedes usarlo tanto como desees. Utilizará GitHub Actions. Agregará un flujo de trabajo de GitHub Actions para realizar sus propias pruebas. Por lo tanto, utilizarás minutos en GitHub Actions, pero nuevamente, incluyen muchos minutos gratuitos por mes. Por lo tanto, es bastante económico operar en repositorios públicos.

Muy bien, vamos a hacerlo. Entonces, nuevamente, esta vez vamos a ir a la sección de seguridad de nuestro repositorio. Vamos a hacer clic en un botón llamado 'configurar análisis de código'. Y luego debería haber un gran botón verde que podemos usar para configurar las alertas de CodeQL. Y creo que esta ruta ha cambiado un poco pero lo resolveremos juntos. Esto creará un nuevo flujo de trabajo en el mismo directorio que nuestro antiguo flujo de trabajo, llamado Análisis de CodeQL. Y luego se ejecutará tan pronto como confirmemos eso en el repositorio.

Desde tu repositorio bifurcado, Volnode Express, dirígete a la sección de seguridad y luego ve a la sección de análisis de código y configura la herramienta de análisis. Cuando hago eso, solía ser que el valor predeterminado era simplemente hacer el análisis de CodeQL, pero están tratando de mostrar que realmente hay un montón de herramientas de seguridad disponibles aquí de otras compañías, de la comunidad de código abierto, y demás. Incluso tenemos una aquí que puedes usar. Creo que estamos aquí abajo en algún lugar. De todos modos, estamos en algún lugar allí, pero hoy vamos a usar solo el análisis de CodeQL. Así que haz clic en configurar aquí en CodeQL. Y eso te llevará a este nuevo archivo de flujo de trabajo code QL.yaml. Así que esto es otro flujo de trabajo estándar de GitHub Actions. Y lo que va a hacer es funcionar cada vez que intentemos hacer push a la rama principal o abrir una solicitud de extracción a la rama principal. Y aquí hay otra característica genial de GitHub Actions. También se ejecutará de forma manual, así que una vez a la semana se ejecutará todo este análisis de CodeQL. Esos son los desencadenantes. Y luego el trabajo que tiene es solo un trabajo llamado analizar, y utilizará algunas características más avanzadas de GitHub Actions. Así que utilizará una estrategia de matriz. Y esto es útil si tienes varias bases de código, pero solo encontró un lenguaje en nuestra base de código, JavaScript. Así que solo se ejecutará eso. Pero si encontráramos, si encontramos, como, algo de JavaScript y algo de Java y algo de Go, crearía esta matriz y ejecutaría todos los análisis para todos ellos en paralelo en una especie de configuración de ejecución de matriz. Solo un concepto estándar de CI/CD. Pero lo hacen de una manera realmente agradable y sencilla. De todos modos, solo se ejecutará eso. Y lo hará con un solo tipo de punto final. Así que de todos modos, se ejecutará en nuestro código JavaScript. Verificará el repositorio. Inicializará CodeQL. Nuevamente, a través de esta matriz de lenguajes, solo encontrará JavaScript. Intentará construir eso. Tiene una rutina de construcción automática que intenta descubrir y comprender cómo construir nuestra aplicación. En nuestro caso, será muy fácil. Luego ejecutará el análisis. Y finalmente, nos informará nuevamente a través de la pestaña de seguridad si ha encontrado algún problema. Voy a hacer clic en confirmar. Y una vez que se haya confirmado ese archivo, nuevamente, y no te preocupes, no necesitas hacer ningún cambio. Una vez que eso esté confirmado, deberíamos estar ejecutando la acción para eso. Entonces, en la pestaña de acciones, deberías ver que tienes dos nuevos trabajos en ejecución. Uno de ellos es nuestro trabajo de construcción y prueba, y el otro es el trabajo de CodeQL con un flujo de trabajo de CodeQL. Así que podríamos hacer clic en el flujo de trabajo de CodeQL específicamente y ver cómo va eso. Así que hemos llegado a la parte donde hemos inicializado CodeQL, hemos ejecutado la construcción automática y ahora estamos ejecutando el análisis, al menos en mi caso. Y esto puede llevar unos minutos. Es un poco más complejo e intensivo en recursos que la verificación de SCA. Así que solo observa tu acción y veamos cuánto tiempo tarda en finalizar. Y al final deberíamos tener algunos resultados y podemos verificar eso. Esperemos que no tarde mucho. Debería tener algo de música agradable mientras tanto.

Una vez que veamos los resultados, deberían aparecer en esta sección de análisis de código de la pestaña de seguridad. Así que voy a encontrar mi producto e instalarlo. Todavía estoy ejecutando ese flujo de trabajo de CodeQL en mi lado. Muy bien. Y luego volveré a ver si alguien más obtuvo los mismos resultados. Entonces, nuevamente, ve a la pestaña de seguridad, sección de análisis de código, y aquí deberías ver un hallazgo, consulta base de datos construida a partir de fuentes controladas por el usuario. Y lo que nos dice es que encontró en nuestro archivo de servicio slash search.js en la línea seis, esta línea y esta sección exacta de código que no le gusta mucho. Entonces, lo que hemos hecho aquí es crear una consulta SQL que vamos a enviar a nuestro backend de base de datos, y como parte de esa consulta, estamos insertando algún texto de búsqueda que ingresó el usuario. Y ese texto de búsqueda se construye a partir de una variable proporcionada por el usuario, y el análisis de código ha determinado que todo lo que hicimos fue aceptar ese texto del usuario, ponerlo en la variable y luego usarlo en esta búsqueda SQL. No hicimos nada, no encontró ninguna otra instancia de esa variable donde estuviéramos verificando caracteres problemáticos, como el porcentaje de comillas, que es un carácter de escape que se puede usar para inyectar otro comando SQL en la consulta. Y así es posible que los usuarios lo usen para inyectar otras consultas MySQL potencialmente maliciosas. Y veremos más adelante que este es un error real que encontró CodeQL. Esto es algo a lo que realmente debes prestar atención. Pero lo otro interesante que debes notar es que te dice exactamente lo que debes hacer. Si una consulta base de datos como una consulta SQL o NoSQL se construye a partir de datos proporcionados por el usuario sin el suficiente soporte de un servicio SQL, sin una desinfección suficiente, un usuario malintencionado podría ejecutar consultas base de datos maliciosas. Y eso es totalmente cierto, y puedes hacerlo con esta aplicación.

Muy bien, me detendré por un momento para ver si hay alguna otra pregunta o si todos están al día. Parece que vamos bien. Genial. Increíble. La gente está viendo lo mismo que yo. Muy bien. Sigamos, entonces, con el siguiente paso. Y, por supuesto, avísame si hay algo que necesite volver a mostrar.

El último paso es StackHawk. Y nuevamente, StackHawk es la empresa para la que Mimi y yo trabajamos. Creemos que es una gran herramienta. Obviamente, estamos sesgados, pero realmente es una herramienta única en este espacio porque DAST es uno de los tipos estándar antiguos de pruebas de seguridad. Y a menudo se considera un estándar de oro en términos de pruebas porque opera contra tu código en ejecución. Y realmente intenta explotar vulnerabilidades y recopila evidencia de que pudo explotar esas vulnerabilidades. Entonces, cuando encuentras vulnerabilidades con una utilidad DAST, sabes que vale la pena priorizarlas porque son reales. Y si ejecutas estas aplicaciones en público, habrá personas que intenten atacar y explotar esas vulnerabilidades. Por lo tanto, es una herramienta muy útil para priorizar en qué trabajar en un entorno de equipo en términos de errores de seguridad. Pero en el pasado, ya sabes, con las utilidades antiguas, era difícil trabajar. Suelen ser estas grandes aplicaciones que consumen mucho tiempo para configurar y operar, y generalmente se ejecutan manualmente. Es la misma herramienta que los probadores de penetración utilizarán cuando realicen una prueba de penetración. Y, por lo tanto, tienden a ejecutarse con la misma frecuencia. La gente las usará una vez al mes, o tal vez una vez al trimestre. Y el problema con eso es que es muy poco frecuente, y cuando encuentran vulnerabilidades, luego es difícil encontrar dónde están esas vulnerabilidades.

El enfoque de StackHawk es crear este escáner portátil que es muy fácil de ejecutar y fácil de ejecutar en automatización. Y eso es a lo que estamos tratando de llegar, es que al igual que esas otras pruebas son pruebas que se pueden ejecutar en cada PR, queremos que DAST también sea una prueba que se pueda ejecutar en PR. Porque si puedes detectar una nueva vulnerabilidad en un PR, sabes que un PR generalmente tiende a ser solo un pequeño cambio de código. Si ejecutas un escaneo DAST y ves, hey, tengo una nueva vulnerabilidad en estas 20, 30 líneas de código que acabo de escribir, entonces estás en la mejor posición para encontrar y eliminar esa vulnerabilidad y volver a probar y ver si realmente te deshiciste de ella.

Entonces, con ese fin, StackHawk es un escáner portátil. Está basado en la herramienta de código abierto OWASP Zap, pero hemos agregado una plataforma SAS en línea para que puedas rastrear todos los resultados de tus escaneos escaneo tras escaneo. Realmente lo hace más utilizable, especialmente en un entorno de equipo. Tiene una configuración YAML sencilla en contraposición a la configuración generalmente basada en GUI de ZAP, y es muy fácil de integrar en CICD. También tenemos muchas otras integraciones y una de las principales es la integración con JIRA para que, cuando encuentres vulnerabilidades, si no puedes solucionarlas en tiempo real, al menos puedes crear tickets con ellas para que puedas priorizarlas y hacer que otras personas trabajen en ellas más tarde. También tenemos muchas capacidades de prueba de API y GraphQL que hemos agregado a esto, lo cual creemos que es bastante único. Por lo tanto, puedes hacer cosas realmente interesantes de fuzzing de API e inyectar tus propios data o inyectar datos falsos realmente realistas en tus escaneos de API. Y tenemos una cuenta de desarrollador gratuita para una aplicación. Así que vamos a sumergirnos en ello. Lo que vamos a hacer es ir a app.stackhawk.com y registrarnos para obtener una cuenta, y esta será una cuenta gratuita. Pero todo lo que tienes que hacer es ir a app.stackhawk.com, y Mimi está escribiendo esa dirección para que puedas seguir. Y puedes configurar una nueva cuenta. Puedes usar tus credenciales de GitHub o tus credenciales de Google, que usaré hoy, o puedes configurarlo con tu dirección de correo electrónico. Si lo configuras con tu dirección de correo electrónico, te pedirá que crees una nueva contraseña y luego te enviará un correo electrónico de verificación, así que debes revisar tu correo electrónico y verificar. Recomiendo Google o GitHub solo por facilidad de uso. Muy bien. Y voy a usar mi cuenta personal. Y cuando configures tu cuenta en GitHub, lo primero que verás... espera, déjame revisar el chat. Genial. De acuerdo, lo primero que verás es esto si has usado Google o GitHub. Así que simplemente dice, hey, esto es lo que sé sobre ti. Aquí está el nombre de tu organización.

La voy a llamar 'mi organización de la masterclass' para mantenerla distinta de las otras cuentas que tengo. Y luego simplemente haz clic en continuar aquí. A continuación, elige tu aventura. Vamos con la opción predeterminada, escanear mi aplicación, porque vamos a escanear la aplicación que ya hemos estado probando. Puedes, ya sabes, puedes elegir Google firing range que inyecta un montón de datos de muestra para que puedas comenzar a ver los resultados del escaneo sin tener que ejecutar un escaneo real. Pero nosotros elegiremos escanear nuestra aplicación y hacer clic en continuar. Y ahora deberías ver esto. El primer paso en este asistente de configuración te indica cómo instalar la CLI de StackHawk Si quieres, no necesitamos preocuparnos por esto hoy y tenemos documentación sobre cómo hacerlo. Así que no tienes que preocuparte por este paso, pero sí necesitas esta clave de API. Porque nuevamente, vamos a ejecutar esto en CI CD, vamos a agregar un paso a nuestro flujo de trabajo de GitHub Actions que simplemente lo ejecutará por nosotros. Pero necesitamos esta clave de API. Así que copia esa clave, guárdala localmente para que puedas volver a ella. Y lo que queremos hacer es configurar esta clave de API. Gracias, asistente de StackHawk. Por cierto, ese globo de chat realmente va a personas detrás de escena que pueden ayudarte si tienes algún problema. De acuerdo, voy a copiar esta clave de API, y luego volvamos a tu repositorio y vayamos a configuración y vamos a guardar esa clave de API como un secreto. Así que en Configuración, hasta abajo, en Secretos, deberías encontrar una sección de acciones. Y vamos a agregar un secreto de acciones. Y lo explicaré una vez más. Crearemos un nuevo secreto de repositorio. Por favor, llámalo hawk, todo en mayúsculas, hawk API key, hawk underscore API key y pega tu valor allí. Y eso es porque nuestra configuración predefinida se referirá a este secreto para inyectar, para usar esta clave de API en el futuro. Así que agregaré ese secreto. Y nuevamente, el camino para llegar allí fue desde tu cuarto repositorio, ve a configuración, secretos y acciones, y luego haz clic en nuevo secreto de repositorio. Danos un pulgar hacia arriba si estás al día. Y ahora, volveré a esta aplicación StackHawk y continuaré. Vamos a hacer clic en siguiente. Démonos un nombre, simplemente lo llamaré igual que mi repositorio, bone node express. Y lo llamaré entorno de desarrollo. Y el propósito de este nombre de entorno es que realmente puedes escanear una sola aplicación en varios entornos. Y simplemente agrupamos los resultados del escaneo por entorno. Es posible que tengas características diferentes en diferentes entornos que te darían diferentes resultados de escaneo. Y por eso lo hacemos. Esta aplicación se ejecutará en local host puerto 3000 en la canalización de compilación que vamos a configurar. Así que simplemente ingresa HTTP local host 3000. Voy a pegarlo aquí. Ese es el nombre de tu host que debes ingresar en la sección de host aquí. Un detalle importante a tener en cuenta, es HTTP no HTTPS. El escaneo fallará si usas HTTPS. Porque cuando iniciemos la aplicación, solo estará escuchando en texto sin formato. Siguiente. Y luego el tipo de aplicación. Puedes simplemente decir omitir por ahora o no sé. Las otras opciones harán más preguntas. Como si fuera una API, podemos obtener varias informaciones para conocer más sobre esa API. O si es GraphQL, podemos, ya sabes, podemos preguntarte si tienes un archivo de esquema o si puedes señalar a un punto de enlace de introspección. Estas son las dos opciones. Si es un entorno de Linux, básicamente puedes señalar a un punto de enlace de introspección, y así sucesivamente. Por ahora, simplemente lo omitiremos.

Vamos a realizar un escaneo muy básico. Haz clic en siguiente. Y luego, en el último paso, deberías tener este archivo de configuración de ejemplo stackhawk.yml. Y realmente son solo estas cuatro líneas de código las importantes para ese archivo de configuración. En él, tenemos el ID de la aplicación, que es el ID de esta aplicación en el sistema de StackHawk, el entorno de desarrollo, y luego el host que vamos a escanear. Esto le dice al escáner todo lo que necesita saber sobre el escaneo que está a punto de ejecutar.

Vamos a copiar eso. Y vamos a pegarlo en un archivo de configuración stackhawk.yml en nuestro proyecto. Y nuevamente, simplemente vamos a ir a través del navegador web en GitHub y configurar este archivo. Para volver a la sección de código, voy a agregar un archivo, crear un nuevo archivo. El archivo se llama stackhawk.yml. YML, no YAML, aunque creo que ambos funcionarán. Y luego simplemente copia el contenido de ese archivo. Y el tuyo debería verse más o menos así. Lo primero que voy a hacer es crear un nuevo nombre de archivo. Y lo llamaré ID de la aplicación, entorno y host. Y luego, cuando haga clic, haremos un commit de este archivo. Y eso iniciará nuestro flujo de trabajo, pero aún no se está escaneando. Necesitamos agregar algo a nuestro archivo de flujo de trabajo para que funcione.

Nos hemos asegurado de que la aplicación exista en el sistema, y estamos listos para escanear. Nuevamente, acabo de crear un nuevo archivo llamado StackHawk.yaml, pegué ese contenido y hice un commit de este archivo. Y ahora, para que se ejecute como una acción y para que realmente escanee la aplicación en la canalización, debemos ir a los flujos de trabajo de GitHub. Y agregar un paso a nuestro archivo de configuración de construcción y prueba.

Antes de pasar a eso, Zach, parece que todavía estamos esperando a que las personas terminen de configurar la cuenta de StackHawk. Así que les daremos unos segundos más y por favor hagan preguntas o den un pulgar hacia arriba. Oh, los pulgares hacia arriba están llegando ahora. Bien. Sólo voy a repasar eso una vez más. En caso de que alguien haya perdido un paso. Ese asistente de configuración se verá prácticamente igual a lo que estoy a punto de hacer ahora. Si hago clic en agregar una aplicación, simplemente la llamé Vuln Node Express en el entorno de desarrollo con el host HTTP localhost 3000. localhost 3000. Luego la llamé omitir por ahora, no sé. Y copié y pegué eso en un nuevo archivo de configuración stackhawk.yml en tu repositorio de código. Voy a eliminar esta nueva aplicación, aunque en realidad no sé si puedo, la dejaré. No desafío al destino. No desafíes a los dioses de la demostración, OK, así que tenemos una pregunta en el chat sobre las cuentas de StackHawk que dice que el sitio web dice que la prueba gratuita dura 14 días y tú mencionaste que es gratis para una aplicación. ¿Puedes aclarar eso un poco, Zach? Sí, absolutamente. Cuando configuras tu nueva cuenta, está configurada para un formato de 14 días. La prueba gratuita del conjunto de funciones de enterprise proporciona una gran cantidad de funcionalidades adicionales. Entonces, hay cosas como inicio de sesión SSO para que puedas conectarlo si usas Octa o Auth0 para SSO, algo así puedes usar eso. Abre el acceso a la API para que puedas obtener información sobre los escaneos y las aplicaciones en el sistema a través de nuestra API si quieres programar contra tu aplicación o tu plataforma. Creo que la cuenta de enterprise también admite webhooks para que puedas enviar datos de escaneo como webhooks a un punto de conexión de webhook. Son solo un montón de funciones advanced, pero después de tu prueba de 14 días, aún tienes acceso a una aplicación y puedes seguir trabajando con ella indefinidamente. Ejecuta tantos escaneos como quieras.

OK. Entonces, en la sección de escaneo dinámico de aplicaciones con StackHawk del del libro de trabajo, vamos a agregar estas líneas a nuestro primer archivo de flujo de trabajo de acciones existente que configuramos. Así que simplemente voy a copiar estas líneas y agregarlas al final del archivo que creamos en nuestro primer paso.

Entonces, nuevamente, eso es.GitHub Flujos de trabajo de construcción y prueba navega hasta ese archivo, haz clic en este pequeño botón de lápiz para editarlo el archivo. Y luego agrega estas nuevas líneas al final, así como así. Y esto es YAML, probablemente todos estén familiarizados con lo quisquilloso que puede ser YAML con el formato. Así que asegúrate de que estos pasos se alineen exactamente con los pasos anteriores. Así que estamos agregando estos dos nuevos pasos. El primero es demonizar el servicio de la API de Node. Entonces esta aplicación que construimos, la vamos a iniciar en la canalización y ejecutarla en segundo plano. Así que decimos npm run start para iniciar la aplicación web. Y luego este signo de ampersand para ponerlo en segundo plano para poder avanzar al siguiente paso. Así que está en funcionamiento. Y luego el siguiente paso es ejecutar el escaneo de Hawk utilizando nuestra propia acción predefinida de GitHub. Entonces ejecutas stackhawk slash hawkscan action, va a obtener esa clave de API que almacenamos en este almacén secreto. Y luego comenzará a ejecutar ese escaneo y enviará los resultados de vuelta a la plataforma. Así que podremos verlos en la interfaz de usuario. Haz commit a este cambio. Y una vez que lo hagas, deberías tener una nueva acción en ejecución. Y en realidad tendrás dos, así que asegúrate de mirar el flujo de trabajo de construcción y prueba. Y puedes ver esto mientras se ejecuta. Y se ejecutará a través del paso de instalación de dependencias, eso probablemente llevará un minuto, minuto y medio. Ejecutará las pruebas unitarias que no llevarán tiempo, demonizar el servicio no llevará tiempo, luego comenzará a ejecutar el escaneo de Hawk, y esa es la parte más interesante en la que queremos centrarnos.

Mientras eso se está ejecutando en segundo plano, disculpen, permítanme mostrarles un poco la aplicación. Esta primera sección es la página de aplicaciones, y aquí se muestra una lista de todas las aplicaciones que has configurado en StackHawk, incluyendo cualquier entorno en el que estés ejecutando. Así que tendrías una de estas tarjetas para cada entorno. Y estas tarjetas te muestran de un vistazo, hey, aquí están los últimos resultados del escaneo en un resumen muy general en el entorno de desarrollo. ¿Cuántos problemas de alta, media y baja gravedad encontramos? Y también, ¿qué problemas se han clasificado, ya sea asignados a alguien o marcados como un riesgo aceptable o marcados como falsos positivos si creemos que la prueba está en error?

Luego, en la sección de escaneos, a medida que ejecutas escaneos, verás cómo se va llenando esta lista. Verás escaneo tras escaneo todos los escaneos que están en el sistema, registrados en el sistema. Vamos a echar un vistazo a eso en un momento. Esta sección trata sobre la integración continua... Bueno, sobre todas nuestras integraciones. Así que tenemos integración continua, integraciones, básicamente, aunque funcionamos en cualquier plataforma de integración continua y entrega continua del mundo. Lo único que realmente necesitas para que funcione en la integración continua y entrega continua es un JDK, porque el escáner es una aplicación Java, o un tiempo de ejecución de Docker. Así que puedes ejecutarlo como un contenedor de Docker. También tenemos integraciones más profundas con GitHub con las que estamos trabajando, tal vez las veamos hoy, si podemos avanzar lo suficientemente rápido. Tenemos una integración, realmente en muchos niveles, con GitHub. Parte de lo que proporcionamos con eso es la capacidad de registrar Stackhawk como una prueba oficial de PR, por lo que aparecerá en la lista de pruebas. También podemos publicar comentarios de PR con los resultados del escaneo. Y finalmente, tenemos una integración con las acciones de GitHub, así que podemos... y de hecho, estamos usando eso actualmente. Así es como configuramos el paso del escáner. También nos integramos con Sneak Code, que es otra utilidad SAST realmente excelente que proporciona un análisis muy profundo de tu código. Tenemos una gran integración con eso, y espero que te mostremos un poco cómo se ve eso con nuestra integración de GitHub CodeQL. Puedes enviar los resultados del escaneo a Slack o Microsoft Teams o a Datadog si quieres rastrear tus datos de escaneo allí, y a Jira Cloud para que puedas crear tickets a partir de los problemas que encuentres.

Muy bien, espero haber pasado suficiente tiempo para que esto termine. Sí. Bien. Así que si ves que tu acción también ha terminado, enfócate en el paso de ejecución de HawkScan. Y generará mucha salida, pero la información clave que proporciona es, al principio, te dará un pequeño resumen del escaneo que va a realizar. Y esto es una especie de verificación previa que está haciendo. Solo se asegura de que tenga un archivo de configuración válido. Pasará por una serie de otros pasos de validación, como si has configurado la autenticación, para autenticarte en la aplicación que estás escaneando, lo probará y te informará si funcionó. Si has configurado algunos métodos de descubrimiento de API, como una configuración de OpenAPI o una colección de Postman que le hayas proporcionado, lo probará y verá si funcionó. Si alguno de esos pasos falla, fallará rápidamente. Una vez que todo eso esté completo, iniciará el motor de escaneo y comenzará a rastrear y descubrir la aplicación, te dará un pequeño resumen de lo que encontró, y luego comenzará a acceder a todos los puntos finales que encontró con cada sonda que tiene. Una vez que haya completado el escaneo, te dará un resumen rápido de los resultados. Así que en términos generales, encontramos dos problemas de alta gravedad, 10 de media y 13 de baja. Y luego enumerará las vulnerabilidades específicas que encontró, en este caso, inyección SQL, cross-site scripting, y algunas otras. Pero esto es solo un resumen para tu beneficio, y esto es realmente útil, especialmente cuando ejecutas escaneos locales, si lo ejecutas desde tu IDE, por ejemplo, pero los resultados reales estarán en la plataforma. Y puedes hacer clic en este enlace para seguir y encontrarlos. Pero si no puedes encontrar ese enlace, simplemente ve a la sección de escaneos y ahora deberías verlo en la lista. Haz clic allí y ve en detalle lo que tienes. Ahora voy a hacer una pausa y asegurarme de que todos los demás estén viendo cosas similares, asegurarme de que no haya bloqueos, revisar los chats. Genial. Parece que todos están siguiendo. Bien. Bien. Es un buen grupo ahí fuera. Ustedes están al día. Esta debería ser, como, una de las partes más difíciles. Si puedes superar esta sección, obtener la clave de API y los secretos y actualizar el flujo de trabajo y todo eso, esto es mucho mejor. Y esto es realmente genial.

De acuerdo, ahora deberías ver los detalles del escaneo. Esta página muestra muchas de las mismas cosas que las otras herramientas nos han mostrado hasta ahora. ¿Cuáles son los hallazgos que encontramos? ¿Cuál es la criticidad de esos hallazgos? Los que están en la parte superior, los de alta gravedad, definitivamente deberías abordarlos. Y, nuevamente, dado que esta es una utilidad DAS y básicamente hemos recopilado evidencia de los problemas que encontramos, sabes que debes priorizar estos. Así que echemos un vistazo a este ataque de Inyección SQL como ejemplo. En realidad, echemos un vistazo a la cross-site scripting porque es un poco más fácil de entender qué está sucediendo aquí. Lo primero que debes notar es que, cuando haces clic en los detalles de los hallazgos, te damos una descripción larga o concisa, pero estamos tratando de educar a los usuarios que se encuentran con esto. Debido a que no todos los desarrolladores van a entender todos estos problemas de seguridad, solo queremos tratar de explicar qué es y cómo abordar el problema. Por lo tanto, proporcionamos este pequeño resumen. También tenemos una serie de hojas de trucos a las que puedes acceder. Estas básicamente muestran ejemplos de cómo se ve este tipo de problema en diferentes lenguajes y frameworks. Y también cómo se ven las soluciones en esos lenguajes y frameworks. También te mostramos en qué rutas encontramos estos problemas. A medida que sondeamos la aplicación, esta vulnerabilidad se encontró en la ruta de búsqueda en la aplicación. En el lado derecho, tenemos los datos de la solicitud y respuesta. Esta es la solicitud que el escáner envió, incluyendo este texto malicioso que enviamos al campo de búsqueda. Y luego la respuesta que obtuvimos en este caso, si decodificas esto, aquí está la evidencia. Esto es lo que intentamos inyectar en el campo de búsqueda. Una pequeña etiqueta de script. Y la respuesta que obtuvimos fue esa etiqueta de script. Y así, en los navegadores antiguos y malos que no tienen verificaciones de seguridad propias, esto en realidad mostraría una alerta, una etiqueta de alerta de JavaScript. Básicamente, lo que estamos haciendo es decir que podemos inyectar scripts en la aplicación web, lo cual es terrible. Ese es un problema de alta gravedad que debes abordar. También hemos creado este comando curl. Entonces, si haces clic en el botón de validar, te devolverá un comando curl. Y si estás ejecutando localmente, ejecutando la misma aplicación localmente, y puedes probar esto más tarde si quieres, en realidad podrías recrear el ataque y ver los mismos datos de respuesta que encontró el escáner, y esta es una excelente manera de validar que has solucionado el problema una vez que intentas solucionarlo. La idea aquí es que estamos tratando de mostrar esta información a los desarrolladores. Si puedes hacer esto en cada PR y hacer que un desarrollador sepa cada vez que ha creado una nueva vulnerabilidad, es increíble. Por lo general, podrán solucionarlo de inmediato. Y si no pueden, pueden clasificar el problema de alguna manera. Puedes asignarlo y, si tienes la integración de Jira activada, creará un ticket de Jira donde podrías marcarlo como falso positivo o aceptado como riesgo.

Genial. Espero que todos hayan aprendido mucho de esto, y me gustaría mostrar una cosa más, ya que vamos bien de tiempo, y eso es la integración de CodeQL. También quiero abrirlo a preguntas, en este punto, si alguien tiene preguntas sobre cómo funciona cualquiera de estas cosas, podemos retroceder y hablar de todo eso.

Pero por ahora, me gustaría intentar configurar la integración de CodeQL para que podamos ver los resultados de SAST. Permítanme contarles un poco sobre esta integración antes de ir allí. Lo que hemos hecho en StackHawk, y esto es realmente bastante único en nuestra utilidad, es que hemos creado un par de integraciones de SAST. Mencioné que hay compensaciones con todos estos enfoques diferentes de las pruebas.

Con DAS, hemos recopilado los recibos de cada vulnerabilidad que encontramos, por lo que sabes que es una vulnerabilidad real en tu aplicación en tiempo de ejecución, y eso significa que realmente debes priorizar solucionar eso. Pero la evidencia que mostramos es un poco limitada. Podemos mostrarte los datos de la solicitud que enviamos y los datos de la respuesta que recibimos, y podemos ayudarte a validar eso, pero sería realmente útil si pudieras echar un vistazo al código y comprender dónde está el problema en la base de código, y realmente no podemos hacer eso desde este enfoque de afuera hacia adentro de las pruebas.

Por el contrario, SAST tiene el conjunto opuesto de compensaciones. Entonces, SAST puede analizar tu código y puede encontrar patrones vulnerables y puede señalarte las líneas y archivos exactos donde podría estar el problema, pero es menos preciso. En realidad, no puede decirte si es una vulnerabilidad real que se expresa en la aplicación en tiempo de ejecución. Por lo tanto, la naturaleza de esta integración es tratar de mostrar ambas partes de la información al mismo tiempo. Así que puedes priorizarlo en función de los resultados de DAS, pero obtener ese poco de evidencia adicional que realmente ayuda a los desarrolladores a encontrar la línea de código exacta que necesitan revisar para solucionar el problema. Así que obtenemos esa precisión de DAST más una evidencia detallada de SAST.

Entonces, veamos si podemos configurarlo. Vuelve a la aplicación de StackHawk y ve a la sección de casillas de verificación, nuestra sección de integración, y ve a la integración de GitHub y haz clic en eso. Luego, simplemente presiona el botón de habilitar GitHub. Y apunta a tu organización donde deseas instalar la aplicación de GitHub. Y luego puedes activarlo para todos los repositorios si quieres, o puedes limitarlo al repositorio en el que estamos trabajando hoy, que es lo que voy a hacer. Así que encontraré, se llama vuln NodeExpress y lo conectaré allí. Y, con eso, nos dará, dará a la aplicación de StackHawk acceso al código y los metadatos y los eventos de seguridad, y dará acceso de lectura y escritura a los estados de confirmación y las solicitudes de extracción. Entonces, si avanzas más con esto, puedes configurar la integración que permite que sea una prueba oficial en las solicitudes de extracción y también que permite publicar los resultados del escaneo en los mensajes de las solicitudes de extracción o en los comentarios de las solicitudes de extracción. No vamos a hacer eso hoy. Solo vamos a hacer la integración de CodeQL. Así que haz clic en instalar. Y usaré mi contraseña. Bien, una vez que lo hayas instalado, tarda un poco en sincronizarse, pero luego esto es lo que deberías ver. Puedes administrar la conexión, y eso te permitirá abrir el diafragma sobre qué otros repositorios quieres que se instale. Ahora que tienes esa conexión configurada, puedes agregar un repositorio conectado. Y lo que haremos es conectar el repositorio de GitHub de Vuln node express a nuestro repositorio de Vuln node express en este lado. Y, con suerte, he elegido el correcto porque he creado dos con el mismo nombre. Bien, veremos cómo va esto. Pero deberías ver algo similar, así que conecta tu repositorio a tu aplicación en el lado de StackHawk y haz clic en finalizar. Y ahora, para ver esto en acción, debemos realizar otro escaneo. Lo que puedes hacer es ir a tu última compilación y ejecución de prueba y hacer clic en volver a ejecutar todos los trabajos desde GitHub. Entonces, bajo acciones, ve a tus trabajos de compilación y prueba, haz clic en volver a ejecutar todos los trabajos, inicia ese escaneo. Así que tendremos que esperar un par de minutos más. Mientras esperamos, una persona en el chat dijo que su autenticador no está funcionando. Oh, ¿para GitHub, cuando te pide que uses el autenticador? Parece que sí, siéntete libre de proporcionar más aclaraciones en Discord si tienes un problema más específico. Sí, a lo que se refiere en ese caso es que debes tener configurada la autenticación de múltiples factores o autenticación de dos factores para GitHub. Y por lo general, te dará un par de opciones diferentes, es posible que puedas usar tu contraseña de GitHub nuevamente si sigues ese flujo una vez más. Pero el autenticador, en mi teléfono, uso el LastPass Authenticator. Uno muy popular es Google Authenticator. Pero es ese token de una sola vez y está buscando... Quiere que lo sigas y espero que lo hayas configurado en tu teléfono o algo así y seleccionas tu cuenta de GitHub y debería darte un código de seis dígitos o algo así que puedes ingresar allí. Tienen otra integración, si tienes la aplicación de GitHub en tu teléfono, entonces otra opción para la autenticación de múltiples factores es ingresar a tu aplicación de GitHub y leer el código. Te darán un pequeño código que puedes escribir desde la interfaz web también. Oh, alguien no entendió cómo reiniciar la acción de compilación y prueba.

Permítanme retroceder y mostrar eso una vez más. Entonces, desde la pestaña de acciones, ve al flujo de trabajo de construcción y prueba y selecciona tu último flujo de trabajo. Digamos que fue este. Si todos los marcadores verdes, en realidad no sé si puedes hacerlo desde aquí. Sí, simplemente haz clic en tu último flujo de trabajo y simplemente di, volver a ejecutar todos los trabajos. Genial. Bien, déjame ver. Así que mi trabajo de construcción y prueba todavía se está ejecutando. Y ahora está completo. Así que déjame ver si eso funcionó para mí. Así que vuelve a tus resultados de escaneo, disculpa. Y si funcionó, tus últimos resultados de escaneo deberían tener un nuevo icono de GitHub en la columna de SAST. Y al hacer clic, cualquier hallazgo que haya encontrado correlaciones con SAST también debería tener ese icono de GitHub. Y luego, al hacer clic en esos resultados, debería haber una nueva pestaña llamada GitHub CodeQL. Haz clic en eso y te mostrará, hey, esta vulnerabilidad que encontré en este lado, el ataque de rechazo de SQL, tiene una evidencia correlacionada de GitHub CodeQL. Y lo que encontraron fue que en, tienes un patrón de código vulnerable en tu archivo search.js. Y puedes hacer clic para verlo directamente. Entonces, ahora hemos hecho clic en el repositorio de código de GitHub, y ha señalado esta línea, y ahí es donde debemos buscar. Una vista mejor está disponible si presionas, ver detalles de CodeQL. Entonces, si presionas este botón desde el panel de evidencia, pestaña de GitHub CodeQL, ver resultados de CodeQL, obtendrás todos los datos sobre, hey, mira en el archivo search.js. Encontré esta línea, donde estás intentando armar esta consulta. Yada, yada, yada. Te brinda todos los detalles sobre, cuál es el patrón de código vulnerable. Entonces, para resumir, tienes un buen resumen del problema de inyección de SQL, la evidencia de entrada y salida que puedes usar para recrear el ataque, y la evidencia de GitHub CodeQL para mostrarte exactamente dónde en la base de código buscar ese problema y comenzar a solucionarlo. Ahí vamos. Y solo una vez más, solo para recorrer esta integración una última vez. Para configurar esta integración, cuando ingreses, primero ve a la sección de integraciones de la aplicación. Disculpa. Amplía esto para que sea un poco más claro. La sección de integraciones de la aplicación, ve a GitHub, y luego habrá un botón de habilitar aquí si aún no has configurado la integración. Sigue los pasos, en el sitio de GitHub te preguntará a qué repositorios quieres conectarlo. Simplemente selecciona el repositorio de Vuln Node Express, y luego deberás agregar aquí, el lado del repositorio de GitHub y el lado de StackHawk de la conexión. Y para ver los resultados correlacionados, deberás ejecutar otro escaneo de StackHawk. Entonces puedes volver a tus flujos de trabajo, ve a acciones, encuentra tu flujo de trabajo de construcción o prueba, haz clic en el último y selecciona volver a ejecutar trabajos. Y eso iniciará todo el flujo de trabajo nuevamente, ejecutará el escaneo de Hawk nuevamente. Y ahora, a medida que envía los resultados, buscará esos resultados correlacionados de SAST. Voy a verificar Discord yo mismo, ver qué otras preguntas tenemos. Bien, parece que todos han seguido muy bien. Buen trabajo, todos. Se puso, ya sabes, progresivamente más difícil a medida que avanzamos en la masterclass. Así que es realmente impresionante que todos nos hayan acompañado hasta el final. Y por supuesto, si no lograste seguirnos hasta el final, te animo a que, después de la masterclass, vuelvas a los detalles de la masterclass aquí y continúes desde donde lo dejaste. Hay algunas otras cosas aquí que no cubrimos, pero también tenemos algunos enlaces a otras cosas que puedes consultar sobre StackHawk, así como Actions, CodeQL y Dependabot, para que puedas leer. Pero espero que esto haya sido realmente útil para que las personas comprendan lo fácil y útil que realmente puede ser configurar este tipo de automatización de construcción y agregar una serie de pruebas de seguridad que realmente pueden ayudarte a escribir un código más limpio y más seguro de manera continua. Es realmente genial encontrar estas vulnerabilidades mientras estás codificando, en lugar de tener que esperar hasta el final del mes o el final de un trimestre o el final del año cuando realizas una prueba de penetración y obtienes estos resultados que están realmente desconectados de tu flujo de trabajo como desarrollador. Y estas herramientas realmente te ayudan a incorporarlas al flujo de trabajo, a incorporarlas a tu flujo de trabajo diario. Simplemente agrega otra de esas pruebas que te brinda comentarios de inmediato si has introducido algún problema en tu código. Entonces, los próximos pasos a partir de aquí, al menos en el lado de Stackhawk, tenemos una gran cantidad de contenido en docs.stackhawk.com. Puedes leer más sobre el escáner, configurar más a fondo la aplicación. Tenemos documentación sobre cómo integrarse con otras plataformas de CI/CD si no usas GitHub Actions, usas Jenkins o CircleCI. Tenemos un excelente contenido allí sobre cómo hacerlo. Luego, también tenemos un buen blog en www.stackhawk.com. Tenemos una gran cantidad de artículos excelentes en general sobre pruebas, sobre recorridos, consejos y trucos, simplemente más detalles sobre cómo escribir un buen código seguro de manera continua. Muchas gracias. Aprecio mucho su tiempo hoy. Realmente aprecio que todos nos hayan acompañado y espero que hayan obtenido algo valioso de esta masterclass.