Masterclass de Pruebas de Seguridad de GraphQL

Los siguientes videos son extractos de esta serie. Hoy, el título es Pruebas de Seguridad Automatizadas de GraphQL. Y mi nombre es Zachary Conger. Soy un ingeniero senior de DevOps en StackHawk, y trabajo como gerente de la empresa para StackHawk. Mi función principal es ayudarte a tener un producto DAST, un escáner de pruebas de seguridad de aplicaciones dinámicas. Soy un adoptante temprano de DevOps. He estado desarrollando software, automatización, pruebas, observabilidad, ese tipo de cosas durante muchos años, demasiados años. Y en mi tiempo libre, me gusta tocar música, andar en bicicleta y tomar fotografías amateur. Soy realmente, realmente súper útil con cualquier problema técnico que surja. Pero espero que no haya demasiados, porque nuevamente, vamos a operar completamente desde un navegador web, que es prácticamente todo lo que necesitas hoy en día. Una última vez, debes obtener la guía del taller, hay un enlace en Discord y en el chat de Zoom. Vamos a usar Discord, así que únete a Discord si aún no estás allí. Lo usaremos para encuestas y puntos de control, por lo que cuando lleguemos a ciertos puntos en el taller, nos detendremos y diremos, `¿todos están al día?` Y tú nos darás un pulgar hacia arriba si lo estás y un pulgar hacia abajo si no lo estás. Realmente ayuda con el flujo y asegurarse de que todos puedan aprovechar al máximo el taller. Y finalmente, si no tienes una cuenta de GitHub, ve a github.com y regístrate. Aquí está la agenda para hoy. Vamos a tomar una aplicación GraphQL. Es una aplicación de prueba simple de GraphQL que realmente no hace mucho aparte de proporcionar una interfaz gráfica. Es como un pequeño motor de blogs, un motor de blogs simple. Tiene algunas vulnerabilidades. Lo que vamos a hacer es todos vamos a hacer un fork de ese repositorio en nuestra propia cuenta de GitHub, luego vamos a agregar un flujo de trabajo de GitHub Actions para automatizar la construcción de esa aplicación en GitHub Actions. Luego vamos a comenzar a agregar pruebas de seguridad a ese flujo de trabajo para que cada vez que envíes código al repositorio de GitHub, se ejecuten más pruebas en él. Entonces, la primera prueba, en realidad, algunas de estas están basadas en el flujo de trabajo y otras son más automáticas que eso, simplemente ocurren en segundo plano. Dependabot es la primera prueba que agregaremos, que probará tu aplicación en busca de vulnerabilidades conocidas y cualquier dependencia que agregues. La siguiente será CodeQL, que analizará el código de la aplicación, en realidad, recorrerá todo el código y buscará patrones que indiquen vulnerabilidades. Y luego, finalmente, agregaremos Stackhawk, que escaneará dinámicamente la aplicación en ejecución en busca de vulnerabilidades. Y todo esto ocurre en el flujo de trabajo de CI/CD, por lo que es automático en cada envío. Bien, mencioné estas formas de pruebas y déjame explicarlas un poco más detalladamente. Este taller se supone que es bastante general, pero estamos utilizando algunas herramientas específicas. Por supuesto, Stackhawk es una de ellas y soy de Stackhawk. Creemos que es la mejor herramienta DAST disponible, pero hay otras opciones y el objetivo de este taller es que conozcas todas ellas, o muchas de ellas. Entonces, el primer tipo de prueba que vamos a hacer se llama SCA o análisis de composición de software. Y en esta forma de prueba, opera en código estático y recorre tus dependencias. Examina tu, en este caso, vamos a examinar el archivo package.json y el archivo package lock.json, y vamos a buscar, va a construir la cadena de dependencia y verificar todo eso en el catálogo de bibliotecas y dependencias de código abierto e informar sobre cualquier vulnerabilidad conocida en cualquiera de esas versiones de bibliotecas. Y si encuentra alguna, te dará un plan de acción para solucionarlo. Entonces, SCA se ha convertido en algo así como un estándar básico que debes hacer en todos tus repositorios. No hay falsos positivos en cierto sentido porque todas las vulnerabilidades que encuentra son vulnerabilidades conocidas y es muy rápido y es muy fácil y generalmente es gratuito. La mayoría de las empresas que ofrecen SCA ofrecen un plan gratuito o un plan bastante económico. Hoy vamos a usar Dependabot, pero hay otras opciones realmente buenas. Sneak es una de las mejores, de hecho. Es posible que en el futuro también incluyamos Sneak como la opción de SCA que hagamos. Dependabot también es muy bueno. Y luego hay otra versión, una versión de código abierto llamada FASA, también tienen una opción respaldada comercialmente. El siguiente tipo de prueba que vamos a agregar a nuestra aplicación se llama SAS o Pruebas de Seguridad de Aplicaciones Estáticas. Ejemplos de esto son CodeQL, que vamos a usar hoy. También hay SonarQube y CheckMarks y muchas otras buenas opciones. Si buscas en Google por SAS, encontrarás muchas opciones disponibles. Este tipo de prueba también opera en código estático, pero no está mirando tus dependencias en absoluto. En realidad, está revisando tu base de código y busca patrones que indiquen que podrías tener una vulnerabilidad. Tal vez no estés haciendo ninguna sanitización de entradas, por ejemplo, generalmente encontraría ese tipo de problema y te lo informaría.

Es realmente genial porque a medida que encuentra tus errores, puede señalarlos por archivo y por línea. Te permite saber exactamente dónde está el problema. Tiende a tener muchos falsos positivos y en mi experiencia no encuentra mucho que sea útil en comparación con otras herramientas. Pero eso mejora cada día a medida que estas herramientas mejoran.

También es un poco lento porque necesita compilar tu código, buscarlo y consultarlo. Cuanto más grande sea tu base de código, más lento se vuelve.

Finalmente, vamos a ver DAST, pruebas de seguridad de aplicaciones dinámicas. Hay varios ejemplos de este tipo de escáner. El nuestro se llama Stackhawk. Eso es lo que vamos a usar hoy. Otros incluyen OASP Zap, que es un proyecto de código abierto en el que Stackhawk se basa, hemos construido sobre OASP Zap. También está Burp Suite, que es una herramienta de pruebas de penetración muy común. Y han estado trabajando para facilitar su automatización también.

Las pruebas de seguridad de aplicaciones dinámicas son una forma de escaneo que opera en tu código en ejecución. Por lo general, esto se aplica a una aplicación basada en web, tal vez una interfaz REST en nuestro caso de hoy. Es una interfaz GraphQL. Simplemente se ejecuta, sondea ese servicio en busca de vulnerabilidades. Envía solicitudes, examina las respuestas y, en función de las respuestas que recibe, intenta determinar si hay alguna forma de vulnerabilidad. Informa sobre esas posibles vulnerabilidades. En lugar de darte detalles línea por línea, te muestra la entrada y salida que causó que el escáner piense que hay un problema con tu código. Al igual que SAST, encuentra tus errores, pero a diferencia de SAST tiende a tener menos falsos positivos y encuentra cosas más útiles. De hecho, debido a que está escaneando una aplicación en ejecución, puedes tener cierta confianza en que las cosas que encuentra son realmente cosas expuestas en tu aplicación y explotables en la vida real, siempre y cuando lo que estés probando realmente represente lo que vas a ejecutar en producción. Puede ser un poco lento. Esa es una de las desventajas de DAST. Pero eso depende del tamaño de tu aplicación, de su capacidad de respuesta y de la proximidad del escáner a la aplicación en ejecución. Incluso si es bastante lento, generalmente hay formas de dividirlo y paralelizar el escaneo para que sea más rápido.

Ok, eso es lo que vamos a ver hoy. Y creo que a partir de ahí, vamos a pasar a comenzar por, sí, vamos a ver GitHub Actions. Entonces, el primer paso en nuestro plan es hacer un fork de una aplicación de prueba llamada Phone GraphQL API. Y vamos a crear un flujo de trabajo de GitHub Actions para construirlo básicamente en un pipeline de CI/CD integrado en GitHub.

