Cómo automatizar las pruebas de seguridad para tu servicio GraphQL

Bienvenidos a todos. Gracias por su tiempo. Lo apreciamos mucho.

En este masterclass, vamos a automatizar las pruebas de seguridad para un servicio GraphQL. Lo que vamos a hacer es tomar un servicio GraphQL de ejemplo vulnerable, y vamos a agregar algunas pruebas de seguridad en el pipeline de CI/CD para ese repositorio. Y eso realmente nos brinda una buena cobertura en torno al código y la aplicación, lo que nos ayuda a encontrar errores más temprano, porque realmente, ese es el objetivo. Queremos encontrar esos errores lo antes posible.

Entonces vamos a, vamos a repasar la agenda, pero a grandes rasgos, vamos a bifurcar un repositorio de ejemplo, modificar ese repositorio, agregar algunas GitHub actions para hacer algunas pruebas. Vamos a conectar CodeQL de GitHub y el escaneo de Stackhawk. Así que podremos realizar algunas buenas pruebas en torno a esta aplicación y detectar algunas de esas vulnerabilidades.

Un poco sobre mí antes de comenzar. Mi nombre es Topher. Soy un Ingeniero de Software Principal aquí en Stackhawk. He estado aquí desde casi el comienzo de la compañía, fui el segundo ingeniero contratado después de un arquitecto principal. Cuando comencé, no había código fuente en absoluto. Así que he estado involucrado en la construcción de todo para Stackhawk desde cero, procesos, código, arquitectura, y todas esas cosas. Estoy en Colorado. He estado en el mundo de las startups durante mucho tiempo, desde mediados de los 90, fue mi primera. Comencé en el Área de la Bahía. Probablemente, uno que tal vez hayan escuchado es que trabajé, estuve en Netscape desde el principio, hace mucho tiempo. Estuve allí cuando estaban inventando JavaScript y SSL, o TLS como se llama ahora, y muchas otras cosas. Eso fue muy divertido. Tengo hijos, me encanta andar en bicicleta. Y mi principal hobby es tocar música. Así que trato de salir y tocar tanto como sea posible. Y Nicole es mi coanfitriona, por cierto, ella será la que ayudará con el Discord y todo.

Antes de adentrarnos en los pasos del flujo de trabajo, me gustaría dar una breve descripción de los aspectos de seguridad que estamos tratando y por qué son importantes. En este masterclass, vamos a implementar tres tipos diferentes de pruebas de seguridad automatizadas para este servicio GraphQL.

Los tres tipos principales, la forma en que los veo, la forma en que los considero, es el primero llamado análisis de composición de software. Si usas GitHub, probablemente hayas visto Dependabot darte algunas notificaciones, o al menos te han pedido que habilites Dependabot. Básicamente, lo que hace es analizar tus dependencias y verificar si hay vulnerabilidades en esas dependencias y luego te informa al respecto. Es útil porque, ya sabes, si estás usando algo, el más reciente fue el de log for shell. Si estás usando esa biblioteca o si es una dependencia secundaria o algo así, esto te lo hará saber. Por otro lado, no analiza las cosas en tu código, en tu lógica específica para tu código o en tu aplicación. Realmente solo busca vulnerabilidades conocidas en las dependencias. Pero es muy rápido y es realmente barato y fácil de implementar. Así que es una buena opción, el análisis de composición de software. Es bueno saberlo. Es bueno tenerlo. Lo habilitaremos como parte del primer paso que vamos a seguir.

Luego, el segundo es el análisis de seguridad de aplicaciones estáticas También lo llamo SAST. Así que si me escuchas decir SAST, eso es a lo que me refiero. Algunos de los principales proveedores aquí son Snyk, CodeQL, eso es lo que representa el ícono superior. Y lo que hace es analizar tu código. Analiza tu código y no es exactamente un compilador, pero busca cosas en tu código. Tiene un analizador e intenta identificar patrones conocidos en tu código fuente y te alerta sobre ellos. Es muy útil porque muestra una línea de código específica y es realmente útil. La desventaja es que no siempre tiene razón. Es solo una suposición, una suposición bien fundamentada, pero al final del día. Es solo una suposición. Pero también lo implementaremos. Así que activaremos CodeQL como parte de esta demostración y tal vez, si tenemos tiempo, también Snyk, porque acabamos de lanzarlo.

Entonces tenemos el tercero que es el análisis de seguridad de aplicaciones dinámicas o DAST. Lo que hace esto, lo que lo diferencia es que realmente crea una instancia de tu aplicación y luego ejecuta un escáner en la aplicación en ejecución. Y es muy útil porque cuando encuentra un problema, es un problema real en la aplicación en ejecución. Una de las cosas difíciles, sin embargo, es que no señala la línea de código como lo hace el SAST. Pero sabes que esta vulnerabilidad está aquí y luego puedes rastrearla e intentar entender qué está sucediendo. Las herramientas DAST que tenemos son StackHawks, ZAP y BurpSuite. Hoy vamos a implementar StackHawk, para el cual trabajo y es un gran producto. Y sí, esos son los tres tipos diferentes de productos de seguridad que vamos a implementar en esta aplicación de ejemplo hoy. Los vamos a incluir en el pipeline de compilación. Entonces, en cada confirmación que se haga en cualquier rama, de la forma en que lo configuraremos, se ejecutarán estas pruebas y sabremos si esa confirmación causó una regresión. Y según la sabiduría convencional en este punto, pero vale la pena señalar que cuanto antes encuentres un error en el ciclo de desarrollo, ya sea de seguridad u otro tipo, más rápido, más barato y más rápido y mejor será solucionarlo porque sabes que lo que acabo de hacer, lo que acabo de confirmar, cambió algo y causó que se activara esta alerta, se encontró el problema de seguridad. Entonces, esos son los tres tipos diferentes. Y esa es la razón por la que lo estamos haciendo. Stackhawk, creemos que lo hacemos muy bien. Estamos construidos alrededor de ZAP, que es un escáner de código abierto. Lo construimos y lo empaquetamos específicamente para CI CD. Así que lo hacemos muy fácil de usar en GitHub Actions, Jenkins, compilaciones de código, todo tipo de sistemas de compilación diferentes. Lo hacemos fácil de ejecutar en CI CD y fácil de entender qué está sucediendo. Así que tomamos los resultados a un nivel alto. Lo que sucede es que nuestro escáner se ejecuta y envía los resultados a nuestra plataforma donde se agregan y hay información histórica y puedes retroceder en el tiempo y ver si las cosas cambiaron. Puedes generar informes, todo tipo de funcionalidades y características en torno a las pruebas DAST que se ejecutan. Básicamente, queremos que sea rápido y fácil de usar y entender porque hay algunas herramientas de seguridad por ahí que te dicen: `hey, hay un problema` y luego realmente no sabes. Se necesita un poco de trabajo de detective para entender qué está sucediendo.

Así que intentamos hacer eso más fácil. De acuerdo. Estos son los pasos de alto nivel para el flujo de trabajo. Es hora de hacer algunas cosas. Hacer que sucedan algunas cosas. Muy bien.

Paso uno, vamos a utilizar GitHub Actions para construir automáticamente una aplicación GraphQL. Así que el paso uno, hablé un poco sobre eso. Vamos a tomar una aplicación GraphQL vulnerable. La forma en que lo haremos es bifurcarlo, lo bifurcaré en mi propia cuenta personal de GitHub para poder modificarlo y luego agregarlo a GitHub Actions para un pipeline de CI/CD.

Luego, el paso dos, agregaremos el escáner SCA, Dependabot, para que podamos recibir alertas cuando, si hay algún problema con las dependencias. Y veremos cómo configurarlo. Hay muchas opciones diferentes al respecto. No vamos a revisarlas todas, pero algunas útiles, algunas útiles, las que uso, las revisaré.

