Jan 01, 1970
Cómo convertir una canalización de DevOps en una canalización de DevSecOps: una descripción general del concepto de cambio a la izquierda por@goal23
11,152 lecturas
Cómo convertir una canalización de DevOps en una canalización de DevSecOps: una descripción general del concepto de cambio a la izquierda
Demasiado Largo; Para Leer
Le expliqué qué es el concepto Shift Left y cómo ayuda a reducir el costo de la corrección de errores y el tiempo de desarrollo: cuanto antes en el proceso de desarrollo inicie las comprobaciones de seguridad, mejor. Luego, deconstruí la estructura de DevSecOps Pipeline y observé qué controles de seguridad se realizan en cada etapa del Pipeline.¡Hola HackerNoon! Mi nombre es Sofia y soy ingeniera de DevOps/Cloud. Decidí participar en el concurso de HackerNoon y Aptible.
En este artículo, hablaré sobre las características del proceso DevSecOps y el concepto de Shift Left. Aprenderá sobre las etapas principales del proceso de DevSecOps, los controles de seguridad automatizados en el desarrollo de software y las herramientas gratuitas y de código abierto. También encontrará consejos que le ayudarán a detectar vulnerabilidades antes y mejorar la seguridad de las aplicaciones.
Este artículo le ayudará a evaluar la madurez de su proceso de DevSecOps, desarrollar una hoja de ruta para su desarrollo, elegir las herramientas adecuadas para cada tarea y comprender mejor cómo gestionar proyectos siguiendo la filosofía DevSecOps.
Concepto de desplazamiento a la izquierda
El objetivo principal de la metodología DevSecOps es introducir controles de seguridad automatizados en los procesos de DevOps, es decir, en el propio proceso de desarrollo de software.
No hace mucho, los especialistas en seguridad de la información realizaron pruebas después de completar el proceso de desarrollo. Este enfoque es ineficiente: si se descubren errores durante las pruebas de seguridad, se debe reiniciar todo el ciclo de desarrollo. Esto requiere mucho tiempo y es costoso.
Hecha un vistazo a la imagen de abajo. Puede ver que el costo de la corrección de errores aumenta con cada paso.
No cuesta casi nada solucionar los problemas de seguridad descubiertos durante el desarrollo y las pruebas funcionales. Todos los cambios necesarios se pueden realizar en el código fuente inmediatamente y enviarlos para su nueva verificación.
Solucionar problemas en la etapa de construcción de artefactos es al menos el doble de caro. Tendrá que realizar cambios en el proceso de compilación, por ejemplo, editar el Dockerfile, lo que significa que necesitará la ayuda de ingenieros de DevOps.
Si se detecta un error durante las pruebas de integración, solucionarlo será 10 veces más caro. En este caso, debes reiniciar el ciclo de desarrollo e involucrar a desarrolladores, ingenieros de DevOps y evaluadores.
Los problemas de seguridad detectados en la etapa de implementación pueden provocar fugas de datos de los usuarios. La empresa puede recibir millones de dólares en multas y daños a su reputación, lo que significa que el coste de un error aumenta cientos de veces.
Por tanto, la principal conclusión es que los controles de seguridad deben realizarse lo antes posible. Si lo visualizas, muévelos al lado izquierdo del Pipeline. Este es el concepto de Shift Left, del que tanto les encanta hablar a los expertos en seguridad.
Estructura de canalización de DevSecOps
Los canales de DevSecOps son una cadena automatizada de procesos y herramientas que crean, prueban y entregan aplicaciones en un entorno de producción y las protegen en cada etapa.
La imagen de arriba muestra la estructura de DevSecOps Pipeline con todas las fases principales de los controles de seguridad. Aquí hay algunas palabras sobre cada uno de ellos:
- Pre cometido. Implica verificar la seguridad del código fuente antes de que el desarrollador envíe el código al sistema de control de versiones. Esta verificación le permite detectar información confidencial no cifrada, como contraseñas o claves API.
- Preconstrucción. Implica verificar la seguridad del código fuente después de que haya ingresado al sistema de control de versiones. Las herramientas realizan análisis estáticos del código fuente y sus dependencias para detectar vulnerabilidades comunes, como muchas de las
Los diez mejores de OWASP lista.
- Post-construcción. Es la verificación de seguridad de un artefacto creado a partir del código fuente, como un archivo Docker, un paquete RPM o un archivo JAR. Las herramientas analizan el entorno de la aplicación y las dependencias, encontrando versiones obsoletas de paquetes y bibliotecas que ya tienen parches en versiones más nuevas.
- Tiempo de prueba. Implica probar la seguridad de una aplicación que se ejecuta desde un artefacto recopilado. Las herramientas de esta fase intentan "romper" la aplicación simulando las acciones de los atacantes.
- Post-implementación. Implica comprobar la seguridad de una aplicación después de haber sido implementada en un entorno de producción. Las herramientas monitorean los registros abiertos de vulnerabilidades conocidas en tiempo real y notifican cuando se detecta una amenaza a la aplicación.
A continuación, echemos un vistazo más de cerca a qué son estas comprobaciones y qué herramientas se utilizan para realizarlas.
Comprobaciones previas al compromiso
Las comprobaciones previas a la confirmación le permiten analizar el código fuente en la máquina del desarrollador antes de confirmar los cambios en la copia local del repositorio. Si alguna de las declaraciones devuelve un error, no se realiza la confirmación. En este caso, el desarrollador debe corregir el error y volver a cometerlo.
Esta verificación evita la situación en la que código no verificado, por ejemplo, con secretos no cifrados, ingresa al repositorio.
Para realizar comprobaciones del código fuente previas a la confirmación, es necesario instalar herramientas en las máquinas locales de los desarrolladores. Este enfoque no sólo tiene ventajas sino también desventajas. Por ejemplo, las diferencias ambientales: diferentes versiones de los instrumentos, distintos sistemas operativos e incluso arquitecturas de procesador.
Si los desarrolladores utilizan diferentes versiones de herramientas de confirmación previa, los resultados de la verificación serán diferentes y esto puede dificultar el trabajo conjunto. Considere esto al implementar controles previos al compromiso dentro de un equipo o en toda la empresa.
Herramientas para comprobaciones previas al compromiso
Se pueden utilizar muchas herramientas de código abierto para configurar comprobaciones previas a la confirmación:
gitleaks secretos de git Escaneo secreto de Trivy susurros git-todos-secretos detectar-secretos fugas importantes
Estas son excelentes herramientas para verificaciones previas al compromiso.
Comprobaciones previas a la construcción
En la fase previa a la construcción, se realiza la prueba de caja blanca. Estas comprobaciones se utilizan para analizar el código fuente, como en el paso anterior. En este caso, la aplicación es una "caja blanca" porque conocemos y entendemos su arquitectura y estructura interna.
Existen varios tipos de comprobaciones previas a la compilación:
- Detección secreta
- Pruebas de seguridad de aplicaciones estáticas (SAST)
- Análisis de composición de software (SCA)
Ahora, analicémoslos en detalle.
Comprobación de detección de secretos previa a la compilación
La detección de secretos es una verificación automatizada que detecta información confidencial no cifrada: secretos no cifrados en el código fuente que han ingresado a un sistema de control de versiones.
Las comprobaciones previas a la compilación se realizan después de que el código fuente haya ingresado al repositorio del sistema de control de versiones. Por lo tanto, los atacantes pueden acceder a todos los datos confidenciales no cifrados en el almacenamiento, por ejemplo, si se filtra el contenido del repositorio.
Además, el proceso de implementación de controles de detección de secretos puede ocurrir no desde cero sino como parte de un proyecto en evolución. En este caso, es posible que se encuentren secretos no cifrados en confirmaciones antiguas y en diferentes ramas del repositorio.
Para resolver estos problemas, necesitamos hacer muchas cosas diferentes. Por ejemplo, debemos limpiar repositorios de secretos no cifrados o implementar diversas herramientas de gestión de secretos como Hashicorp Vault .
Herramientas para la detección de secretos
La detección secreta se puede configurar usando
Comprobación SAST previa a la compilación
La prueba de seguridad de aplicaciones estáticas (SAST) es una prueba en la que los analizadores no solo verifican la corrección sintáctica sino que también miden la calidad del código con la ayuda de métricas únicas. La tarea principal de los escáneres SAST son las pruebas de seguridad.
En particular, los analizadores SAST contienen código fuente para vulnerabilidades comunes, por ejemplo, algunas de las
El análisis SAST se denomina prueba de caja blanca porque el analizador puede acceder a la estructura interna de la aplicación. Es importante tener en cuenta que los analizadores verifican el código fuente sin ejecutarlo, por lo que pueden generar falsos positivos y no detectar algunas vulnerabilidades.
Por este motivo, no debe limitarse únicamente al análisis SAST. Es mejor abordar el tema de manera integral y utilizar diferentes tipos de análisis: SCA, DAST, IAST y OAST.
Herramientas SAST
Soluciones patentadas:
La solución gratuita es GitLab SAST.
Comprobación SCA de origen previa a la compilación
El análisis de composición de software (SCA) es una metodología que protege las aplicaciones analizando sus componentes de código abierto.
Los escáneres SCA buscan dependencias obsoletas que contengan vulnerabilidades y exploits conocidos. Además, algunas herramientas SCA pueden determinar la compatibilidad de licencia de los componentes y los riesgos de infracción de licencia.
Source SCA analiza el código fuente y, más específicamente, las dependencias de la aplicación definidas en el código fuente. Este análisis a menudo se denomina escaneo de dependencias.
SCA le permite detectar un problema en el que una vulnerabilidad en un componente puede provocar problemas de seguridad en todas las aplicaciones.
Un buen ejemplo es
herramientas SCA
Solución comercial con planes de precios gratuitos:
Como parte de GitLab (disponible solo en la versión Ultimate), puedes usar
Comprobaciones posteriores a la compilación: SCA binaria
La fase posterior a la compilación se produce después de que se hayan creado los artefactos a partir del código fuente en CI Pipeline: una imagen de Docker, un paquete RPM o un archivo JAR. Con comprobaciones posteriores a la compilación, puede analizar las dependencias en estos artefactos binarios.
El análisis SCA binario implica inspeccionar artefactos binarios como imágenes de Docker, paquetes RPM y archivos JAR/WAR/EAR. A menudo también se le conoce como escaneo de contenedores. Tiene sentido ejecutarlo cuando se construyen los artefactos binarios, es decir, no antes de la etapa posterior a la compilación.
Hay algunas características interesantes cuando se trabaja con imágenes de Docker. Los analizadores binarios SCA verifican capas de imágenes de Docker y las buscan como sumas hash en bases de datos públicas de vulnerabilidades como
Algunos de los analizadores no sólo pueden encontrar componentes vulnerables sino que también sugieren una solución, por ejemplo, especificando la versión mínima requerida de un componente con una vulnerabilidad ya solucionada.
Ejemplos de analizadores SCA binarios populares
La solución gratuita es
Soluciones de código abierto:
Docker Registry con analizadores integrados -
Comprobaciones en el momento de la prueba: DAST, IAST y OAST
En esta etapa, se realizan pruebas dinámicas de caja gris y pruebas de caja negra. Cuando la estructura interna de la aplicación es parcial o totalmente desconocida, estos controles de seguridad se realizan emulando las acciones de un atacante que encuentra vulnerabilidades e intenta "romper" la aplicación explotándolas. Analicemos brevemente cada uno de ellos: DAST, IAST y OAST.
Comprobación DAST en el momento de la prueba
Los escáneres DAST prueban automáticamente las aplicaciones simulando ataques externos a través de diversas vulnerabilidades. La aplicación es una caja negra para el analizador; no se sabe nada al respecto.
Para las comprobaciones DAST, es necesario tener una instancia en ejecución de la aplicación disponible para el escáner. Además, cuanto más cerca estén los parámetros de la instancia de prueba de la aplicación a la instalación de producción, menos falsos positivos habrá.
Por ejemplo, supongamos que ha implementado una instancia de aplicación de prueba a la que solo se puede acceder a través del protocolo HTTP, pero en producción, solo se puede acceder a la aplicación a través del protocolo HTTP.
En ese caso, el escáner DAST generará algunos errores relacionados con la falta de cifrado del tráfico entre el cliente (analizador) y el servidor (instancia de aplicación).
Ejemplos de herramientas DAST
Herramientas que merecen su atención:
GitLabDAST — sólo disponible en la versión UltimateProxy de ataque OWASP Zed (ZAP) — una solución de código abierto, que también se utiliza en GitLab DAST- acunetix
- Fortalecer WebInspect
- Análisis de aplicaciones de seguridad HCL
- DAST administrado por sinopsis
Tenable.io (Escaneo de aplicaciones web)- Análisis dinámico de Veracode
Genial, sigue adelante.
Verificación IAST en el momento de la prueba
IAST (Prueba de seguridad de aplicaciones interactivas) es una prueba de caja gris que combina las ventajas y fortalezas de la prueba de caja blanca SAST y la prueba de caja negra DAST.
Para aprovechar todas las ventajas y eliminar las desventajas de los métodos SAST y DAST, los desarrolladores inventaron IAST, un mecanismo híbrido que combina estos métodos. Aumenta la precisión de las pruebas dinámicas porque brinda más información sobre el funcionamiento de la aplicación a través del análisis de código.
Vale recordar que además de sus ventajas, IAST tiene limitaciones. El más básico es la dependencia del idioma en el que está escrita la aplicación bajo prueba. Las soluciones IAST funcionan a nivel de aplicación y requieren acceso al código ejecutable para analizar su comportamiento.
Esto significa que las soluciones IAST deben poder comprender el lenguaje de programación en el que está escrita la aplicación. Cabe señalar que la compatibilidad con una solución IAST concreta puede implementarse mejor en algunos idiomas que en otros.
El análisis IAST también lleva mucho tiempo. Depende de muchos factores, como el tamaño y la complejidad de la aplicación, la cantidad de dependencias externas y el rendimiento de la herramienta IAST utilizada.
Además, el proceso de análisis no escanea el código en sí, sino que comprueba sólo aquellos fragmentos que se ejecutan directamente. Por lo tanto, el análisis IAST se combina mejor con las pruebas funcionales cuando se pueden probar tantos escenarios de aplicación como sea posible.
Ejemplos de herramientas IAST
Aquí tienes excelentes herramientas:
Buscador de sinopsis Análisis interactivo de Veracode Microfocus Fortificar WebInspect Checkmarx CxIAST Evaluación de contraste Detección HDV (IAST)
Genial, sigue adelante.
Verificación OAST en el momento de la prueba
OAST (Prueba de seguridad de aplicaciones fuera de banda) es una técnica desarrollada por
Ejemplos de herramientas OAST
Te recomiendo:
Suite de eructos - OWASP ZAP con
Complemento OAST - servicios OAST
PRESUMIR ,tuk tuk , yinteractuar
Siga adelante.
Comprobaciones posteriores a la implementación
Esta es una etapa esencial para garantizar la seguridad y operatividad de la aplicación. A diferencia de las comprobaciones previas a la confirmación, que se realizan en la etapa de desarrollo, las comprobaciones posteriores a la implementación le permiten identificar posibles problemas ya durante el funcionamiento de la aplicación en el entorno natural.
Monitoreo de la seguridad de los artefactos
Para detectar nuevas vulnerabilidades a tiempo, es necesario realizar comprobaciones periódicas de artefactos, incluso después de que se haya implementado una aplicación.
Esto se puede hacer utilizando repositorios o herramientas especiales, como
Monitoreo de seguridad de aplicaciones
Otra forma de garantizar la seguridad es monitorear la propia aplicación. Hay varias tecnologías disponibles para este propósito:
- Web Application Firewall (WAF) es una herramienta de filtrado de tráfico. Funciona en la capa de aplicación y protege las aplicaciones web analizando el tráfico HTTP/HTTPS.
- RASP (Runtime Application Self-Protection) es una tecnología que detecta y bloquea ataques a una aplicación en tiempo real. Agrega una función de defensa al entorno de ejecución, lo que permite que la aplicación se autoproteja automáticamente.
La principal ventaja de RASP sobre WAF es que entiende cómo funciona la aplicación y detecta ataques y tráfico ilegítimo. RASP puede detectar no sólo ataques típicos que utilizan la coincidencia de firmas, sino también intentos de explotar vulnerabilidades de día cero reaccionando a anomalías.
A diferencia de WAF, RASP funciona dentro y con la aplicación. A WAF se le puede engañar. Si un atacante cambia el código de la aplicación, WAF no puede detectarlo porque no comprende el contexto de ejecución.
RASP tiene acceso a información de diagnóstico sobre la aplicación, puede analizarla, detectar anomalías y bloquear ataques.
La tecnología RASP tiene la especialidad de centrarse en prevenir ataques de forma predeterminada. El sistema no requiere acceso al código fuente.
Tontos RASP
Te recomiendo:
Fortalecer cuadrado AbrirRASP es una solución de código abierto desarrollada por BaiduCiencias de la señal Jscrambler hdv Imperva
Genial, sigue adelante.
Visualización de resultados de canalizaciones de DevSecOps y gestión de vulnerabilidades
En diferentes etapas del Pipeline, utilizo muchos analizadores de pruebas de seguridad de aplicaciones/DevSecOps. Cada uno de ellos genera un informe en su propio formato, y algunos generan los llamados Falsos Positivos. Por este motivo, no es fácil analizar la seguridad de una aplicación en su conjunto.
Para analizar eficazmente las vulnerabilidades y gestionar el proceso de corrección, se utilizan herramientas especializadas de gestión de vulnerabilidades, a menudo denominadas simplemente paneles de seguridad .
Los paneles de seguridad resuelven el problema al entregar los resultados de los análisis de DevSecOps de una forma unificada y fácil de analizar. De esta manera, los ingenieros de seguridad pueden ver qué problemas existen, cuáles son los más críticos y cuáles deben abordarse primero.
Herramientas DevSecOps
Como paneles de seguridad se suele utilizar una amplia gama de herramientas: por ejemplo, los sistemas SOAR/SIEM clásicos y el orquestador especializado DevSecOps AppSec.Hub de Swordfish Security o el kit de herramientas de gestión de vulnerabilidades de código abierto DefectDojo.
DefectDojo es una herramienta muy extendida. Es ampliamente utilizado incluso en empresas empresariales. Sin embargo, a pesar de su popularidad y su sólida antigüedad, esta herramienta ocasionalmente tiene algunos defectos de nivel inicial cuando los contribuyentes rompen la funcionalidad básica en la confirmación.
Sin embargo, lo bueno es que los desarrolladores y mantenedores de DefectDojo ayudan a resolver las complejidades. Los desarrolladores de DefectDojo son personas muy receptivas; recomendamos contactarlos directamente a través de Problemas en GitHub.
Concepto de desplazamiento a la izquierda: resumamos
Una vez más, aquí hay un resumen rápido de lo que había en el artículo.
Le expliqué qué es el concepto Shift Left y cómo ayuda a reducir el costo de la corrección de errores y el tiempo de desarrollo: cuanto antes en el proceso de desarrollo inicie las comprobaciones de seguridad, mejor.
Luego, deconstruí la estructura de DevSecOps Pipeline y observé qué controles de seguridad se realizan en cada etapa del Pipeline:
- Pre cometido. Implica verificar la seguridad del código fuente antes de que ingrese al sistema de control de versiones.
- Preconstrucción. Es una verificación de la seguridad del código fuente en el sistema de control de versiones (SecretDetection, SAST, SCA).
- Post-construcción. Es una verificación de seguridad de un artefacto creado a partir del código fuente (Source SCA, Binary SCA).
- Tiempo de prueba. Implica probar la seguridad de la aplicación que se ejecuta desde el artefacto recopilado (DAST, IAST y OAST).
- Post-implementación. Implica verificar la seguridad de la aplicación después de su implementación en el entorno de producción (WAF, RASP).
Ahora comprende cómo funciona DevSecOps Pipeline. Ahora puede evaluar la madurez de sus procesos de DevSecOps, desarrollar una hoja de ruta para su desarrollo y elegir las herramientas adecuadas para cada tarea.
L O A D I N G
. . . comments & more!
. . . comments & more!