GitHub Actions es un pipeline de CI/CD integrado en GitHub, tiene un lenguaje de configuración YAML simple y un gran mercado de acciones, que son como complementos. Y esto es lo genial de GitHub Actions en mi opinión, que crearon una forma realmente fácil para que los autores creen acciones que simplifiquen pasos complejos a través de estas pequeñas acciones que puedes agregar. Así que usaremos un par de esas acciones. Usaremos una acción de Stackhawk, una acción de CodeQL, y así sucesivamente. Pero es un sistema realmente genial. Está basado en eventos, generalmente basado en envíos, PR, pero también puedes tener webhooks arbitrarios como eventos de inicio. Y para cada flujo de trabajo que creas, los llaman flujos de trabajo. Dentro de un flujo de trabajo, un solo flujo de trabajo iniciará un solo runner. Por defecto, eso ocurre en la nube de GitHub. En realidad, tienen máquinas virtuales que aparecerán para ti en su propia nube. Y luego, dentro de un flujo de trabajo, que instancia un runner, puedes tener múltiples trabajos, que pueden ejecutarse en paralelo o pueden activarse entre sí, pueden tener un orden. Y dentro de cada trabajo, tienes varios pasos que se ejecutan en secuencia. Así que vamos a hacer un solo flujo de trabajo, un solo trabajo y un par de pasos en nuestro flujo de trabajo. Un ejemplo sencillo. Y cada paso puede ser ejecutar un comando de shell, puedes tener runners basados en Windows y runners basados en Linux. Así que puedes ejecutar un simple comando de shell o ejecutar una acción del mercado de GitHub Actions. Haremos un poco de ambos. Hay una solución de gestión de secretos integrada en GitHub Actions, que nos será útil porque la usaremos para almacenar una clave de API secreta.

Y para tus cuentas personales, esto es todo gratuito. Obtienes 2000 minutos gratuitos al mes de compilación y eso es bastante genial. Entonces, si no lo usas para el trabajo, recomiendo usarlo para tus proyectos personales simplemente porque es muy económico y efectivo.

Muy bien, así que vamos a empezar. Primer paso, dirígete a este repositorio. Esta es una aplicación de prueba simple nuevamente llamada volumegraphqlapi. Publicaremos un enlace a esto. Genial, ahí vamos. Muy bien, dirígete al enlace en Discord. Vamos a hacer clic en Fork y luego danos un pulgar arriba cuando hayas hecho el fork. Así que simplemente vamos a ir a volumegraphqlapi aquí. Haz clic en el botón Fork en la esquina superior derecha aquí. Voy a hacer un fork en mi propia organización personal. Tenemos un montón de profesionales aquí, ustedes están al tanto de esto, esto es increíble. Muy bien, me doy un pulgar arriba a mí mismo. Muy bien, lo hemos bifurcado aquí. Solo voy a seguir mi propia agenda aquí. Muy bien, se ve bien. Tenemos a ocho personas al día.

Y ahora lo que quiero hacer es agregar un nuevo archivo. Entonces, arriba aquí, hay esta opción de ir a archivo, agregar archivo, haz clic en agregar archivo, crea un nuevo archivo. Ahora, sé que a algunas personas les horrorizará la forma en que lo hicimos hoy. Todos estamos acostumbrados a trabajar en IDE y yo también, pero esto es solo para que todos trabajen desde la misma página y para minimizar las diferencias de estaciones de trabajo y las variaciones que pueden hacer que las personas se atasquen a veces. Así que vamos a crear un nuevo archivo y este archivo debe estar en el directorio .GitHub. El directorio .GitHub tiende a tener archivos especiales de GitHub como plantillas para PR y en nuestro caso, flujos de trabajo, hay un archivo de propietarios de código. Puedes agregar toneladas de cosas propietarias de GitHub que tienden a ir allí. Entonces, en el directorio .GitHub, crea un directorio de flujos de trabajo y aquí es donde se colocarán todos tus flujos de trabajo de GitHub actions. Crearemos nuestro primer flujo de trabajo de GitHub actions llamado build and test YAML. En main y siempre uso YML. Creo que también se puede usar YAML. Pero de todos modos, voy a volver a consultarlo. Lo sacaré lentamente aquí. Mi referencia, es útil aquí. Entonces, este es nuestro primer flujo de trabajo, build and test. Realmente vamos a construir la aplicación en un contenedor Docker. Así que lo llamaremos, build and test. Lo ejecutaremos cada vez que hagamos push, y aquí, si quieres, puedes agregar ramas y cosas así. Creo que sería más así. Ramas, main, etc. Pero por simplicidad, voy a decir en push. Entonces, cada vez que hagamos push de código a este repositorio, tendremos un solo trabajo llamado HockScan. Y lo llamaremos, build and test. Y se ejecutará en una imagen de Ubuntu, versión 20.04. Y en realidad iniciará una máquina virtual con siete gigas de RAM y creo que unos 16 gigas de espacio en disco y dos CPUs. Así que es una máquina decente para la mayoría de estos tipos de trabajos. También hay una opción para ejecutar tus propios runners en tus propias instalaciones si lo deseas. Si tus cargas de trabajo son más grandes que eso. Muy bien, así que vamos a ejecutar varios pasos. El primero será clonar nuestro repositorio y para esto, vamos a usar una acción de GitHub y esta es una de las acciones estándar de GitHub. Tienen varias acciones integradas, básicamente, que mantienen ellos mismos.

Son de alta calidad y se encargan de muchas cosas de bajo nivel así que este simplemente clona un repositorio y, de forma predeterminada, se encarga de determinar en qué confirmación estamos trabajando en este flujo de trabajo. No tienes que especificar la rama o el hash de confirmación. Se encarga de eso por ti de forma predeterminada. Así que usa la acción, check out.

El siguiente paso es construir la aplicación y esto en realidad solo ejecutará un comando de shell. Ese comando de shell es docker compose build. Y más adelante, después del taller, si quieres continuar con esto y explorarlo por tu cuenta, definitivamente vale la pena echar un vistazo a esa aplicación de prueba, ejecutarla en tu propia estación de trabajo, ver si puedes hacerla funcionar y escanearla localmente. Pero aquí simplemente la ejecutaremos y escanearemos en GitHub Actions.

Así que tenemos nuestro archivo de flujo de trabajo. El flujo de trabajo se llama construir y probar. Tiene un solo trabajo también llamado construir y probar. Clona el repositorio, construye la aplicación. Vamos a confirmar este archivo. Y una vez que lo hagas, si haces clic en acciones, deberías ver que se está construyendo. Así que Nick ha publicado la configuración del archivo en el chat de Discord. Si logras que esto funcione y haces clic en acciones y ves que tu flujo de trabajo se está ejecutando, avísanos. No puedo, oh, tengo un error tipográfico en el mío. Así que todavía no puedo darte un pulgar arriba para mí. Voy a volver aquí. Acciones. Eso debería funcionar. Vuelve a acciones aquí. La pestaña de acciones en la parte superior de la consola de tu repositorio. Y el mío se está ejecutando. Veamos si funciona esta vez. Se ve bien. Clonar el repositorio. Construyendo la aplicación.

Así que esta sección de construcción de la aplicación llevará un poco de tiempo. Utiliza Docker para construir la aplicación y tiene algunas cosas que hacer. A medida que avanzamos, con suerte, a medida que construyamos más y más esto se acelerará un poco porque los ejecutores de GitHub, con suerte, elegirán un ejecutor que esté en una máquina que tenga tu caché. Y así, si haces esto con frecuencia tiende a ejecutarse un poco más rápido la próxima vez. Déjame ver, creo que lo tengo ejecutándose localmente, sí. Así que tengo una copia de esta cosa ejecutándose localmente y si te estás aburriendo puedes intentar descargarla y ejecutarla localmente pero definitivamente no es necesario para lo que estamos haciendo hoy. Pero solo te mostraré lo que obtienes si inicias sesión en la cosa. Se está ejecutando en localhost 3000 y simplemente abre una interfaz gráfica y he agregado una pequeña consulta allí, no hay mucho en ella, la única razón por la que la tengo ejecutándose localmente es porque quiero mostrarte un poco más adelante un ejemplo de una vulnerabilidad en la aplicación.

Muy bien, todavía estamos construyendo, esto llevará un tiempo. ¿Tienes alguna pregunta? Creo que Antoine Sharife, creo que hay un simple error tipográfico. Sí, Ubuntu en lugar de Ubuntu. No lo sé. Gracias, Benjamin. Interesante. Claudia, Gabrielle Cristea tiene un problema en el que no ha funcionado para ti. ¿Puedes compartir, ya que estos son repositorios públicos, Claudia, puedes compartir la URL de tu repositorio? Tal vez Nick pueda echarle un vistazo. Gracias, genial, la construcción se completa. De acuerdo, genial. Genial, la construcción se completa. Oh, creo que el libro de guía del taller de GraphQL testing, creo que has clonado el libro de guía del taller en lugar de la aplicación de prueba. Veamos, creo que lo que quieres clonar. Acabo de publicar la URL allí para ti. Esto es genial. Gracias de nuevo, Benjamin. Siempre es genial cuando las personas se ayudan mutuamente en el chat. Y gracias por la paciencia de todos. Deberíamos tener tiempo suficiente para completar todo esto, pero me aseguraré de que nos mantengamos en el camino correcto. Sí, entonces Shashank. Hay un error tipográfico en tu archivo de flujo de trabajo, debería ser uses en lugar de users. Genial. Muy bien. Todos cometemos errores tipográficos hoy. Yo también cometí el mío. Se supone que debo estar ejecutando esta cosa.

