 Hola, soy Ricardo Amarilla, Técnica la COUN MANAGER PARAQUITA, y hoy vamos a hablar acerca de DevSecOps en español. Aquí tenemos un pipeline de GitLab, que contiene varias etapas o stages. Tenemos la Tapa Build, que construye la aplicación, la colocan contenedores y la publica en el registro de contenedores. Luego tenemos la Tapa de TES, que ejecutan TES unitarios, así como una variedad de diferentes escaneos de seguridad. Estos Scanners incluyen prueba de seguridad de aplicaciones estáticas, SAS, por sus siglas en inglés, en búsqueda por vulnerabilidades en el código estático. Scanner de contenedores, que busca vulnerabilidades en las imágenes del contenedor. Análisis de dependencias, que busca vulnerabilidades en versiones de archivos de dependencias. El Scanner de Licencia analiza las licencias que funcionan las políticas aprobadas o denegadas que podemos configurar en el repositorio. Por último, tenemos la Detección de Secretos, en búsqueda del password y tokens que pueden haberse incluido accidentalmente en el repositorio. Luego tenemos la Tapa de Implementación o Diploid, que implementa nuestro código en un entorno de código. Luego de implementarlo, ejecuta un análisis dinámico de seguridad de aplicaciones que envía solicitudes maliciosas a una aplicación para detectar vulnerabilidades. Por sus siglas en inglés, lo denominamos SAS. Todos los análisis de seguridad se ejecutan en una rama Feature Branch y encuentran vulnerabilidades antes de que los cambios envíen a la rama master. Estos análisis pueden ser configurados en un archivo KIPLA-CI YEMO file o por medio de auto DevOps. Ahora echemos un vistazo a un Merge Request. Aquí podemos ver que en este Merge Request tiene la configuración de aprobaciones. Vulnerability check significa que si se detectan vulnerabilidades de cierta gravedad, se requiere una aprobación antes de que se pueda realizar el Merge. También hay una verificación de licencias que requiere aprobación si se detecta una licencia no permitida. Estas comprobaciones se pueden configurar en la sección general de la configuración del proyecto. Ahora veamos el resultado de los escáneres de seguridad. Aquí tenemos un ejemplo de una vulnerabilidad SAS. Contiene información detallada sobre la vulnerabilidad, su gravedad, su ubicación y cómo resolverla. Para iniciar una conversación sobre la vulnerabilidad se puede crear un Issue Confidencial sin evadir la vulnerabilidad. Esto permite a los desarrolladores y el equipo de seguridad a colaborar a encontrar una solución. También se puede crear un Merge Request Confidencial que solo permita la visibilidad a aquellos compromisos. Se realiza un seguimiento de los cambios de los Issues Abiertos, lo cual es excelente para los registros de auditoría y de complayas. Luego tenemos las vulnerabilidades SAS, que muestra información de las solicitudes recibidas y enviadas junto con enlaces relevantes de la vulnerabilidad. Si un desarrollador considera que esta no es válida puede descartarla con un comentario. Esta información es rastreada y puede ser vista por el equipo de seguridad. También existe un tipo de escaneo de licencias que detectó una nueva licencia. Un miembro del equipo de seguridad puede agregar la licencia a la política de licencias denegadas y evitará que se confirme el Merge Request a menos que se obtenga una aprobación. Hola, soy Fernando, Technical Marketing Manager aquí en KITLAT y ahora vamos a ver el dashboard de seguridad y los reportes sobre vulnerabilidad. El equipo de seguridad también puede colaborar con una visibilidad general completa de todas las vulnerabilidades dentro de un proyecto o grupo de proyectos. Los profesionales de seguridad utilizan el Security Dashboard o Panet de Seguridad en español para obtener una visión general de alto nivel de todas las vulnerabilidades detectadas lo que les permite ver el estado de los problemas de seguridad detectados. Ahora vamos a ver el reporte de vulnerabilidad. Pueden clasificar todas las vulnerabilidades y determinar su estado, gravedad y cuál fue el scanner que lo detectó. Vamos a seleccionar SAST y DAST y ver las vulnerabilidades que detectó. Al hacer click en una vulnerabilidad un miembro de equipo de seguridad no solo ve la información detallada sobre la vulnerabilidad sino que puedes cambiar su estado para confirmar, descartar o resolvería. Este cambio se registra para permitir una auditoria. El reporte de vulnerabilidad también se puede ver en clase de grupos. Aquí también podemos clasificar por proyecto.