Y luego, el tercer paso, agregaremos GitHub CodeQL, que es un producto SAST. Analizará la base de código de las aplicaciones. Y si encuentra algo, nos lo hará saber en los commits.

Y luego, el paso cuatro, agregaremos Stackhawk para escanear una instancia de la aplicación en ejecución. Esto durante el proceso de compilación CI/CD. Agregaremos Stackhawk para que pueda ejecutar el escáner, encontrar cualquier vulnerabilidad, y los informará de vuelta a la plataforma de Stackhawk. Los otros dos, en realidad, los resultados aparecen en GitHub. Así que podemos ver las cosas allí, pero con el paso cuatro, va, los resultados se informan de vuelta a Stackhawk. Así que revisaremos Stackhawk y veremos qué encontró el escáner y qué significa eso y cómo podemos hacer algo al respecto.

Si no has trabajado con GitHub Actions antes, son la oferta de CI/CD de GitHub. Tienen un gran mercado de diferentes cosas que puedes hacer. Básicamente, se controla mediante la verificación de un archivo YAML o dos en tu repositorio en un lugar específico. Y una vez que GitHub lo vea, realizará acciones.

Lo primero que haremos es bifurcar esta API GraphQL de Vaughn, que es, por lo que CACAH es el repositorio público de StackHawk. Tenemos esta aplicación vulnerable aquí. Es una aplicación Ruby. En realidad, es de un tercero. Si vamos, vamos a ver aquí. Así que es este sistema de tallado. Esta es una API GraphQL de CACAH Vaughn, que se basa en este sistema de tallado. Oh, en realidad, solo para darles un ejemplo, aquí está ejecutándose localmente. No tienes que hacer esto como parte del taller. Solo quería mostrarles a todos cómo se ve esta aplicación vulnerable. Es tu interfaz estándar de introspección de GraphQL. Solo quería mostrarte cómo se ve. Así que vamos a bifurcar esto. De acuerdo, así que la API GraphQL de Vaughn. Sí, así que ve y crea la bifurcación.

Y ahora tengo una bifurcación aquí. Y lo que vamos a hacer es básicamente agregar la CI a este repositorio como en GitHub Actions. Como dije antes, lo que haces es poner un archivo en este repositorio que GitHub pueda reconocer. Y en este caso, es este YAML de compilación y prueba. Entonces, lo que quieres hacer es en tu bifurcación, quieres agregar un archivo, crear un archivo nuevo, y el nombre del archivo es GitHub workflows build and test.yaml. Y luego en nuestra guía de flujo de trabajo o en los pasos está este ejemplo, no ejemplo, pero aquí está el contenido del archivo. Así que este es un archivo YAML. Básicamente dice, estamos creando una nueva Acción de GitHub aquí, la ejecutaremos en Ubuntu.

Solo hay dos pasos para comenzar aquí. Vamos a clonar el repositorio, y luego vamos a construir la aplicación. Y la aplicación es muy fácil de construir. Solo utiliza Docker Compose. Así que adelante y haz commit de eso.

Entonces vamos a hacer commit directamente en la rama principal, lo cual está bien. Ahora, con ese archivo confirmado, puedes ir a la pestaña de GitHub Actions. Y verás, basado en ese commit, si vas a ver ese commit, ese es uno que acabo de hacer. Ahora tenemos una acción llamada Construcción y Prueba aquí. Y si no has trabajado con esto antes, puedes ver la salida de lo que está sucediendo. Así que si recuerdas, teníamos dos pasos. Teníamos clonar el repositorio y construir la aplicación. Y esos están aquí. Clonar el repositorio hace exactamente lo que esperas, simplemente hace una buena clonación. Y luego construir la aplicación. Está ejecutando Docker Compose aquí.

Comencemos a hablar sobre cómo agregar Dependabot. Entonces, escaneo de dependencias con Dependabot en la Guía de Flujo de Trabajo, ese es el paso dos. Así que, esperaremos a que esta acción termine, pero en realidad no tenemos que hacerlo, pero. Entonces, si vas a GitHub, en tu clon del Vulnable Graph API, si vas a la pestaña Configuración, Seguridad y Análisis de Código. Así que siguen cambiando esto, pero básicamente lo que quieres hacer es, aquí quieres habilitar tu gráfico de dependencias. Y lo que eso hace es permitirte activar algunas funciones de Dependabot. Y para este taller, lo que queremos son las alertas. Así que puedes leer lo que hace aquí, pero básicamente cuando detecta que alguna de tus dependencias tiene una vulnerabilidad, nos alertará. Y luego queremos actualizaciones de seguridad. Esta es bastante genial. Permite que Dependabot abra solicitudes de extracción automáticamente para resolver las alertas. Así que veremos eso. Lo activaremos. Y luego, cuando encuentre una alerta, si cree que puede resolverla, abrirá una solicitud de extracción para nosotros, lo cual será bastante agradable. Entonces, ya sabes, esta es solo una aplicación de ejemplo vulnerable, pero imagina en tu aplicación real con la que estás trabajando, si cuando hay un problema Dependabot encuentra algo, si automáticamente abre la solicitud de extracción para ti, eso sería mucho más fácil para ti y tu equipo lidiar con que tener que investigarlo y resolverlo.

De acuerdo. Con eso habilitado, ahora vamos aquí. Ahora vamos a esto, desde la configuración a la pestaña de seguridad, vamos a Dependabot. Y hey, Dependabot encontró cosas. Así que tenemos, parece que hay ocho abiertas que encontró, Axios, problema de ineficiencia aquí. Así que puedes entrar en cada una de estas y obtener más detalles. Así que en esta, está diciendo, hey, ve de la versión, sabes, 0.18.1 a 0.21.2. Y solucionará algunas vulnerabilidades para ti. Hacen algunas cosas interesantes al decirte, ya sabes, hey, ¿es esto grave? alguna información sobre la vulnerabilidad que encontró. Una de las cosas que el mundo de la seguridad tiene, si no estás muy familiarizado con ello, son estos IDs, el CWE y CVE y el GHSA. Y estos son solo información sobre la vulnerabilidad para que puedas aprender más al respecto. Así que este activó estas alertas, puedes ir y esto es común, básicamente una base de datos, si no has entrado en el tema de CWE antes. Eso te da información al respecto. Así que en este caso, tenemos una fuga de seguridad de regex aquí, que actualizar la biblioteca solucionará. Y como estábamos hablando antes, Dependabot abrió una solicitud de extracción para actualizar esa biblioteca por nosotros. Así que si entramos aquí, vamos, oh, genial. Esta es una solicitud de extracción con un formato agradable. Ahora, esta es una aplicación de ejemplo, no voy a fusionar esta solicitud de extracción, pero si lo piensas como si fuera tu aplicación o, ya sabes, mi aplicación, la aplicación de tu equipo, básicamente, probablemente tendrías un montón de pruebas en torno a esto. Así que cuando hizo esta solicitud de extracción, al menos de la manera en que tenemos las cosas configuradas para nuestras compilaciones, se ejecutarían una serie de pruebas de integración, una serie de pruebas unitarias y cosas así.