Muy bien, mientras todos se ponen al día, siéntanse libres de ir a la guía y copiar y pegar la configuración del flujo de trabajo si tienen problemas. Voy a pasar al siguiente paso y comenzar a describir lo que vamos a hacer.

Vamos a usar Dependabot. Dependabot es un SCA gratuito para repositorios de GitHub. Hay muchas otras opciones excelentes de SCA disponibles. Incluso lo encontrarás integrado en muchos de los repositorios de artefactos en estos días. Sé que JFrog y Nexus tienen algo similar.

Simplemente verificará tus dependencias directamente en el repositorio de artefactos. Dependabot en GitHub está habilitado por defecto en los repositorios públicos. Pero si haces un fork de un repositorio, no está habilitado por defecto, incluso si es público. También es fácil agregarlo a repositorios privados y es gratuito para ambos. Encuentra bibliotecas con vulnerabilidades, tomará tu archivo de dependencias, ya sea tu archivo Gradle o Maven, archivo Palm, simplemente lo buscará, e incluso intentará desglosar todas las subdependencias que se derivan de las dependencias que has incluido. Y luego revisará cada una de ellas para ver si hay vulnerabilidades conocidas y te lo hará saber.

Y Dependabot es genial. Hay otras herramientas que también hacen esto. Cuando encuentra un problema, te dirá exactamente qué hacer para solucionarlo. Y si puede, incluso creará una solicitud de extracción (PR) para solucionarlo. Y en nuestro caso, esa PR iniciará nuestro flujo de trabajo nuevamente, por lo que pasará por todas las pruebas que tengas, y se asegurará de que se compile correctamente, y todo lo que tienes que hacer para solucionarlo es aceptar la PR. En la práctica, puede tener algunos falsos positivos, aunque todo lo que encuentra realmente es una vulnerabilidad. Puede haber falsos positivos porque podrías incluir una biblioteca gigante que tiene un pequeño error aquí y todas las herramientas que usas, ninguna de ellas realmente toca ese error. Por lo tanto, teóricamente es posible que informe sobre algo que es una vulnerabilidad, pero que realmente no te afecta. Aun así, todos sabemos que es mejor mantenernos al día con estas cosas de manera constante, y es bueno tener algo que nos recuerde, simplemente nos recuerde, hey, hay actualizaciones que deberías revisar, y aquí tienes una forma fácil de solucionarlo.

Muy bien, voy a pasar a solucionarlo. Espero que todos estén al día con nosotros, y vamos a hacerlo. Así que voy a volver a mi código base. Estoy en mi fork de Vuln GraphQL API, y voy a ir a la pestaña de seguridad aquí. Y bajo la pestaña de seguridad, hay varias cosas interesantes, y vamos a usar dos de ellas, pero primero, vamos a hacer las alertas de Dependabot.

Queremos habilitar las alertas de Dependabot para que nos notifiquen cuando una de nuestras dependencias tenga una vulnerabilidad. Haz clic en la pestaña de seguridad, habilita las alertas de Dependabot, y ahora tiene todas estas opciones. Vamos a hacer estas tres primeras. No vamos a hacer esta todavía. Lo haremos más tarde. Solo queremos hacer estas tres. Primero, Dependency Graph permite a GitHub revisar tu archivo de dependencias, sea cual sea, si es un archivo POM o en nuestro caso, un archivo package.json, y procesarlo básicamente, y buscar todas las subdependencias. Queremos eso. Encontrará más cosas. Queremos las alertas de Dependabot para que recibamos alertas cada vez que se encuentren nuevas vulnerabilidades. Es fácil. Luego, las actualizaciones de seguridad de Dependabot. Actualiza fácilmente a dependencias no vulnerables. Esta es la función que realmente emitirá una PR a tu repositorio, y eso es bastante impresionante. Así que lo habilitaremos. Muy bien, y si has habilitado estas tres cosas, pero no te preocupes por esta todavía, si has habilitado estas tres cosas, muy pronto deberías ver un nuevo distintivo junto a tu pestaña de seguridad. Dice, en mi caso, 11, sospecho que todos los demás también tienen 11. Haz clic allí, y verás un distintivo que dice 11 junto a las alertas de Dependabot. Haz clic allí, y verás 11 alertas diferentes. Así que ha descubierto que tenemos un montón de dependencias de NPM que hemos especificado, y son problemáticas. Así que simplemente haz clic en una como ejemplo, esta dependencia tar. Encuentra que tenemos la versión 4.4.13, y recomienda que actualicemos a la 4.4.19 porque hay cinco vulnerabilidades diferentes en ella, y nos muestra cómo hacer este cambio simplemente editando nuestro archivo Yarn, y nos brinda muchos detalles sobre cuál es el problema, creación arbitraria de archivos, anulación y ejecución de código. Bastante malo, no quieres eso en tu utilidad tar.

Entonces, ¿dónde está buscando para verificar estas vulnerabilidades? Creo que es el CVE, déjame ver. Sí, está revisando la base de datos CVE. Es el CVE 2021, sí, ahí lo tienes. Vamos a ver aquí. Así que todo es terrible, tienes muchos detalles aquí. De todos modos, es algo sencillo de solucionar, solo actualiza la cosa y oh, mira, hay varias solicitudes de extracción disponibles en este momento. Entonces, si vas a la pestaña de solicitudes de extracción, espero que todos los demás también estén viendo esto. Si miras las solicitudes de extracción, tienes varias solicitudes de extracción en espera. Y una de ellas es para la utilidad tar que estábamos viendo. Y si hago clic en esto, me muestra la solicitud de extracción, dice, Dependabot ha creado una pequeña descripción de lo que está intentando hacer, muestra algunos de los archivos que cambió. Así que realmente hizo algunos cambios en nuestro archivo YarnLock, incluyendo, con suerte, uno de ellos es el archivo tar. Así que cambió el archivo YarnLock de 13 a 19. Y si volvemos a mirar la conversación, está ejecutando algunas pruebas. Así que está ejecutando nuestro flujo de trabajo de compilación y prueba que ya creamos para asegurarnos de que hacer este cambio no rompa la aplicación. Así que vamos a ver los detalles de eso, y eso nos llevará de vuelta a GitHub Actions en la pestaña de Acciones. Y nos muestra que está intentando compilar la aplicación para ti, y nos muestra que está intentando compilar la aplicación nuevamente. Y siempre y cuando esto tenga éxito, debería ser seguro enviar esta solicitud de extracción y fusionarla con tu código base. Así que eso es dependabot, ¿cómo les va a todos con esto? ¿Todos están al día y ven lo mismo que estoy viendo yo? De acuerdo, sigan adelante. Entonces alguien preguntó, ¿puedes validar a tus usuarios, cómo podemos asegurarnos de que todo funcione correctamente y tener este backend que es una ubicación de tráfico y alguien pregunta, ¿cómo sé que mi aplicación seguirá funcionando después de actualizar la versión de la biblioteca? Esa es una gran pregunta. Sí, la respuesta es, siempre y cuando hayas creado un buen flujo de trabajo de CI/CD que incluya suficientes pruebas para detectar cualquier problema, puedes tener la confianza de que funcionará si esas solicitudes de extracción se completan. Así que volvamos y revisemos estas solicitudes de extracción nuevamente. Así que echemos un vistazo a la solicitud de extracción de tar, y ha pasado por sus pruebas, y pudo compilar la aplicación nuevamente con éxito. Así que siempre y cuando hayamos hecho nuestras pruebas correctamente, la aplicación debería funcionar perfectamente. Ahora, no lo hemos hecho, no hemos configurado muchas pruebas extensas, así que no sabemos eso con certeza, pero presumiblemente en tu código base, tienes pruebas unitarias y algunas pruebas de integración. Puedes fusionar las solicitudes de extracción si quieres, pero no es necesario. No voy a fusionar la mía solo porque queremos seguir avanzando, pero es algo genial para probar tal vez más adelante después del taller. Pero si no puedes resistirte y tienes que fusionar una de esas solicitudes ahora mismo, adelante. Veamos. Agrega algunas validaciones manuales en caso de un cambio importante. Sí, y creo que en el caso de un cambio importante, hay algunas vulnerabilidades que dependabot encuentra. En realidad, no sugerirá una solicitud de extracción para ti. Y creo que una actualización de versión importante es uno de esos casos en los que probablemente no intentaría crear una solicitud de extracción para ello. Entonces, sí, de acuerdo, a menos que alguien quiera que lo haga más despacio y definitivamente avísennos, voy a pasar al siguiente problema que queremos abordar. Así que lo siguiente que vamos a ver es CodeQL, que es una utilidad de análisis estático de seguridad de aplicaciones (SAST). Entonces, CodeQL, nuevamente, es un escáner de prueba de seguridad de análisis estático (SAST). Y lo que hace es tomar tu código y solo funciona en tipos específicos de lenguajes. Afortunadamente, en nuestro caso, JavaScript es uno de ellos. Y el motor de JavaScript también funciona en TypeScript, que es parte de esta aplicación. Toma tu código, lo analiza, lo compila en un formato de base de datos para que pueda ejecutar consultas en él. Y luego, en el caso de CodeQL, hay muchas consultas de código abierto que los investigadores han creado para CodeQL. Y ejecutará todas esas consultas en la base de datos que está indexada en función de tu aplicación. Y cualquier patrón de código que encuentre que indique una vulnerabilidad, lo informará. Y el conjunto de consultas para vulnerabilidades comunes está creciendo cada día. Este producto es gratuito para proyectos de investigación y de código abierto. Entonces, mientras lo hagamos, mientras lo hagamos en nuestro repositorio público, será gratuito en cualquier repositorio público. Si quieres usarlo para un repositorio privado, hay una tarifa. Y creo que es algo así como 21 dólares por usuario para la licencia de seguridad. Eso es para la licencia profesional que incluye seguridad. Con eso, nos pondremos manos a la obra, pero quiero hacer una pausa. Veo que hay mucha conversación en Discord.

Así que quiero ponerme al día con eso. Tienes un montón de solicitudes de extracción. Una pregunta rápida sobre Dependabot, ¿se pueden configurar los mensajes de commit para que se ajusten a nuestros registros de cambios automáticos si usamos commits convencionales, por ejemplo? Esa es una gran pregunta, Benjamin. No estoy seguro, pero tú... Esa es una gran pregunta, y lamento... pero no sé la respuesta a eso. Probablemente puedas editar el mensaje de la solicitud de extracción, pero no creo que eso sea lo que estás preguntando. Creo que estás preguntando sobre los mensajes de commit que activan procesos como obtener Opsi que harán cosas automáticamente. Lo cual es una gran pregunta. Genial. Ah, sí. Muy bien, Nick. Buen trabajo.

Muy bien, así que CodeQL. Nick y Benjamin están teniendo una gran conversación aquí. Genial. Y sobre intentos de que coincida con el formato de mensajes de commit anteriores. Eso es bastante ingenioso.

De acuerdo. Lo siguiente que quiero ver es CodeQL. Vamos a habilitarlo en este repositorio. Nuevamente, estoy en el repositorio Vuln GraphQL API, y es mi bifurcación de él. Entonces, nuevamente, vamos a ir a la pestaña de Security, y esta vez vamos a hacer clic en Alertas de Escaneo de Código. Vamos a hacer clic en ese botón que dice Configurar Escaneo de Código. Así que solo para asegurarnos de que todos estén conmigo, estás en tu repositorio de código, ve a la pestaña de Security, Configurar Escaneo de Código, y desde aquí, en realidad hay muchas opciones aquí para diferentes tipos de escaneo SAST, y vale la pena echarles un vistazo porque hay muchas buenas opciones. Y Sneak es realmente bueno. Stackhawk, también tenemos nuestra propia aplicación allí. En realidad, es para DAST, pero utiliza algunas de las herramientas de análisis estático para brindarte más información. Hay Systig y Barricode. No son tan buenos. SEMGREP, etc. Vamos a usar el incorporado, CodeQL Analysis, el primero de la lista. Así que solo haz clic en este botón, configura este flujo de trabajo, y esto creará un nuevo archivo de flujo de trabajo en tu repositorio. Así que está en el mismo directorio que el que configuramos nosotros mismos, el flujo de trabajo de compilación y prueba. Entonces está en .github/, workflows/, codeqlanalysis.yaml. Y esto funciona. No tienes que cambiar nada. Pero es bueno saber qué está haciendo porque para tu base de código, es posible que no funcione tan automáticamente como este. En general, he encontrado que ha sido realmente bueno, pero déjame explicar qué está haciendo. Así que configura un flujo de trabajo llamado codeQL, y se ejecutará cada vez que hagas push a la rama principal o hagas una solicitud de extracción a la rama principal. Además, se ejecutará una vez a la semana automáticamente independientemente de si haces push o no. Así que este es otro de esos desencadenantes que los flujos de trabajo de GitHub Actions pueden ejecutar según un horario. En él, hay una sola tarea llamada analyze. Creo que es solo una tarea, sí. Y se ejecuta en la última versión de Ubuntu disponible, y ejecuta una matriz. Entonces, si tuvieras varios lenguajes, esperemos que lo detecte, y ejecutará una matriz de compilaciones que básicamente ejecuta lo mismo en paralelo uno para cada lenguaje que encontró. Entonces, en nuestro caso, encontró JavaScript. Y solo va a hacer una matriz de uno. En esta tarea, hay un conjunto de pasos. Entonces vamos a clonar el repositorio como antes, vamos a inicializar CodeQL con tu lenguaje. Va a intentar compilar automáticamente tu aplicación, y finalmente, va a ejecutar el análisis en ella. Bastante simple, haz un commit de eso, y debería iniciar un nuevo flujo de trabajo. Este flujo de trabajo se ejecutará junto con nuestro flujo de trabajo original de compilación y prueba en paralelo. Entonces, si vas a Acciones ahora, deberías ver en Flujos de trabajo que ahora tienes, además de compilación y prueba, también tienes CodeQL. Puedes ver que ambos flujos de trabajo se están ejecutando actualmente en paralelo. Entonces, esperemos que el de compilación y prueba funcione igual que antes. Vamos a ver cómo va el de CodeQL. Así que haz clic en la matriz, y en mi caso, tengo Initialized CodeQL en ejecución, y de forma predeterminada, se ejecuta en paralelo. Así que vamos a ver cómo va. Y mientras esperamos que esto se ejecute, llevará un tiempo que se ejecute, echa un vistazo a Discord y avísanos si has llegado a la parte en la que has subido el archivo de análisis de CodeQL al repositorio. Genial. Vais más rápido que yo. Bien hecho.

La gente ya está recibiendo alertas de CodeQL. Aún no he recibido la mía. Pero estoy llegando al final de mis consultas, creo. Lo desactivaré. Veamos si ya estoy recibiendo alertas, aunque no esté completo. Aún no. ¿Ustedes ya las recibieron? Bien. Ahora hemos terminado. Y sí, mi pestaña de security tenía 11 alertas antes, y ahora tengo 13 y tengo dos alertas de análisis de código, como suena, la mayoría de las otras personas están obteniendo el mismo resultado. Haz clic aquí. Puedes ver que tenemos un par de problemas de alta gravedad, como aleatoriedad insegura y bloqueo de texto claro de información sensible. Así que haz clic en estos elementos y te dirá, `oye, usaste un valor aleatorio en un contexto de security que es criptográficamente inseguro. No deberías hacer eso`. Y probablemente tengan razón, pero encontraron esto en nuestro database seeder que simplemente genera una serie de usuarios aleatorios. Así que esto es parte de nuestra siembra de database, básicamente para más testing. Entonces, esto es algo que podrías marcar como un falso positivo, pero es un buen punto. Es un buen patrón que encontró. Y no sé, no creo que arreglaría esto para un seeder de pruebas, pero si estuviera en tu código principal, probablemente valdría la pena revisarlo. Echemos un vistazo al otro. Registro de texto claro de información sensible. Nuevamente, esto está en el seeder. Mientras creamos usuarios, queremos imprimirlo en un registro para que puedas ver qué usuarios hemos creado. Y lo interesante que ves aquí es que señala el archivo exacto y la línea exacta del archivo, e incluso los caracteres exactos del archivo con los que está preocupado. Y te brinda un poco más de información al respecto, te da algunas recomendaciones. Debido a que es específico del lenguaje, te brinda recomendaciones específicas del lenguaje para tu código. Y eso es una utilidad bastante útil, especialmente en tu repositorio de código abierto, porque es gratuito. Y si tienes repositorios privados, debes considerar si vale la pena pagar 21 dólares al mes por usuario, pero, pero esto, este no es un mal valor y es una utilidad bastante buena. Aunque creo que DAST generalmente es mejor porque encuentra más problemas y tiene menos falsos positivos. Aún así, creo que si, si el valor de esto es útil y simplemente tener una verificación cruzada con tus otros escáneres que están disponibles, siempre es bueno tener una variedad de escaneos en marcha. Así que eso es CodeQL. ¿Alguien tiene alguna pregunta sobre CodeQL o SAST en general en este punto?