Así que estaríamos muy cómodos al pasar de esta versión a la nueva versión, estaría bien. En este caso, simplemente voy a dejar esto aquí y volver a security aquí. Ahora, no volvió a security, Dependabot. No abrió solicitudes de extracción para todas estas porque no fue una actualización limpia. Así que puedes obtener información aquí. Entonces dijo que se puede instalar la última versión, esto es uno, cinco, 10. Así que hay estas otras dependencias que no se actualizaron, básicamente, es algo así como un fallo rápido donde, oh, si no puedo hacer una actualización limpia en una sola biblioteca, entonces solo te informaré sobre la vulnerabilidad, te daré algunos detalles sobre lo que podrías hacer aquí. Y nuevamente, aquí hay más detalles sobre los errores. Entonces esto es lo que se identificó en la biblioteca. Estos IDs CWE son bastante comunes en el mundo de la security. Así que volvamos a security, una lista de cosas confiables aquí. Entonces puedes revisar cada una de ellas y tener una idea. Ahora, te diré que la primera vez que ejecutes esto, si no lo has ejecutado en tu repositorio o proyecto, encontrará un montón de estas cosas. Así que sí, dedica un tiempo a revisar y aprender un poco sobre lo que son, cuánto impacto podrían tener. Como dijimos antes, la cosa con las herramientas de tipo SCA como este escáner de dependencias es que puede o no ser un problema, solo te informa que, hey, la dependencia tiene una vulnerabilidad de security conocida. Entonces, en realidad no te dice si se presenta en tu código. Así que, si esto tuviera algo que ver con expresiones regulares y no usas expresiones regulares en absoluto, podría no ser un problema para ti, pero esto requiere un poco de investigación para descubrirlo. Así que vamos a ver ese archivo.

En lugar de eso, como parte del paso, agregamos este directorio de flujos de trabajo de GitHub usando este comando para agregar un archivo. Sí, Nicole acaba de publicar el manual. Si vas allí y vas al paso uno, el segundo paso del paso uno, está el archivo YAML de compilación y prueba. Y así en dot GitHub slash workflows slash build and test dot YAML, tenemos esto. Y vimos esos pasos en la acción. Así que tenemos clonar el repositorio y compilar la aplicación. Si vamos a ver las acciones, entramos aquí, tenemos clonar el repositorio y compilar la aplicación. Y una vez que tengas ese archivo YAML allí, simplemente ve a configuración, seguridad del código y análisis, y puedes habilitar el gráfico de dependencias y luego activar las dos primeras opciones o habilitar las dos primeras opciones para Dependabot. Y luego puedes ver esas ejecuciones como acciones de GitHub. Y luego puedes ver esas ejecuciones aquí porque se hizo una solicitud de extracción. Así que eso fue en el manual del masterclass. Eso fue el paso dos, análisis de dependencias con Dependabot. Y podemos ir a seguridad Dependabot y aquí está lo que encontró Dependabot. Así que creo que vamos a pasar al paso tres aquí. Vamos a habilitar el análisis de código estático con Code QL. Y esto también se hace en GitHub. Así que vamos a seguridad análisis de código. Entonces en el repositorio, vas a la pestaña de seguridad, vas a análisis de código, vas a configurar la herramienta de análisis. Y mira, lo primero que aparece es el análisis de Code QL. Así que vamos a configurar esto. Y esto es otro GitHub action. Entonces, básicamente, cuando vamos a configurar el Code QL, lo que va a hacer es agregar otro archivo YAML de GitHub Actions en ese directorio dot github slash workflows en la raíz del repositorio. Y va a tener un montón de configuraciones aquí. En realidad no vamos a cambiar mucho. Vamos a confirmar esto tal como está, ver cómo funciona por defecto porque en realidad es bastante bueno. Así que, solo para repasar eso de nuevo, vas a seguridad análisis de código, configurar la herramienta de análisis. Oh, para mí aparece de inmediato, si no aparece, simplemente busca Code QL. Y luego podrás encontrar ese flujo de trabajo. Quieres el análisis de Code QL de GitHub y simplemente haz clic en el botón de configurar. Y todo lo que hace es agregar este archivo a tu repositorio. Así que aquí está el archivo. Puedes revisarlo si quieres. Voy a confirmarlo aquí. Así que a la derecha, haces clic en comenzar confirmación, confirmar directamente en main, confirmar nuevo archivo. Ahora en nuestro directorio dot github slash workflows, tenemos dos archivos. Tenemos el que agregamos para Dependabot, que en realidad fue solo, no para Dependabot, lo siento. El que agregamos solo para construir la aplicación. Y luego este de Code QL que se agregó cuando agregamos el flujo de trabajo de Code QL. Así que si vamos a acciones ahora, tenemos esos dos que aparecen y puedes, por defecto, ves todos los flujos de trabajo. Tenemos esos dos definidos usando esos dos archivos YAML en el directorio github, github dot github workflow, y luego la confirmación que acabo de hacer para agregar ese Code QL YAML activó dos de estos. Así que tenemos el de Code QL, que es el nuevo. Y si entras aquí, puedes ver que está analizando JavaScript. Genial. Está haciendo todo tipo de cosas. Y luego tenemos, y luego este fue el de construcción y prueba que agregamos. Ya a estas alturas, esto ya nos resulta familiar porque ya lo hemos visto, pero básicamente está construyendo eso. Vale. Así que Code QL completó.

Ahora, si vas al repositorio, si vas a la pestaña de seguridad antes, cuando hicimos clic en análisis de código, obtuvimos esa indicación para buscar flujos de trabajo, pero esta vez, como tenemos uno instalado, realmente lo hizo. Ahora, lo que ha hecho es analizar y escanear el código fuente del repositorio y está buscando patrones de vulnerabilidad de seguridad conocidos en el código en sí. Y encontró cuatro de ellos aquí. Y como mencionamos antes, lo genial de los productos SAS es que resalta la línea de código para ti en el archivo. La forma en que se escribió esta aplicación, nuevamente, es un ejemplo de una aplicación vulnerable. Alguien colocó un secreto en el código. Y eso, estoy de acuerdo, es algo crítico. Ups, lo siento. Aquí está en la línea 42 de app.ts. El secreto está aquí. Te brinda más información al respecto, incluyendo, hey, no hagas eso. Usa variables de entorno o alguna forma de resolución en tiempo de ejecución. Pero es bueno porque te muestra la fuente. Puedes ver la fuente directamente, si no lo crees. Tal vez sea un secreto. Oh, no. No es la línea de código. Te muestra la línea de código, lo siento. Y luego te da algunos ejemplos de código aquí. Nuevamente, aquí están estos IDs de CWE. Se vincularán a MITRE.org para que puedas obtener más información al respecto. Así que ese es el primer análisis de código, la alerta de Code QL que encontré.