Si no, creo que deberíamos tomar un descanso de cinco o diez minutos y regresar. Si alguien necesita ir al baño, yo sí. Pero les daré uno o dos minutos si tienen alguna pregunta. De acuerdo. Tenemos una pregunta. ¿Cuál sería el proceso recomendado para solucionar estos problemas, se pueden integrar en algo como JIRA? Para este caso en el que estamos registrando, debería darte una recomendación específica. Y no he leído esto detenidamente. Acabo de agregar esta herramienta a este taller y no me he adentrado lo suficiente en ella, pero básicamente probablemente recomendará, ya sabes, enmascararlo o enviarlo, o cifrarlo de alguna manera. Las credenciales deben estar cifradas, por ejemplo, utilizando el módulo de criptografía. Entonces, sí, te brindan una explicación bastante detallada sobre cómo abordar este problema aquí. Muy bien, ¿por qué no tomamos un descanso de cinco minutos, volvemos aquí a las 12:02 en nuestro horario? Así que en punto de la hora, más un par de minutos, tomemos un descanso rápido y volvamos de inmediato. ¿Les parece bien a todos? Un descanso de 10 minutos, trato hecho, Nick. Estoy contigo. Cuando regresemos, usaremos StackHawk. Así que nuestra próxima incursión, esta es la prueba final que vamos a agregar, vamos a agregar Pruebas de Seguridad de Aplicaciones Dinámicas (DAST), y vamos a usar StackHawk. StackHawk, hacemos un escáner lo suficientemente grande como para escanear una página. Porque sabemos que vamos a intentar escanear de vuelta al ADIF, necesitamos configurar una vista incorporada mientras escaneamos esa página.

Y esto se basa en el OWASP XAP de código abierto. De hecho, el fundador de OWASP XAP, Simon Bennetts, trabaja en StackHawk. Y prácticamente pasa todo el día trabajando en mejoras para OWASP XAP en sí. Y está trabajando en, ha estado trabajando en cosas del marco de automatización, y telemetría, y algunas mejoras realmente buenas para OWASP XAP. Así que definitivamente es una herramienta que vale la pena investigar.

Es excelente para las pruebas de penetración. También está mejorando para la automatización. Pero en StackHawk, lo que hemos hecho es, hemos tomado la utilidad OWASP XAP. Lo hemos empaquetado como un contenedor Docker. Y hemos agregado una simple configuración YAML para que sea realmente fácil automatizarlo. Uno de los problemas con XAP, y esto está mejorando, es que tiene archivos de configuración dispersos en varios lugares. Está diseñado principalmente para ejecutarse como una aplicación de escritorio. Y hemos intentado eliminar los aspectos de la aplicación de escritorio y simplemente darle un archivo de configuración YAML simple para que sea mucho más fácil integrarlo en el pipeline de CI/CD. Tenemos documentadas integraciones para muchas plataformas de CI/CD diferentes. Y tenemos una plataforma en línea en segundo plano para rastrear tus escaneos. A medida que ejecutas escaneos con StackHawk, los resultados se envían de vuelta a la plataforma de StackHawk para que puedas recopilar los datos allí y analizarlos en el futuro. Pero también para que podamos hacer otras cosas interesantes como enviar notificaciones a través de Slack o MS Teams, por ejemplo. Podemos integrarnos con Jira para un triaje en colaboración de los problemas que encuentra el escáner. Y tenemos soporte genérico para webhooks para que también puedas enviar datos de escaneo a otras plataformas en las que estés interesado que no admitimos directamente, pero que pueden recibir webhooks. Y hemos realizado muchas mejoras en el escaneo de GraphQL. Y me atrevo a decir que tenemos el mejor escáner de GraphQL entre las herramientas DAST debido a las modificaciones que hemos realizado en el rastreo de GraphQL para encontrar suficiente información y descubrir muchos problemas que existen, pero sin entrar en un bucle infinito de consultas de GraphQL. Y eso puede ser un equilibrio difícil de lograr.

Bien, al igual que Jira, ¿tiene integración con los problemas de GitHub? Esa es una excelente pregunta. No, no tenemos integración con los problemas de GitHub, pero es posible que puedas hacerlo con el soporte de webhooks. Muy bien, esto es lo que vamos a hacer. Permíteme revisar el manual rápidamente aquí. Estamos en el paso cuatro, Escaneo de Aplicaciones Dinámicas. Así que vamos a seguir adelante, vamos a crear una cuenta de StackHawk. Y en tu cuenta de StackHawk, al configurarla, se pasará por un pequeño asistente de inicio. Asistente de Inicio. Y el primer paso será crear una clave de API. Voy a tomar esa clave de API y guardarla en las Secrets de GitHub para que podamos usarla en nuestro pipeline más adelante. En el flujo de trabajo de inicio de StackHawk, también crearemos nuestra primera aplicación. Así que simplemente vamos a crear un nombre para la aplicación, y nos devolverá un UUID largo para identificar de manera única la aplicación que intentaremos escanear hoy. Y finalmente, vamos a comenzar a crear un archivo de configuración inicial para el escaneo de Hawk en tu aplicación. Este proceso de inicio realizará todo esto por nosotros. Así que comencemos, simplemente dirígete a app.stackhawk.com. StackHawk.com, lo que ves aquí, ingresa el nombre, en realidad lo llamaremos App.stackhawk.com. Eso es interesante. Ahí lo tienes. Así que ve a app.stackhawk.com y si aún no tienes una cuenta, perfecto. Vamos a registrarnos para obtener una cuenta nueva aquí. Si tienes credenciales o tus credenciales de Google, si quieres, simplemente puedes usar una dirección de correo electrónico y configurar tu propia contraseña. Tomará un poco más de tiempo porque debe verificar tu dirección de correo electrónico y todo eso. Así que tendrás un poco de ida y vuelta por correo electrónico, pero está bien, si quieres seguir ese camino, simplemente voy a usar Google y usar mi alter ego, mi alias z en econger.com. No me envíen spam, por favor. Ahora inicia sesión. Y esta es la pantalla de bienvenida. Voy a cambiar esto, para no perder la pista de en cuál estoy trabajando aquí.

Masterclass de ZConger.org. Y luego el resto es solo información básica. Mi foto de perfil, si se encuentra en Google, que no es acceso de terceros. Básicamente, solo dice: `oye, aquí están las credenciales de Google`. Haz clic en continuar. Y en la selección de tu plan, recomiendo que elijas el gratuito a menos que realmente quieras probar esto y potencialmente optar por el plan Pro. Pero con la cuenta gratuita para desarrolladores, puedes escanear una sola aplicación todo lo que quieras en cualquier número de entornos. Eso es lo que voy a usar para la demostración de hoy en la masterclass. Haz clic en continuar.

Y luego queremos escanear tu stack. Así que vamos a escanear nuestras propias aplicaciones. Elije esta opción en su lugar. Si quieres, puedes volver en otro momento y configurar un entorno de prueba de Google. Y eso simplemente carga un montón de datos de muestra para que puedas ver la plataforma sin tener que escanear tu propia aplicación. Pero escanear tu propia aplicación es lo que vamos a hacer. Así que elige tu stack, escanea por aplicación y haz clic en continuar. Así que dame un pulgar arriba en esta URL aquí si estás cerca de donde estoy en este flujo de creación de una nueva aplicación. Gracias.

Muy bien. Normalmente solo nombro la aplicación según el repositorio. Soy un tipo de Unirepo, no un modelo de repositorio, lo siento, un repositorio para cada aplicación. Así que llamaría a mi aplicación Vuln Graph QL API. Puedes llamarla como quieras. Los comandos de clave de API primero. Me pregunto por qué no obtuve un comando de clave de API primero. Entonces, lo que quiero que hagas si tienes los comandos de clave de API es obtener una copia de tu API. Sí, me pregunto por qué lo omití para mí porque eliminé esta cuenta. Esto podría ser un error donde recuerda mi antigua clave por alguna razón. Pero si estás viendo el flujo normal allí si te pide una clave de API primero. Adelante y recopila esa clave de API y guárdala en algún lugar. Y luego la guardaremos en las acciones de GitHub en breve. Así que genial. Y dale un pulgar arriba al comentario de Nick allí, guarda tu clave de API. Y Nick dice, y esto es cierto, si no guardas tu clave de API aquí, está bien, podemos crear otra clave de API, que es lo que voy a hacer. Así que te mostraré dónde podemos configurar una nueva clave de API en un momento.

Muy bien, ahora tienes tu clave de API guardada, y ahora deberías estar en esta página, detalles de la aplicación. Dale un nombre a tu aplicación, Vuln GraphQL, API es como yo la llamo, igual que el nombre del repositorio. Y luego, para el nombre del entorno, la idea aquí es que es posible que desees escanear esto en diferentes entornos, según las etapas y entornos y flujos por los que pasa tu proceso de CI/CD. Voy a usar desarrollo. Recomendamos que uses StackHawk en un entorno que no sea de producción. Así que desarrollo, preproducción, puesta en escena, QA, como quieras llamarlo, pero generalmente no producción porque intenta cambiar datos, lo que puede ser problemático para tu aplicación si cambia algo incorrecto, obviamente. Pero también puede llevar a resultados de escaneo inconsistentes si agrega datos y luego tiene más datos que escanea cada vez. De todos modos, seleccionaremos el entorno de desarrollo esta vez, y luego vamos a escanear la dirección local del host en el puerto 3000. Entonces, HTTP localhost dos puntos 3000, y eso es HTTP, no HTTPS, localhost dos puntos 3000. Haz clic en siguiente, y luego te pregunta qué tipo de aplicación tienes. Y en nuestro caso, tenemos una aplicación GraphQL, así que vamos a elegir API, o tipo de aplicación, y luego el tipo de API es GraphQL. Y luego lo predeterminado es correcto. Entonces, busca los puntos de introspección de GraphQL, para que pueda hacer preguntas sobre qué consultas puede realizar. Y en nuestro caso, tenemos la ruta predeterminada slash GraphQL. Y le daré a siguiente aquí.

De acuerdo. A partir de aquí, vamos a configurar un nuevo archivo de configuración stackhawk.yaml y lo vamos a descargar, voy a mostrar toda mi pantalla para que puedas ver lo que estoy haciendo. Voy a descargar este stackhawk.yaml, y lo voy a abrir, y lo abriré en Atom. Y como estamos trabajando solo en el navegador, recomendaría que copies y pegues esto en un archivo en tu repositorio.

¿El escaneo cambia algo dependiendo del entorno en el que se encuentre la aplicación? La producción satélite es más cuidadosa. Es una muy buena pregunta. Por defecto, no cambia realmente la naturaleza del escaneo dependiendo del entorno. Pero, si profundizas en StackHawk, puedes hacer alteraciones en este archivo. Puedes inyectar variables de entorno en este archivo. Así que si quieres que se comporte de manera diferente en un entorno de producción, puedes hacerlo. Por ejemplo, si realmente quieres ejecutar esto en un entorno de producción, una cosa que podrías hacer es simplemente decir, `oye, solo quiero ejecutar consultas aquí`, `no quiero ejecutar ninguna mutación que pueda cambiar mis datos`. Y podrías proporcionar eso en tiempo de compilación.

Cuando descargues tu archivo stackhawk.yaml, deberías ver algo como esto. Y lo único que debería ser diferente entre el tuyo y el mío es este ID de aplicación porque se mapea directamente a tu aplicación. Así que voy a tomar este archivo y lo copiaré y pegaré en un nuevo archivo en mi repositorio. Así que regresa a tu repositorio. Veamos, ¿dónde se fue el mío? Así que ve a la base de tu repositorio vuln-graphql-api en tu organización. Y vamos a crear un nuevo archivo en la base del repositorio. Y llámalo stackhawk.yml. stackhawk.yml. Pegaremos todos esos detalles que acabamos de copiar. Archivo de configuración stackhawk.yml que el flujo de inicio creó para ti. Aquí tenemos un ID de aplicación que se mapea a tu aplicación en la plataforma StackHawk. El entorno, y puedes cambiar el nombre de esto a cualquier cosa que desees. Cada vez que ejecutes un nuevo escaneo en un entorno diferente, se creará automáticamente en segundo plano. Vamos a escanear nuestra aplicación. Vamos a escanear Http localhost, dos puntos 3000. Y luego hay esta sección aquí que detalla la configuración específica de GraphQL. Por defecto, solo hay una araña web normal. Si solo agregaste estas cuatro líneas a tu archivo de configuración, tendrías un escaneo funcional que usaría una araña web normal similar a Google. Simplemente mirará tu archivo robots.txt en la base de tu aplicación web, y encontrará enlaces y seguirá esos enlaces y explorará tu aplicación de esa manera. Y luego verificará cada uno de esos caminos en busca de vulnerabilidades. Pero le estamos diciendo, `oye, tengo más información para ti que eso`. `Tengo una configuración de GraphQL`. `Y mi ruta de esquema o mi punto de introducción está en slash GraphQL`. `He habilitado GraphQL`. `Y quiero que ejecutes consultas y mutaciones`. `En otras palabras,` `quiero ejecutar todas las operaciones en mi base de datos`. También dice método de solicitud, get. Y recomiendo que cambies esto a post, y también se lo recomendaré a nuestros desarrolladores. Porque creo que la mayoría de las aplicaciones GraphQL suelen usar post, es mejor para consultas más largas si tienes consultas más largas. Y en el caso de esta aplicación, en realidad encuentra algunas cosas ligeramente diferentes. También tenemos Auto policy. Auto policy establecido en true. Lo que hace es que hay muchas cosas como políticas de escaneo Zap en segundo plano que puedes ajustar y configurar. Y básicamente hemos hecho un montón de ajustes y configuraciones automáticas porque esta es una aplicación GraphQL. Para Auto input vectors, esto se supone que, si lo dejas en blanco, probablemente elegiría post para la mayoría de sus vectores de entrada a medida que intenta hacer consultas a GraphQL. Así que lo que deberías obtener es exactamente lo que pegaste, excepto cambiar el método de solicitud de get a post. Y avísanos si estás con nosotros hasta aquí. Voy a hacer commit de este cambio. De acuerdo.

Y nuevamente, ese archivo es stackhawk.yml. Y deberías ver que se ejecutará code QL y se construirá y probará nuevamente, pero aún no le hemos dicho que necesita ejecutar StackHawk. O el escáner, lo llamamos Hawkskin, por cierto. Así que diré Hawkskin y StackHawk, son un poco intercambiables. De todos modos, aún no le hemos dicho que ejecute Hawkskin, por lo que en realidad no producirá resultados todavía, pero eso es lo siguiente que haremos.

Entonces vamos a volver a GitHub Workflows. Vamos a encontrar este archivo build and test.yml. Y lo vamos a editar para agregar una línea para ejecutar la aplicación para que esté disponible para el escaneo y luego escanear la aplicación con Hawkskin. Muy bien, así que estoy en el archivo build and test.yml. Voy a hacer clic en este lápiz para poder editarlo. Voy a agregar un par de líneas aquí. Primera línea, ejecutar la aplicación. Ejecutar docker-compose up detach. Entonces nuestro archivo docker-compose explica cómo construir esta aplicación en un contenedor de Docker y también explica cómo ejecutar la aplicación y escuchar en el puerto correcto. Así que vamos a hacer eso para levantar la aplicación y luego usaremos esta bandera --detach para dejarla ejecutándose en segundo plano. Y de esa manera podemos pasar al siguiente paso en el trabajo y dejar esa aplicación ejecutándose. El siguiente paso será ejecutar HoxScan para escanear la aplicación. Y vamos a usar, así que usamos esta palabra clave uses, Stack Hawk slash HoxScan Action en la versión V1.3.2 es la versión actual. Vamos a usar la clave de API que ingresaste, excepto que aún no la has ingresado. Oh querido. Así que voy a ingresar esto y este trabajo va a fallar. Pero de todos modos, vamos a ingresar estos detalles. Tengo un pequeño problema de flujo porque no hice mi clave de API. Así que vamos a ingresar, esto eventualmente estará en el alijo secreto. Así que pondremos esto en, hock underscore API underscore key. Te mostraré a qué se refiere eso en un minuto. Así que todo esto debería funcionar tan pronto como obtengamos ese secreto allí. Así que voy a seguir adelante y hacer commit de este archivo. Ahí lo tienes. Y deberías tener, todo esto también se detalla en la guía del masterclass, si quieres consultarlo. Y Nick ha ingresado los pasos adicionales en Discord también. Así que simplemente puedes copiar y pegar esos.

De acuerdo, probablemente ahora tienes una acción en ejecución que tiene este cambio y probablemente fallará en el paso de escaneo de Hawkskin porque no agregamos ese secreto. Así que vamos a dirigirnos al alijo de secretos. Entonces, en tu repositorio, ve a la pestaña de configuración y luego aquí a la izquierda, ve a secretos. Y aquí es donde vamos a agregar nuestros secretos. Antes de hacer clic en este botón, vuelve a donde guardaste tu clave de API, copia la clave de API. Debería comenzar con hock.un montón de números. un montón más números. Si no tienes eso guardado en algún lugar, podemos crear otro ahora mismo. Lo cual es lo que voy a hacer. Así que voy a ir a tu nombre de usuario y configuración y voy a API keys. Y sí, estas son claves de API antiguas de organizaciones anteriores que he configurado. Así que esto es algo de lo que alertaré a nuestros desarrolladores. Así que voy a crear una nueva clave de API, workshop V2. Continúas. Luego puedo copiar esa clave. Comienza con un Hawk. Un montón de letras y números, un montón más de letras y números. Voy a copiar eso en mi portapapeles.