Si bajamos aquí, podemos ver algunos más de estos. Entonces, este utiliza el ID de usuario, que es solo un número aleatorio muy limitado aquí. Probablemente queramos fortalecer eso, mejorarlo un poco. Y nuevamente, es el mismo tipo de cosa. Podemos entrar aquí y decir, hey, usa algunos ejemplos de cómo escribir un código mejor para obtener ese ID aleatorio. Y luego el tercero aquí, sí. Cuando registras información del usuario en la consola, puede haber información sensible del usuario como IDs de usuario, tarjetas de crédito, quién sabe. Así que definitivamente debemos echarle un vistazo. Por lo tanto, debes enmascarar tus registros o no registrar eso, o hay varias formas diferentes de resolverlo. Pero lo que esto está haciendo es decirte la línea de código. Y también, ya sabes, si cree que es crítico o alto. Y luego este aquí, cookies transmitidas en texto claro sin SSL. Así que eso es CodeQL para esta aplicación. Es bastante bueno. Hasta este punto, lo que tenemos, tenemos nuestro escáner de seguridad de dependencias en marcha que nos avisa cuando encuentra problemas en nuestras dependencias, o vulnerabilidades conocidas en nuestras dependencias que pueden o no afectar nuestra aplicación. El escaneo de código es un poco más directo. Ups, aquí vamos. Esto está diciendo, hey, en esta línea de código, esto parece ser un problema. Así que eso es muy útil. Sin duda, vale la pena revisarlo, pero, ya sabes, de nuevo, si eso está en una prueba o si está en, ya sabes, alguna parte del código que no se invoca realmente, tal vez no sea un problema real en tu aplicación en ejecución. Pero es muy bueno tenerlo. Pero, por lo tanto, el tercero que vamos a hacer es StackHawk. Así que vamos a ejecutar nuestro escáner, que va a construir una instancia de la aplicación en GitHub actions, y luego ejecutar el escaneo directamente contra ella. Y luego, si encuentra problemas, cuando encuentra problemas, sabes que es un problema en tu aplicación en ejecución. Así que vamos a seguir adelante y hacer eso aquí. Así que este es el paso cuatro que estamos haciendo aquí. Escaneo dinámico de aplicaciones con StackHawk. Para que esto funcione, vamos a registrarnos en una nueva cuenta de StackHawk. Así que me estoy registrando en una cuenta aquí. Cuando hago esto, me enviará un correo electrónico de confirmación. Si aún no tienes una cuenta de StackHawk, puedes usar tu inicio de sesión de GitHub. Puedes usar tu inicio de sesión de Google, o puedes crear una cuenta de correo electrónico. Creé una basada en correo electrónico aquí solo porque tengo tantas. Pasé por eso, la creé, y me enviaron un correo electrónico de confirmación. Hice clic en eso y aterricé aquí. Así que creando una nueva cuenta en StackHawk, así que voy a decir, sí, está bien para la organización. Estoy usando esa basada en correo electrónico aquí. Así que tenemos una opción, puedes cargar algunos datos de muestra o simplemente comenzar el escaneo. Vamos a comenzar el escaneo aquí. De acuerdo. Entonces, lo que tenemos que hacer aquí, vamos a copiar y pegar un poco de información de StackHawk en GitHub aquí. Cuando llegues a este punto, tendrás el escáner configurado. Este es el primer paso del modal de incorporación aquí. Lo que queremos hacer es, no vamos a usar la CLI. Por lo tanto, puedes ejecutar StackHawk como una herramienta para desarrolladores localmente, tenemos una, es solo otra utilidad de línea de comandos llamada Hawk. Hay diferentes formas de instalarlo en OSX. Puedes usar Brew, pero también hay otras formas de hacerlo. No vamos a hacer eso como parte de esto porque lo estamos ejecutando en GitHub actions. Así que queremos ejecutarlo en Docker. Por lo tanto, vamos a, en la configuración del escáner de StackHawk, el tipo de escáner, queremos la imagen de Docker de StackHawk. Y luego esta es la parte que vamos a copiar y pegar de StackHawk en GitHub.

Lo que haremos aquí es sacar nuestra clave de API de StackHawk y puedes seleccionarla así o simplemente hacer clic en ese botón. Así que vamos a copiar la clave de API, la clave de API de StackHawk. Vamos a volver a GitHub aquí y la vamos a agregar como un secreto del repositorio. Vamos a la configuración, esto está en tu clon de Volny, Volny App Vulnerable Graph QL API. Vamos a la configuración, secretos, acciones. En la configuración, hay una pestaña de secretos y debajo de ella, acciones. Y en acciones, queremos agregar un nuevo secreto del repositorio. Entonces, lo que haremos es sacar la clave de API de StackHawk. La vamos a poner en GitHub como un secreto de acciones para que cuando se ejecute la acción, pueda buscarla fácilmente. En este caso, la llamaremos Hawk API key, todo en mayúsculas. Y luego simplemente cortamos, pegamos la clave de API de StackHawk aquí. Para resumir, en el primer paso de la configuración de StackHawk, hacemos clic en la imagen de Docker de StackHawk. Tienes dos opciones, CLI o imagen de Docker. Queremos la imagen de Docker y queremos esta clave de API. Cópiala. Y volvemos a GitHub para la configuración de nuestro repositorio, secretos, acciones, nuevo secreto del repositorio, nombre, Hawk API key. El secreto es la clave de StackHawk. Haz clic en agregar secreto. Y ahora lo tenemos. Ahora esta variable de entorno estará disponible para todas las GitHub actions, que tendrán la clave de API.

Muy bien. Así que eso es genial. Ahora lo tenemos guardado en GitHub. Configuraremos el resto en un momento, pero primero tenemos que volver a StackHawk aquí.

Configuración del escáner, vamos a hacer clic en siguiente. Detalles de la aplicación. La forma en que StackHawk organiza los escaneos, ten en cuenta que lo que sucede es que tienes tu aplicación GraphQL que se ejecutará. StackHawk tiene un escáner que va a atacar esa aplicación. Y luego va a informar los resultados, lo que encuentre, de vuelta a StackHawk. Y la forma en que informa esas cosas es agrupándolas en aplicaciones y entornos. Así que aquí es donde configuraremos nuestra primera aplicación. Dependiendo de tu equipo y organización, no hay una única forma de hacer esto. Muchas personas lo hacen por servicio, así que lo llamaremos UL, lo llamaremos por el servicio. Además de la aplicación, agrupamos las cosas por entorno, así que lo llamaremos desarrollo. Y luego queremos poner nuestro host. Para el host, no. Lo que va a suceder es que GitHub Actions ejecutará la aplicación Valny en el pipeline de CI/CD. Se ejecutará en Docker. En Docker, se ejecutará en el puerto 3000, efectivamente lo que es el localhost para ese pipeline de CI/CD. Así que, según lo que el escáner de StackHawk sabe, se está ejecutando en localhost puerto 3000 sin SSL. Sin SSL. Así que adelante y pon http://localhost3000.

El siguiente paso aquí es decirle al escáner de StackHawk qué tipo de aplicación va a ser testing. Hay muchas opciones aquí, admitimos muchas cosas diferentes. Lo que queremos es API. Así que API de GraphQL. Y lo que esto hará es, hablé un poco antes sobre cómo, lo que hace StackHawk es tomar el escáner ZAP y configurarlo específicamente para un caso de uso dado. Esto es parte de eso. Entonces lo que hará es decirle al escáner que cargue las pruebas de vulnerabilidad de GraphQL. Configurará la introspección. Configurará muchas cosas por ti. Así que debes elegir en el tipo de aplicación, tipo de aplicación API y luego tipo de API GraphQL. Y cuando elijas GraphQL, quiere saber el punto de introspección. Y simplemente lo agrega a esa URL, esa URL de host que le dimos anteriormente. Esto parece correcto. Así que vamos a tener HTTP: // localhost: 3000 / GraphQL. Ahí es donde el escáner va a ir a descubrir qué tiene esta aplicación en particular en términos de tipos de datos y mutaciones y todas esas cosas.

Bien, este es el último paso aquí. Lo que queremos hacer es copiar esto nuevamente, vamos a copiar este YAML de StackHawk. Esto es muy similar a cómo funcionan las GitHub actions. donde registras un archivo YAML en un lugar específico de tu repositorio. Y luego las acciones o StackHawk saben dónde encontrarlo. Si lo ven allí, entonces harán cosas. Entonces esto es nuestro archivo de configuración de StackHawk. Básicamente se llama stackhawk.yaml. Si lo revisas, tenemos el ID de la aplicación que acabamos de crear, el M, está el host, localhost 3000. Así que esta es la parte personalizada para GraphQL. Así que queremos GraphQL habilitado. Ahí está el punto de introspección. Vamos a hacer todas las operaciones. Estamos haciendo publicaciones aquí, vectores de entrada automáticos, y todas esas cosas.

Entonces vamos a continuar. Lo que queremos hacer es copiar esto, volver a GitHub, volver a nuestra aplicación Volney aquí, ir a la pestaña de código. Y como hicimos en ese primer paso de Dependabot, vamos a agregar un archivo. Así que queremos crear un nuevo archivo. Lo voy a llamar simplemente Stackhawk, stackhawk.yml. Y luego el contenido se pega directamente desde el asistente. El modal de Stackhawk, o guía de configuración, solían llamarse asistentes, pero creo que ya nadie los llama así. Pero de todos modos, queremos cortar y pegar el stackhawk.yml del flujo de configuración de Stackhawk aquí como un nuevo archivo, y luego simplemente hacemos el commit de esto.