Regresa a los secretos de acciones. Y nuevamente, esto está en la pestaña de configuración y secretos. Crearé un nuevo secreto de repositorio. Llámalo Hawk_API_key para que coincida con lo que pusimos en nuestro archivo de flujo de trabajo y simplemente pega el valor de la clave y haz clic en agregar secreto. Muy bien. Ahora eso debería coincidir con lo que hemos agregado al flujo de trabajo. build and test.yaml. Hawk_API_key. Ahora voy a hacer un cambio menor. Solo voy a modificar este archivo. Lo editaré y simplemente eliminaré esta línea en blanco. Tal vez agregaré otra línea que diga tickle solo para crear un cambio que active otro flujo de trabajo. Así que haz esto y eso activará otra ejecución de acciones. Y vayamos a acciones. Aquí está el anterior y el mío falló, probablemente el tuyo también si aún no has ingresado tu clave de API secreta. Y si hago clic en él, solo verificaré. Debería haber fallado en el paso de escaneo de Hawk. Y hay un mensaje en la consola que dice, error, la clave de API proporcionada no es válida, básicamente porque no hay una clave de API que hayamos proporcionado. Y no pudo autenticarse en la plataforma de StackHawk. Ahora volvamos y vayamos a nuestro trabajo actual que se está ejecutando. Busca, en todos los flujos de trabajo, ve a construir y probar, y selecciona el más reciente que se está ejecutando, y haz clic en él y observemos cómo se construye. Para mí, actualmente está construyendo la aplicación. Y eso puede llevar un tiempo, unos minutos tal vez. Y ejecutará la aplicación, que funcionó la última vez. Así que creo que el paso de ejecutar la aplicación funcionará, y luego deberíamos llegar al paso de escaneo de Hawk.

¡Hola, chicos! Mi nombre es Nick. Si has llegado hasta este punto, tienes un nuevo flujo de trabajo de acciones en ejecución. Revisa el último comentario de Nick y dale un pulgar arriba. Si has ajustado esta parte donde tienes un nuevo flujo de trabajo en ejecución, tienes tu clave de API de escaneo de Hawk guardada como un secreto, y esto se ha iniciado. Y esto, nuevamente, es una prueba. Tengo otro en el que estoy trabajando. Quiero asegurarme de que lo estemos haciendo bien, para poder hacerlo bien. Así que sé que hay un error. Pero solo quiero asegurarme de que estemos configurando los ajustes correctamente. Y planeo hacer uno para agosto. Si aún no has hecho uno, espero poder participar más adelante. Pero si ya lo hiciste, me aseguraré de leer las notas y luego escucharemos tus comentarios, pero planeo hacer uno para agosto.