Si vamos a acciones ahora, ahora estamos configurados aquí, así que ahora tenemos que agregar, ahora tenemos que vincular el escáner Stackhawk al paso de construcción. Acabo de crear ese stackhawk.yml así que eso activó nuestros dos pasos existentes aquí, o dos acciones, así que tenemos construir y probar, que simplemente construye la aplicación, y luego el de CodeQL. Entonces lo último que tenemos que hacer aquí es, tengo esos dos pasos opcionales en la guía, si no usaste el flujo de configuración, simplemente reitera esa información. Entonces lo que quieres hacer es agregar un escaneo de Stackhawk a tu flujo de trabajo de construcción y prueba. Ese es el paso en el que estoy ahora. Así que agrega un escaneo de Stackhawk a tu flujo de trabajo de construcción y prueba. Entonces lo que vamos a hacer aquí, es volver al código. Vamos a ir a .github/flujo de trabajo, y vamos a modificar ese primer archivo build and test.yaml que creamos para el paso de Dependabot. Tenía esos dos pasos, teníamos clonar el repositorio y construir la aplicación. Y lo que quieres hacer aquí es simplemente, vamos a agregar algunos pasos más. Así que queremos obtener el archivo aquí y simplemente hacer clic en editar este archivo. Y luego vamos a agregar dos pasos más. Y están en la guía de flujo de trabajo. Todo el archivo está en la guía de flujo de trabajo. Puedes tomar los dos últimos pasos aquí. Vamos a tener ejecutar la aplicación, que simplemente hace un docker-compose up. Y luego tenemos un nuevo paso llamado hawkscan, y va a utilizar básicamente una acción predefinida llamada acción hawkscan. Y va a utilizar esa clave de API secreta que pusimos anteriormente. La forma de referenciarlas es diciendo secrets.punto y luego el nombre de la clave. Nosotros la llamamos hawk API key. Así que vamos a especificarla aquí. Lo que va a hacer es ejecutar el escáner. Va a obtener esa clave de API del repositorio de secretos. Esa clave de API, la utilizará para luego subir los resultados. En realidad, los envía en tiempo real a la plataforma de Stackhawk. Y sí, luego podemos ver eso. Así que lo vamos a poner aquí. Empecemos aquí para poder cerrar esto. Estamos agregando estos dos pasos. Así que cuando hagamos el commit ahora, así que vamos a hacer el commit de eso. Vemos que tenemos ejecutar la aplicación en Hawk Scan con Docker Compose up, y luego la Acción de Stackhawk con la clave de API. Así que con este nuevo commit, tenemos nuestros nuevos pasos aquí en la Acción de construir y probar. Y puedes ver que, no quiero ver eso, aparecieron aquí. Así que ahora tenemos, después de construir la aplicación, tenemos ejecutar la aplicación, que es ese Docker Compose de Dash D. Y luego después de eso, ejecutará el escáner. Así que si volvemos aquí, si volvemos a Stackhawk ahora, básicamente podemos, hemos terminado. Así que ahora solo estamos esperando a que los resultados del escaneo aparezcan aquí. Como parte del proceso de construcción, eso es lo que sucederá. Entonces la pregunta es, ¿cómo funciona CodeQL? ¿Utiliza palabras clave? Por ejemplo, console.log user, ¿busca la palabra clave user, o utiliza alguna otra técnica? ¿Tienes algún conocimiento al respecto? Sí. Tiene un analizador y busca patterns. Así que no es exactamente un compilador. No compila el código y luego analiza los flujos de ejecución, aunque algunos pueden hacer eso.

No creo que CodeQL haga eso. Creo que es esencialmente una máquina de expresiones regulares muy, muy sofisticada. Por lo tanto, busca esto aquí, la aleatoriedad insegura. Tiene un montón de patterns que busca para diferentes tipos de código fuente. Por ejemplo, para JavaScript, y no conozco la implementación exacta, pero supongo que busca int aleatorio, y dice: oh, está poniendo algún tipo de rango estrecho para un int aleatorio. Y luego el ID de usuario. Sí, no sé. Debe mirar eso y decir: oh, algo ID. Eso es importante en el contexto de security. Entonces, esa es la desventaja de SAST es que no, puede o no ser algo. Solo está mirando los patterns. Solo puede llegar hasta cierto punto para determinar si es una vulnerabilidad real o no.

Sí, aquí está su cosa. Así que obtiene una fuente aleatoria, eso probablemente sea como el desencadenante, como, oh, mira esto. Están usando obtener valores aleatorios. Ahora estamos en marcha. Así que el escáner se está ejecutando ahora mismo en GitHub. Si volvemos a Stackhawk aquí, podemos hacer clic en la izquierda aquí. Podemos ver nuestros escaneos. Aquí está el escaneo que iniciamos. Así que un volumen GraphQL. Comenzó, como dije antes, está transmitiendo los resultados de vuelta. Así que el escáner se está ejecutando ahora mismo contra esa instancia de la aplicación GraphQL. Puedes ver cómo avanza aquí y ver en qué paso está, qué está haciendo y cuánto tiempo tarda. Así que va a pasar por todas estas cosas diferentes. Y todas estas son las que están ajustadas para, recuerda que elegimos, es una API y específicamente es un tipo GraphQL. Así que va a, está ajustado a ese tipo de aplicación. Todas estas cosas son cosas que quiere buscar en GraphQL. Así que terminó, escaneo completado, y encontró algunas cosas. Esto es muy similar a la lista de vulnerabilidades de CodeQL en GitHub para el escaneo de CodeQL. Pero esto son cosas que se encontraron en la aplicación en ejecución. Estas son cosas que definitivamente debes revisar. Estos son los hallazgos, justo antes de profundizar en los hallazgos, estos son los caminos que se examinaron. Ahora, para GraphQL, como la URL siempre es GraphQL y solo agrega parámetros, esto no es muy, no habrá muchas cosas diferentes para un sitio tradicional. Tendrá un montón de rutas aquí. Pero sí tiene operaciones, encontró 11 de ellas. No estoy seguro de qué está pasando allí. De acuerdo, vamos, ahí vamos. Estas son las operaciones que encontró en nuestra aplicación GraphQL. Así que encontró un montón de mutaciones, incluyendo una llamada super-secret-private-mutation. ¿Qué? Eso no suena bien. Y luego las consultas. Así que tenemos búsqueda, publicación, usuario, todas esas cosas. Como estaba diciendo, los caminos no son muy interesantes para GraphQL, pero las operaciones sí lo son. Aquí las detallamos para ti. Estas son las cosas que encontró, en términos de operaciones. Y luego estas son los hallazgos de seguridad que detectó. Podemos ver cada uno de ellos. Debido a que es un escáner DAST, está probando la aplicación, básicamente, a través de ese host y puerto, no conocemos el código fuente. Entonces CodeQL, los productos SAS te dirán en qué línea de código encontraron ese patrón, dónde estaba ese ID de usuario. Pero, entonces, STATCOT no puede hacer eso. Pero lo que sí hace es capturar la solicitud y la respuesta, y luego señala la evidencia que desencadenó esta alerta, este hallazgo. Así que aquí tenemos esta inyección remota de comandos en el sistema operativo. Nuevamente, tenemos el ID CWE, que es, ya sabes, lo mismo, es la misma base de datos, lo mismo en statmitre.org. Tenemos detalles aquí. Tenemos, fue una mutación, super secreta mutación privada. Oye, la evidencia está aquí mismo. Así que aquí está la solicitud y la respuesta. Así que aquí está, esto es lo bueno. Así que ahí, esta es una solicitud que hizo. La variable de comando era cat x etsy password.

Eso no es bueno. Y lo que es aún peor es que en realidad hizo cat etsy password. Y aquí mismo puedes ver que la evidencia está resaltada como parte de la respuesta aquí. Y eso, ya sabes, no es una gran vulnerabilidad para tener en tu aplicación GraphQL. Y aquí tienes más información al respecto. ScanRule pudo recuperar el contenido de un archivo en el sistema operativo. Así que en lugar de tener el código fuente, tenemos esta solicitud y objetos de respuesta que podemos revisar. Si quieres, puedes mirar aquí. Puedes ver los encabezados. Fue un post GraphQL. Aquí están las cookies que se usaron, pero aquí están las variables que se enviaron.

Entonces hay una pregunta. ¿Es similar la implementación de GitLab para StackHawk a la de GitHub? Es la misma. Entonces es lo mismo, StackHawk sigue siendo el mismo. El escáner es el mismo. Lo único que hace es ejecutarse en lo que sea equivalente a las acciones de GitLab. Por ejemplo, en Jenkins se ejecutaría en Docker. Si lo estás ejecutando en la línea de comandos, yo lo hago todo el tiempo en mi máquina. Se ejecuta y luego simplemente se ejecuta contra la aplicación. Simplemente se ejecuta contra el host y el puerto. Y luego informa los resultados a StackHawk. Las únicas limitaciones que puedo pensar podrían estar relacionadas con el entorno entre los dos, pero realmente todo se configura a través de ese archivo YAML de StackHawk. Así que volvamos aquí. Podemos ver el archivo YAML de StackHawk. Si vas a ver la documentación, este archivo puede volverse muy grande y complicado, pero hay mucho que puedes hacer allí. Así que realmente es lo mismo. Es el mismo escáner entre los dos.

Ok, otra cosa que hacemos es proporcionar este comando curl, que te permite reproducirlo. Así es como el escáner Hawk, nuestro escáner, lo encontró. Básicamente te lo damos. Así que imagina que lo estás haciendo localmente en tu máquina, estás intentando desarrollar algunas cosas, ejecutas el escáner, encuentra este problema. Puedes reproducirlo usando esta solicitud de reproducción. Simplemente copias esto, lo pegas en tu terminal y lo ejecutas. Puedes ver aquí la consulta, mutación super secreta. Y luego la variable, sí, variable cat Etsy password. Y otra cosa que puedes hacer es, digamos que estás de acuerdo con esto o no, digamos que no estás de acuerdo con esto, porque no es bueno. Quieres asignarlo. Puedes marcarlo como asignado. Puedes marcarlo como falso positivo, si no crees que sea un problema, o aceptar el riesgo. Es básicamente una forma de hacer un seguimiento de estos. Y la próxima vez que se ejecute el escáner, recordará eso y dirá, oh, no es nuevo, es un falso positivo. Ya lo has solucionado. Así que ese fue el primero, el segundo. Básicamente pasas por el mismo proceso. Así que miras esto, dices, oh, es CWE 89. Aquí tienes más información al respecto. Es una consulta, la consulta es un solo apóstrofe. ¿Y qué obtuvimos de eso? Sí, en realidad solo pasó ese apóstrofe simple a la database. Así que eso no es bueno. Podría ser mucho más malicioso. Así que probablemente quieras solucionarlo. Realiza una sanitización de SQL, una sanitización de entradas en tu entrada. Esas son las dos vulnerabilidades graves que encontró el escáner. Luego comenzamos a entrar en las vulnerabilidades medianas aquí, pero es el mismo tipo de cosa. Miras esta política de CSP aquí, tiene un comodín y sabes, la evidencia está aquí. Y si haces clic en respuesta, lo resalta para ti. Así que puedes saber exactamente dónde estaba en los encabezados, muy útil, es algo similar. Así que entras aquí. Y aquí es donde el dominio cruzado, esto es en todas estas operaciones diferentes. Así que quieres, y en las cabeceras de respuesta que salen de tu aplicación GraphQL, quieres, quieres ser un poco mejor en la configuración de dominio cruzado aquí. Muy bien, así que si estás haciendo cosas en la línea de comandos, puedes decirle a StackHawk, o incluso a través del comando Docker aquí, puedes decirle que vuelva a escanear y solo ejecutará las cosas.

Solo ejecutará las pruebas para los hallazgos que encontró en este escaneo. Entonces, si tienes uno realmente largo que lleva mucho tiempo... Básicamente, el caso de uso es si tienes algo que lleva tiempo y no quieres ejecutar todo cada vez, puedes hacer que se ejecute solo contra los hallazgos que encontró en el escaneo anterior. Entonces, básicamente, dices, ejecuta el escaneo, es un rescan, y aquí está el escaneo desde el que comienzas. Así que esa es una nueva función, pensé en señalar eso. Pasé mucho tiempo en eso. A medida que ejecutas escaneos, los obtendrás aquí, y te mostrará las diferencias entre ellos. No creo que... No creo que esto lo haga. Esto solo tiene los abiertos. Pero mantenemos un seguimiento de las cosas a lo largo del tiempo, para que puedas ver los nuevos que llegaron, o si solucionaste uno, entonces este número disminuirá, ese tipo de cosas.

Oh, mira esto. Acabas de ejecutar tu primer escaneo. Um, sí. Me olvidé por completo de esto aquí. Veamos, Dependabot, ya pasamos por eso. CodeQL. Escanea código, agrega patterns. Básicamente, sí, simplemente... Oh, es de código abierto, así que puedes ver esos patterns si quieres. StackHawk. Creo que cubrimos mucho de esto. Sabes, una de las cosas de las que no hablé fueron nuestras integraciones. Así que nos integramos con un montón de cosas diferentes, como Jira, para que puedas crear problemas directamente en StackHawk para encontrarlos. Entonces, si imaginas esa vulnerabilidad de SQL, si tienes la integración de Jira configurada, puedes ir allí y decir, oh, ¿sabes qué? Enviar a Jira, y luego creará el ticket de Jira para ti y lo vinculará. Eso es muy útil. También tenemos estas notificaciones basadas en eventos donde puedes recibir una notificación en Slack cada vez que un escaneo falla, ese tipo de cosas. Lo mismo con Teams. Tenemos un webhook genérico, por lo que podemos enviar eventos a medida que suceden en nuestro escáner, si quieres obtener la carga útil, si quieres cargarlos, si quieres enviar automáticamente cosas a alguna especie de, ya sabes, database para que puedas hacer un seguimiento de estas cosas por tu cuenta, puedes hacerlo. Creo que eso fue todo para la, oh, hay una vista previa de variables personalizadas. Esta es una nueva función que estamos lanzando ahora, creo, o la próxima semana, tal vez, no estoy seguro. No, está disponible, pero haremos un lanzamiento oficial la próxima semana con muchos recursos y materiales para ayudar a las personas a comenzar y ejecutar con variables personalizadas para APIs de GraphQL. Entonces, lo que hace esto es que te permite ingresar variables personalizadas en un formato específico. Entonces, si tienes un campo de correo electrónico aquí, puedes decir, sabes qué, quiero inyectar algunos datos falsos en forma de un correo electrónico, y creará una cadena que parece un correo electrónico aleatorio y lo usará como parte de eso, como viste, donde estaba la contraseña de cat etsy, comenzará a poner ese tipo de cosas en esos lugares. Así que es realmente, realmente genial para ejecutar tus comprobaciones de datos básicos, porque quiero decir, he escrito mucho código donde asumes que será un correo electrónico y luego manejas un patrón, pero luego hay algo más que llega y no habías pensado en eso. Entonces, lo que esto hace es que te permite inyectarlos, por lo que puedes hacerlo, hay una amplia gama de ellos. Entonces, hay correos electrónicos, teléfonos, UUID, todas esas cosas. Y se verá bastante realista, son datos que parecen reales que llegarán. Realmente pone a prueba la aplicación. Es genial tenerlo. Topher, corrígeme si me equivoco, también puedes proporcionar tus propias variables si quieres probar algo como un restablecimiento de contraseña. Y sí, esa es otra opción realmente útil. Sí, entonces, justo arriba de eso está, si no quieres usar la biblioteca Faker, si no quieres, si sabes que hay una cadena que quieres buscar, como digamos que tenías una contraseña o hay alguna cadena que si tienes un error sabes que causa un problema específico y quieres forzar esa cadena, puedes hacerlo aquí. Entonces puedes especificar estas variables personalizadas y luego las usará como parte de las pruebas. Así que hay un par de opciones diferentes aquí, puedes especificar cadenas codificadas en duro, como si sabes que hay una cadena problemática o como dije, si es una contraseña, si realmente necesitas eso, o si solo quieres generar datos que parezcan falsos e inteligentes, también puedes hacerlo. Y hablamos un poco sobre la configuración de GraphQL, hay muchas opciones aquí. Así que nuestros documentos intentan ser bastante completos. Este masterclass se trata realmente de configurar esos tres tipos de escáneres de seguridad. Y con esos tres, creo que, sí, para esta aplicación, ahora tenemos tres tipos diferentes de escaneo de seguridad habilitados. Tenemos el análisis de composición de software utilizando Dependabot, que nos informa sobre las dependencias. Tenemos el SAST, que buscará en el código fuente patrones que parezcan sospechosos y te alertará sobre ellos. Y luego tenemos DAST utilizando StackHawk, que se ejecutó contra la aplicación en vivo y encontró algunos problemas allí. Entonces sabemos que esos son problemas reales y pudimos verlos y clasificarlos, ya sea solucionarlos o decir, sabes qué, estamos bien con eso por ahora. Pero con esas tres cosas, acabamos de agregar algunas herramientas bastante buenas para nuestra aplicación vulnerable aquí, nuestra aplicación de ejemplo. En el futuro, espero que puedas usar esto para implementarlo en tu propio servicio de GraphQL. Y luego la idea es, ya sabes, una vez que estén en su lugar, cuando obtengas uno nuevo, la primera vez que lo escribas, obtendrás un montón de cosas, las revisas y solucionas y dices, no me importa esa biblioteca o lo que sea, o lo voy a solucionar. Y luego, en el futuro, cada vez que obtengas uno nuevo en cualquier confirmación, sabrás que, oh, hey, ese commit cambió algo y tengo que averiguar cuál fue el cambio y por qué esto activó esta alerta. Pero, ya sabes, eso es mucho mejor que pasar por todo el proceso y luego implementarlo y luego, ya sabes, recibir un correo electrónico que dice, hey, encontramos este problema en tu servidor de producción. Definitivamente no queremos hacer eso. Así que queremos hacerlo lo más cerca posible del commit. Y así que creo que, veamos los próximos pasos. Sí, ahora básicamente traduces lo que hicimos a tu entorno. Entonces, si no estás usando GitHub actions, cualquier proveedor de CI CD que estés usando, StackHawk los admite muchos.