De acuerdo, y esto llevará un tiempo. Mientras se está construyendo el mío, a veces solo construir la sección de la aplicación lleva demasiado tiempo, y no estoy seguro de por qué. Pero esperemos a que se ejecute. Ustedes pueden dejar que el suyo se ejecute, y si tienen algún error, avísenos. Podemos comenzar a solucionar esos problemas. De acuerdo, así que esperemos ese cálculo. Mahindra, esa es una buena pregunta. Así que está obteniendo toda la información. Está buscando toda esa información a través del punto final de introspección de graphQL, donde puedes exponer qué datos están disponibles, qué tipos de consultas están disponibles. Y por defecto, muchas bibliotecas, como express, exponen mucha información de forma predeterminada. Por lo tanto, hay mucha información para que el escáner la utilice en general. De hecho, es una buena idea curar el punto final de graphQL y qué metadatos están disponibles para dar pistas a las personas sobre qué se puede consultar en tu base de datos. Pero por defecto, muchas de las bibliotecas y módulos que podrías usar para crear un punto final de graphQL proporcionarán mucha información detallada de forma predeterminada. Y eso es lo que estamos utilizando. Así que si vuelvo a la sección de escaneos, puedo ver que mi escaneo ha comenzado, lo cual es genial. Entonces podemos ver que se está ejecutando el escaneo de Hawk para escanear la aplicación. Y como aparece para mí como que ha comenzado desde la sección de escaneo del sitio web de StackHawk, puedo decir que la clave de API debe haber funcionado. Entonces, si hago clic aquí, me mostrará detalles sobre dónde se encuentra hasta ahora. Tenemos una barra de progreso. Se está escaneando, ha estado escaneando durante aproximadamente un minuto. Hasta ahora ha encontrado 14 problemas de alta gravedad, 39 de gravedad media y ninguno de baja gravedad. Hice clic en la pestaña de resumen del complemento. También hay una pestaña de hallazgos y rutas. En el resumen del complemento, me muestra: `Oye, aquí hay algunos de los complementos que tengo y esto es lo que he completado hasta ahora. Puedes ver que hay muchas categorías generales y dentro de estas grandes categorías generales de complementos, quiero decir, son complementos reales, pero cada complemento en realidad tiene generalmente un conjunto bastante grande de pruebas que se ejecutan. En hallazgos, me da un resumen de los hallazgos que ha encontrado. Así que hemos encontrado un error de inyección SQL, inyección remota de comandos del sistema operativo. Estos son problemas de alta gravedad y suenan bastante mal y lo son. Configuración de dominio cruzado, escáner de CSP, dirección comodín. Estos comienzan a ser un poco más esotéricos y aún así realmente falsos. Más esotéricos y aún así definitivamente vale la pena investigar. Y luego hay un montón de problemas de baja gravedad a los que deberías echar un vistazo si tienes tiempo, pero son más fáciles de posponer. Hagamos clic en uno de ellos. Este es mi favorito. Lo que hizo fue encontrar a través de la introspección que hay una mutación llamada super-secret-private mutation. Por supuesto, se expuso a través de la introspección porque eso es lo que hacen muchas de las bibliotecas estándar. Pero envió esta mutación y envió esta variable. Básicamente, lo que está haciendo es enviar un comando, caca, y luego cat Etsy password.

Y así, la solicitud, esa es la solicitud que se hizo. Y luego la respuesta que se obtuvo fue el archivo de contraseñas de Etsy. Así que cat Etsy password funcionó. Y eso es una ejecución de comando arbitrario. Es un error terrible, terrible. Y por eso se llama un problema de alta gravedad. Pero lo que puedes ver de esto es que tienes muchos detalles para cada uno de estos problemas que se encontraron, incluyendo algunos detalles sobre cómo remediar el problema. Sabes, un poco más sobre este problema, y luego una hoja de trucos completa a la que puedes acceder que te dice cómo prevenir este tipo de cosas.

Entonces, esto está enlazando a un artículo de blog para Python, pero los detalles que hemos incluido aquí, aunque son específicos para Python, son información general útil sobre cómo solucionar un error de ejecución remota de comandos del sistema operativo. Así que estás obteniendo mucho material de referencia en el que puedes trabajar. También tienes, aquí tienes la solicitud, la solicitud específica que hicimos que indicaba que podría haber un problema, y luego la respuesta que recibimos de la aplicación que indicaba que hay un problema. Y aquí hay un botón de validación, que te proporciona un comando curl que puedes usar para ejecutar la misma consulta exacta contra tu aplicación, si la tienes en ejecución y disponible en tu estación de trabajo.

Para ustedes, porque no tienen una, a menos que lo hayan hecho, probablemente no hayan descargado la aplicación y la hayan ejecutado localmente. Y por eso estoy ejecutándola localmente, para poder demostrar que el botón de validación realmente funciona. Así que hago clic en validar, pego la ruta. Hago clic en validar, copio esto al portapapeles, y luego lo pego. Así que estamos pegando el comando curl, estamos haciendo un post. Y estamos enviando esta mutación y variable, y luego presionamos enter y obtenemos la misma respuesta, obtenemos el contenido del archivo de contraseñas de Etsy, lo cual es la evidencia de que tenemos un error de ejecución remota del sistema operativo. Y finalmente, en esta página, y acepto preguntas. Puedes ver que esto se encontró en una ruta específica llamada mutación. Si tienes rutas de API normales, eso es lo que se mostrará aquí. Así que es posible que encuentres este tipo de problema en varias rutas en una API normal. Y así tendríamos una lista de rutas aquí, pero básicamente lo que mostramos aquí es, lo tengo ampliado tanto que no se muestra muy bien. Pero para cada una de estas rutas, dice, o se ha asignado a nadie. No lo hemos marcado como un falso positivo. No lo hemos aceptado. Y no lo hemos asignado a nadie. Pero lo que podemos hacer desde aquí es marcarlo como un falso positivo o aceptar el riesgo o asignarlo. Y ahora no tengo la integración configurada pero la integración con Jira es realmente poderosa. Así que si esto fuera una integración con Jira, lo que verías aquí es que podrías seleccionar a qué proyecto de Jira quieres agregar el ticket. No tienen todos estos detalles completados para crear un nuevo ticket, incluyendo un enlace a estos resultados de escaneo, un resumen de todos los resultados de escaneo. Entonces, ¿cuál es la mutación? ¿Cuáles son las variables que se envían con la mutación? ¿Cuáles son algunos de estos, cuál es la hoja de trucos a la que enlazas para obtener más detalles al respecto? Y así sucesivamente. Así que si juegas con esto, definitivamente vale la pena probar la integración con Jira. Y te mostraré, déjame retroceder y mostrarte otro, otro registro. Así que creo que la inyección de código entre sitios reflejada... si hago clic en eso... Olvidé algunos de estos. Así que si hago clic en la página de inyección de código entre sitios, oh, también hay una mutación. Aquí vamos. Esto es lo que encontrarías con una API normal que no es realmente GraphQL. Encontrarías todas las rutas en las que se encontraron estos problemas. Así que lo encontramos en la ruta raíz, así como en varias mutaciones y consultas. Cookie sin atributo same site. Y nuevamente, cada uno de estos, puedes seleccionar todos ellos y decir, hey, quiero asignar todos estos a otro ticket o a otro desarrollador a través de JIRA. Permíteme, quiero mostrarte, veamos, quiero mostrarte un ejemplo de lo que quiero decir con la integración de JIRA solo para que puedas tener una mejor idea. Creo que lo tengo configurado en mi propia cuenta. Así que yendo detrás de escenas aquí un poco. Si tomara a este chico y lo asignara, ampliara esto para socializarlo un poco mejor, así que podría hacer clic, creo que tengo esta integración con JIRA, enviar a JIRA, y aquí está el tipo de detalle que obtendrías. Así que puedes seleccionar el proyecto al que quieres enviar esto en JIRA, resumen, buen detalle, título, descripción, criticidad, ruta y luego un enlace de regreso a esta página para que puedas ver todos los detalles incluyendo la evidencia que encontraste. Incluyendo la evidencia que encontraste.

Página 27. Y ahí está. Así que obtienes algunos detalles buenos aquí y un enlace de regreso a los resultados del escaneo. Muy bien. Entonces, en pocas palabras, esos son los resultados de StackHawk. Y déjame mostrarte, te voy a dar un poco más de un recorrido de lo que más hay aquí. A medida que realices más escaneos, verás más resultados de escaneo filtrados aquí. Verás un pequeño resumen a medida que avanzas. Y a medida que comiences a clasificar las cosas, este resultado de escaneo inicialmente tenía dos resultados de alta gravedad, y acabamos de clasificar uno. Así que ahora tiene un nuevo resultado de alta gravedad y uno clasificado. Y esto entra en juego más adelante, si quieres, por defecto, StackHawk nunca interrumpirá tu compilación, pero si quieres, puedes establecer un umbral que diga, hey, si veo algún problema de alta gravedad, interrumpe la compilación, falla, para que el proceso se detenga. Pero si clasificas esos problemas, ya no contarán en tu contra. Así que ese es un patrón bastante común con StackHawk, obtienes un nuevo problema de alta gravedad, lo clasificas, y luego tus compilaciones volverán a funcionar. Luego, en la sección de aplicaciones, tenemos, tendremos un conjunto de tarjetas. Así que cada aplicación como vulnerabilities graph QL API tiene una tarjeta para cada entorno. Hasta ahora, solo tenemos el entorno de desarrollo. Y te muestra este gráfico de barras. Y si continuamos ejecutando escaneos, verás esta barra repetida una y otra vez. Y a medida que resuelvas problemas, esperemos que tus alertas amarillas, verdes y rojas disminuyan con cada escaneo para que tengas una indicación visual de cómo estás resolviendo tus errores. Y también verás problemas que están clasificados como una barra gris que desciende por debajo de esta línea.

Tengo una pregunta. ¿Existe alguna forma de configurar una autenticación de inicio de sesión antes de escanear la aplicación? Excelente pregunta. Y Nick proporcionó un enlace para el escaneo autenticado. Ese es un tema muy importante porque la mayoría de las aplicaciones GraphQL y las API más importantes suelen tener secciones autenticadas. Y sí, tenemos una serie de guías muy detalladas sobre cómo configurar una autenticación antes de escanear la aplicación. Cómo configurar una autenticación para poder acceder a cualquiera de ellas. Y también hemos estado trabajando en características adicionales para eso también.

Permítanme pasar a las integraciones.

Quiero abrir el piso para preguntas en este punto, porque esto es lo que hemos tenido y estoy muy satisfecho con el tiempo que ha llevado. Estamos casi en la hora en punto. Así que si alguien tiene preguntas, quiero asegurarme de que puedan hacerlas antes de pasar al siguiente taller. Una pregunta que a veces nos hacen es, ¿cuál es el siguiente paso? ¿A dónde irías desde aquí? Y diría, prueba estas herramientas en tus propias aplicaciones. Si tienes un proyecto personal, ese es un buen lugar para comenzar o si tienes un proyecto de trabajo, todas estas herramientas son realmente útiles para eso. CodeQL nuevamente tiene un precio para cualquier número de aplicaciones si está en un repositorio privado. Pero las demás son gratuitas. GitHub Actions es gratuito durante 2000 minutos, StackHawk es gratuito para una aplicación. Pruébalo y ve cómo funciona en tus aplicaciones y ve qué encuentras. También puedes revisar los PR que Dependabot creó y los problemas que CodeQL encontró y ver si puedes encontrar soluciones para ellos. Tengo una pregunta aquí, si GitHub Actions tiene un límite de seis horas por trabajo, ¿qué sucede si tu escaneo lleva más tiempo que eso? ¿Hay otras opciones? Es una buena pregunta. No sé si nos hemos encontrado con muchos escaneos que lleven seis horas, pero en realidad tenemos una buena publicación en el blog sobre cómo mitigar los escaneos largos. Nick, ¿puedes ver si puedes encontrar eso? Creo que es una publicación bastante reciente. Oh, rápido en la búsqueda. Oh sí. ¿Puedes ver si puedes encontrar la publicación en el blog de StackHawk sobre... Básicamente se trata de cómo mitigar los escaneos largos. Pero hay varias opciones. Puedes dividir el escaneo en partes, por lo que GraphQL podría ser un componente único. Puedes limitar el rastreo.

Hay muchas opciones de ajuste que puedes hacer con StackHawk para limitar el rastreo y las rutas que estás verificando. Puedes dividirlo en componentes y ejecutar varios componentes en paralelo. Esa es generalmente la forma en que lo abordaría si tienes una aplicación realmente grande.

Aquí vamos. De acuerdo. Excelente sugerencia, Benjamin. Benjamin sugiere realizar un escaneo para mutaciones y otro escaneo para consultas. Es una muy buena idea. Otra opción, como, depende también de los pipelines que uses. No todos están utilizando GitHub Actions, y si profundizas en GitHub Actions, he visto a mucha gente optar por ejecutores autohospedados, y puedes ejecutar los ejecutores en AWS, por ejemplo. Así que, no necesariamente tienes que ejecutarlo localmente. Puedes ejecutarlo en AWS o en cualquier otro lugar. Y allí no tienes los mismos límites de tiempo. No tienes las mismas restricciones de recursos que tienes en GitHub Actions.

Entonces, sí, al probarlo en tu aplicación, lo siguiente que debes verificar, o lo siguiente que debes hacer para que brille realmente, es ese paso de autenticación. Normalmente eso le brinda al escáner un acceso mucho más profundo. Es realmente útil cuando realizas escaneos DAST para sembrar los datos y siempre comenzar con el mismo conjunto consistente de datos cada vez que ejecutes el escaneo, especialmente si estás realizando mutaciones, porque al hacer mutaciones o cambiar los datos, cambiarás la naturaleza de los resultados del escaneo al final. Voy a quedarme un rato y seguir respondiendo preguntas a medida que lleguen.

Espero que todos hayan obtenido algo de esto. Espero que todos hayan obtenido algo de esto. Y espero que hayan aprendido algunas cosas que puedan aplicar en sus propias aplicaciones, ya sea para el trabajo o para sus proyectos personales. Y siempre estamos disponibles. Si pruebas la versión gratuita de StackHawk, puedes enviarnos correos electrónicos a [email protected] y te responderemos. Realmente nos enorgullece brindar un buen soporte al cliente, incluso si solo estás utilizando el plan gratuito. Oh sí, y Nick menciona, también tenemos un canal de Discord. Puedes hacernos preguntas allí. Únete. Oh, eso es genial. Magna Logan, utilizas StackHawk en tu entrenamiento de DevSecOps. ¿Dónde aprendiste por primera vez sobre StackHawk? ¿Es este un curso que utiliza StackHawk? Eso es increíble. Muy bien. Bueno, muchas gracias a todos. Me alegra mucho que todos pudieran seguirlo. Parece que obtuvimos resultados muy consistentes. Realmente apreciamos que estén aquí y se tomen el tiempo. Y estén atentos a StackHawk, pruébenlo. Prueben esas otras herramientas también. También echen un vistazo a Snyk. Quiero mencionarlos, porque realmente tienen excelentes utilidades de SCA y SAST, muy fáciles de usar también. Definitivamente vale la pena echarles un vistazo. Ambos son realmente, realmente fáciles de usar. Y muchas gracias a todos. Cuídense. Voy a desconectarme ahora. Pero si tienen alguna pregunta adicional, únanse a nuestro canal de Discord de StackHawk y las responderemos allí. Hasta luego.