Dependabot es, creo que es bastante fácil. Lo hemos habilitado para todas nuestras cosas en nuestros repositorios de GitHub. CodeQL es un proveedor de SaaS. Snyk es otro proveedor importante que está disponible. Tenemos integraciones con ambos. Sí, puedes usar esos.

Y luego, ya sabes, mantente en contacto. StackHawk, tenemos un blog. Siempre estamos haciendo cosas. Si tenemos tiempo, puedo mostrar algo de integración con Snyk. Snyk code es muy similar a CodeQL de GitHub y esa herramienta de SaaS. Escaneará patrones en tu código fuente y te informará la línea y el número de archivo o el archivo y el número de línea donde encontró el problema.

Lo que hacemos, nuestra integración con ambos, aunque no tengo la de GitHub lista para usar, es tratar de correlacionar un hallazgo de SaaS entre Snyk y un hallazgo de Dask en nuestro escáner. Básicamente, utilizaremos ese ID de CWE para correlacionar los dos para que puedas ver que no solo se encontró en el escaneo de SaaS, donde se dice, sabes qué, ese ID de usuario no parece correcto o esa es una contraseña secreta codificada. Si nuestro escáner lo encuentra, entonces vincularemos los dos y podrás ver que esto también se encontró en la aplicación en ejecución por el escáner de StackHawk.

Permíteme configurar esto aquí. Estoy en StackHawk, vamos a configurar una integración con Snyk, ID de organización de Snyk, así que tenemos una cuenta en Snyk para nuestra organización y luego generamos un token de API aquí. Ahora vamos a vincular los dos y Snyk, porque funciona en tu código fuente, debes darle acceso a tus repositorios porque tiene que leer el código fuente. Así que vamos a, tenemos nuestro, este es el Volne graph API, por lo que es el que bifurcamos básicamente. En cuanto al código fuente, será lo mismo porque no hemos cambiado nada. Y solo tengo una aplicación en StackHawk, que es el Volne graph API. Eso es prácticamente todo. Proporcionas tu ID de organización, tu clave de API, tu ID de organización de Snyk, tu clave de API de Snyk, y luego vinculas tu repositorio de código fuente, que ya has configurado en Snyk, con tu aplicación de StackHawk. Y dices finalizar. Y ahora están aquí. Si volvemos a nuestro repositorio, vamos a nuestra acción. Vamos a la acción de compilación y prueba aquí, flujo de trabajo. Solo queremos volver a ejecutar esto. Se volverá a ejecutar y como parte de su ejecución, tiene el paso de escaneo de Hawk. Así que Hawk scan aquí. La diferencia es que esta vez, cuando se ejecuta el paso de escaneo de Hawk, ejecutará el escáner. El escáner se ejecutará contra la aplicación, enviará los resultados de vuelta a la plataforma de StackHawk. Sin embargo, esta vez tenemos la integración con Snyk aquí. A medida que lleguen los hallazgos, StackHawk, nuestra plataforma, se comunicará con Snyk y preguntará, ¿tienes algún hallazgo para esto? Y si lo tiene, correlacionará los dos y luego podremos verlo en StackHawk. Y eso es realmente genial porque StackHawk encontró el problema en la aplicación en ejecución. Y luego puedes seguir la integración hasta la línea de código real que encontró Snyk. Así que vinculas esas dos cosas. Es un problema en el que las herramientas SAST dirán, esto parece un problema. Este ID de usuario parece incorrecto o este secreto parece incorrecto, pero en realidad podría no ser un problema en la aplicación en ejecución si esa parte del código nunca se usa o si es solo una utilidad de prueba o podría ser cualquier número de cosas. Esa ruta lógica no se ejecuta en el código, sea lo que sea. Y luego, por otro lado, StackHawk, encontramos un problema, pero StackHawk no tiene conocimiento del código. Se ejecuta fuera de tu aplicación. Se ejecuta en un host y un puerto. Sabe que es una aplicación GraphQL, pero eso es todo. No puede acceder al código fuente. Así que estamos tratando de cerrar la brecha aquí entre los dos mediante esta integración con Snyk y la de CodeQL también. Acabamos de lanzar la integración de CodeQL. Básicamente se verá muy similar a lo que te mostraré con la de Snyk. No he actualizado este masterclass porque es muy nuevo. Así que está construyendo la aplicación aquí.

Ahora se ejecutó la aplicación. Ahora está ejecutando el escaneo de Hawk. Como puedes ver, esto responde parcialmente a la pregunta de cuál es la diferencia entre esto y GitLab. En el núcleo, el escáner es el mismo. Simplemente se ejecuta el comando de Hawk en Docker. Se puede ejecutar en Docker. Se puede ejecutar en tu escritorio. Luego, todos los proveedores de CICD tienen formas de ejecutar cosas en Docker, o puedes intentar configurar el comando de Hawk directamente allí. Estamos haciendo algunas de esas cosas con Microsoft Azure en este momento. Tienen una forma de decir, sabes qué, voy a ejecutar un comando de Java. Entonces, Hawk es una aplicación de Java. Por lo tanto, puedes configurar una acción que diga, hey, no ejecutes el escáner en Docker. No quieres ejecutarlo directamente, pero debes tener Java configurado, y luego debes descargar Hawk. Lo proporcionamos como un archivo zip, por lo que puedes descargar el archivo zip, descomprimirlo y ejecutarlo directamente. Así que eso depende de cómo funcione el sistema de CICD, qué tan bien admita Docker, qué tan bien admita la ejecución de cosas de terceros arbitrarias. Pero de todos modos, esta es la misma salida que si lo estuviera ejecutando en mi computadora portátil, o si lo estuvieras ejecutando en tu máquina. Así que ejecuta este comando de Hawk. Ahí está el archivo stackhawk.yml especificado. Ahora está en la ruta de este proyecto. Se inicia, puedes ver que se está ejecutando la versión 2.9. Aquí está, localhost 3000. Ese es el host que configuramos cuando lo estábamos configurando. Todo listo. Voy a repasar esto. Así que aquí tienes, puedes tener una idea de lo que está haciendo aquí. Encuentra 11 rutas de GraphQL. Va a probarlas todas. Pasa por aquí, hace todo eso, ejecuta, ya sabes, un montón de cosas de estado. Y al final, para la línea de comandos, en realidad mostramos este pequeño resumen útil aquí. Así que entras aquí. Ahí está esa inyección remota de comandos del sistema operativo. Aquí está la inyección de SQL. Básicamente, son las cosas que encontramos. No creo que las imprima todas. Creo que solo imprime algunas de ellas. Pero, así que se ejecutó, esa es la salida. Y luego, si volvemos aquí, ahora hemos ejecutado otra instancia. Así que a las 10 en punto, hora de Denver, ejecutamos la primera y luego ejecutamos la segunda aquí, pero con la integración de Snyk. Ahora tenemos indicadores aquí que nos dicen que algunos de los hallazgos se correlacionaron con los hallazgos evaluados en Snyk. Entonces, si vamos a la inyección de SQL, decimos, bien, genial. Ya habíamos visto esto antes. Vamos, sí, es esa consulta. Es una comilla simple. Eso causaría un problema. Error de SQLite, ¿recuerdas este? Sí, claro, solo estamos pasando eso. No estamos sanitizando las entradas. La diferencia ahora es que ahora tenemos esta pestaña de código de Snyk aquí. Podemos hacer clic en esto y decimos, oh, CWE89. Wow. Snyk encontró eso en el archivo post.ts.

Y si vamos aquí, vamos, oh sí. Sí, eso es, así que si miras esto, está tomando esta consulta directamente de los argumentos, directamente de la URL. No está haciendo nada con eso. Y simplemente, oh, argumentos, lo siento, los argumentos. Sí, por lo que está pasando este argumento directamente de la consulta a esto. Sí, por lo que un solo apóstrofe causaría que esto, básicamente, se analice y se finalice. Tendrías algunas cosas adicionales. Entonces sí, necesitamos abordar eso. Pero puedes ver cómo este es un problema detectado en la aplicación en ejecución. Y esta es la línea de código real que parece bastante sospechosa y necesita corregirse. También puedes volver a Snyk y verlo.

Algo similar donde tienen, aquí está la línea de código, un poco más de información al respecto. Y luego hubo otro. Entonces este servidor filtra X powered by... Aquí están todas las operaciones que se detectaron con este problema. Así que ahora vamos al código de Snyk, y tal vez esté en un par de lugares diferentes. Así que vamos aquí, no le gusta eso. Y no le gusta. Oh, sí. Sí. Entonces este también es... Este también. Sí. Por defecto, Express envía este encabezado X powered by. Y está filtrando información sobre tu aplicación. Entonces, si un tercero malintencionado, podrías decir, oh, sé que esto es una aplicación de Express. Ahora sé que puedo investigar ciertas vulnerabilidades de Express. Sí, puedes usar el middleware helmet para no revelar esa información. Pero sí, hay dos lugares en el código. Deberías revisar eso y solucionarlo. Sí. Esa es nuestra integración de Sneak. Es bastante buena, puedes ver entre las ejecuciones del escaneo aquí, no hemos... Nada realmente cambió porque no cambiamos ningún código ni hicimos nada. La única diferencia es que agregamos una integración de Sneak aquí. Y como dije antes, el otro proveedor de SAST con el que nos integramos es GitHub CodeQL. Sí, CodeQL. Y se ve muy similar. De hecho, puedes tener ambos ejecutándose al mismo tiempo, creo, pero tendría, básicamente tendría marcadores de CodeQL aquí y los enlaces volverían a CodeQL. Así que eso está tratando de cerrar esa brecha. Tenemos el análisis de composición de software de Dependabot. Tenemos SAST, el análisis estático y el análisis dinámico de StackHawk. Realmente estamos tratando de unir esos dos porque poder decir, hey, esta línea de código está causando este problema en tu aplicación en ejecución es realmente poderoso. Y es algo genial si eres un ingeniero, como poder saber, poder ver eso, como cuando haces una confirmación, confirmas un montón de cambios y luego esto se activa y dice, oh, sabes qué, esta línea que acabas de agregar tiene este problema. Hacer eso en el momento de la confirmación es súper poderoso. Simplemente, hace las cosas fáciles y rápidas. Eso es todo lo que tenemos. Sí, los próximos pasos, actualizaciones del escáner CI. Es todo buen material. Esperemos que esto se traduzca fácilmente en tus aplicaciones de GraphQL, la parte de CI. Como dije, si no estás usando GitHub Actions, soportamos muchos otros. La idea básica es la misma, configuras, si es GitLab o Jenkins o cualquier otro, básicamente configuras el escáner, el escáner de StackHawk para que se ejecute en tu CI, pipeline de CI/CD contra tu aplicación. Y luego informa los resultados. Dependabot y CodeQL, porque operan en el código fuente, no tienes que, no tienes que tener una aplicación en ejecución. Es un poco más fácil ponerlos en marcha. Sneak es muy similar. Básicamente, cuando vas a ejecutar, cuando vas a usar Sneak, querrá acceso a tus repositorios de GitHub y tú dices, sí, está bien. Y los verifica y luego ejecuta, ejecuta su coincidencia de patrones directamente en tus repositorios. Pero es lo mismo que hicimos con CodeQL. Esperemos que eso se traduzca, ves que Sneak o CodeQL, es muy, muy similar. Y luego tenemos nuestras actualizaciones, manténganse atentos.

Siempre hay cosas nuevas que salen. Creo, sí, creo que eso lo resume. Como dijo Topher, quiero decir, pasamos por un sistema de seguridad realmente sólido security aquí con varios tipos de security testing que se llevan a cabo al mismo tiempo. Así que gracias por eso, Topher, fue increíble.

Y como mencionó, pasamos por un par de ejemplos específicos utilizando herramientas particulares para facilitarlo, pero hay muchas herramientas que podrías usar. CodeQL se puede intercambiar con Snyk, e incluso creo que Snyk tiene una herramienta de análisis de composición de software también. Así que todas estas herramientas funcionan, juntas, para brindarte una cobertura realmente completa de tus APIs y aplicaciones.

Así que por favor, siéntete libre de utilizar cualquiera de esos recursos que dejamos en Discord para profundizar, ya sabes, con esta experimentación ahora. Quiero decir, si estuviste completamente en la masterclass, tienes una cuenta de StackHawk, estás en una prueba gratuita, creo que es una prueba gratuita a nivel enterprise cuando pasas por eso. Sí, así que tienes acceso a todo durante ese tiempo. Juega con ello, conecta algunas cosas, y nuestro equipo también se pondrá en contacto con más recursos sobre cómo puedes simplemente jugar y explorar con StackHawk y conectar algunas de estas herramientas. Así que, sí, gracias a todos por unirse. Gracias Topher por llevar a cabo una masterclass tan buena. Espero que disfruten el resto de su día. Gracias a todos.