La combinación de procesos de desarrollo, implementación y operaciones de software dentro de los equipos de DevOps promete una mayor eficiencia, actualizaciones más fáciles y frecuentes y aplicaciones de mayor calidad. Sin embargo, la complejidad de la infraestructura también ha dado lugar a una superficie de ataque cada vez mayor que es difícil de monitorear y mantener.
En cuanto al desarrollo, la organización promedio utiliza de cuatro a nueve lenguajes de programación diferentes, administra millones de nuevos paquetes e imágenes cada año y debe parchear miles de vulnerabilidades en los componentes de código abierto más comunes, según Informe de JFrog “Estado de la Unión de la Cadena de Suministro de Software 2024”En el otro extremo del proceso de DevOps, dos tercios de las empresas han retrasado la implementación de una aplicación debido a problemas de seguridad relacionados con Kubernetes, y casi la mitad (46%) ha experimentado incidentes de seguridad reales, según Informe de seguridad “Estado de Kubernetes” de Red Hat 2024.
Los profesionales de la ciberseguridad que quieran proteger el proceso de aplicaciones deben prestar atención al software escrito por los desarrolladores, los componentes de código abierto importados por los desarrolladores, los contenedores y la infraestructura de la nube utilizados para implementar el software y las herramientas de creación utilizadas para crear software, dice Jeff Williams. CTO y cofundador de Contrast Security, una empresa de seguridad de software.
“El problema es que la superficie de ataque es enorme”, explica. “No se trata sólo de su tubería. Este es todo el código utilizado para desarrollar software: IDE, herramientas de prueba y conjuntos de rendimiento. …Cada uno de ellos es capaz de corromper el código que sus desarrolladores crean y producen. »
Es cada vez más importante obtener una visión integrada de todo el proceso de DevOps, desde el desarrollo hasta la implementación de la aplicación. Componentes de software: no sólo bibliotecas de código abierto, sino también Contenedores acoplables Y otros activos de infraestructura — suelen tener un código vulnerable, lo que aumenta los riesgos. Las herramientas de terceros pueden verse comprometidas: recuerde La brecha de seguridad de Codecov — permitir la inyección de código malicioso en proyectos en desarrollo. La infraestructura y el almacenamiento en la nube pueden estar mal configurados o mal protegidos, p. Instancias de copos de nieve.
Tener una buena visibilidad del estado de la infraestructura de implementación y canalización del software DevOps es esencial, dice Josh Lemos, gerente de seguridad de la información del proveedor de DevOps GitLab (y sin relación con el autor).
“Hay dos trenes realmente importantes que deben circular”, afirmó. “La primera es que necesita seguridad y empaquetado del desarrollo, cumplimiento y certificación de todos sus artefactos de compilación en uno de estos trenes o flujos de trabajo. El otro es el monitoreo de la implementación y la orquestación de estos elementos en sus entornos de producción. »
Escribir, usar, comprar, construir
En general, los equipos de seguridad de DevOps necesitan proteger cuatro áreas que están expuestas a ataques. La primera y la segunda área son las más obvias para los desarrolladores: el código que escriben y los componentes de software que utilizan, dice Williams de Contrast Security.
“Hablamos de [that code] “Desde el comienzo de OWASP”, dijo. “Si tienes errores en el código que escribes, la gente los explota y te violan. No es bueno. »
Las empresas también deben prestar atención al código que compran o utilizan indirectamente a través de un servicio. Finalmente, deben proteger las aplicaciones y servicios utilizados para crear e implementar software: IDE, herramientas de prueba, conjuntos de rendimiento e instrumentación.
“Cada uno de ellos es capaz de corromper el código final”, afirma Williams, y añade que la mayoría de los equipos de DevOps no prestan atención a la superficie de ataque completa que representan sus canales y cadenas de suministro de software. “Creo que todavía estamos en la edad de piedra en lo que respecta a la verdadera seguridad de la cadena de suministro. »
Si bien la gran mayoría de las empresas (87%) están creando o migrando aplicaciones a la nube nativa, el 59% no entendió las implicaciones de seguridad de hacerlo y, como resultado, experimentó un problema de seguridad. Como era de esperar, los incidentes de seguridad comunes son tan variados como la infraestructura necesaria para producir e implementar software: violaciones de red, vulnerabilidades de API, configuraciones incorrectas de certificados, vulnerabilidades de clústeres y contenedores entre las principales causas de incidentes de seguridad, según un estudio. Noviembre de 2023 Encuesta sobre problemas de seguridad de aplicaciones nativas en la nube.
Incluso las empresas que monitorean partes de sus procesos de DevOps no obtienen una buena cobertura, afirma Williams.
“Este no es el caso en todas partes, y casi nada cubre partes de DevOps como escritorios para desarrolladores, IDE, marcos de prueba y complementos”, explica. “Quiero decir, hay un universo de código que nadie monitorea y la mayoría de las organizaciones realmente no piensan en este problema. »
Cuestione su infraestructura DevOps
Para la mayoría de las empresas, es esencial asegurarse de tener visibilidad en todo el proceso. La supervisión puede advertir cuando una parte que no es de confianza reactiva repentinamente un paquete retirado en el repositorio, o cuando se incluyen secretos en el código que de otro modo podrían trasladarse a un repositorio, o cuando una imagen de Docker contiene cantidades significativas de software no utilizado.
Las empresas deben proporcionar un seguimiento continuo de cada etapa del proceso, afirma Paul Davis, CISO de campo del proveedor de cadena de suministro de software JFrog.
“[Knowing] que esta pasando…y [seeing that] un paquete salió mal en producción, o tengo que restaurar un paquete porque a alguien se le ocurrió una nueva vulnerabilidad, esta facilidad de uso [and visibility] “En la superficie de ataque, esa visión y trazabilidad son claves para mí”, afirma.
Las empresas también deberían tomar medidas en cuatro áreas específicas de su infraestructura DevOps, según Lemos de GitLab. Primero, se deben registrar las identidades de cualquier desarrollador, especialista en operaciones, dispositivo o servicio que participe en el proceso. Las empresas también deben mantener una lista de los artefactos de software que utilizan, aquellos que tienen vulnerabilidades y mantener un repositorio privado, si es posible. Los sistemas de compilación deben probarse con frecuencia y cualquier desencadenante automatizado (como cambios en el software de terceros que desencadena una compilación) debe analizarse para determinar posibles implicaciones de seguridad. Finalmente, todo el oleoducto debe diseñarse para minimizar el impacto (es decir, el “radio de explosión”) de un compromiso, afirma.
“Lo mejor que he visto hacer a las empresas primero es adoptar patrones de diseño conocidos y efectivos”, dice Lemos. “Cuanto más puedas ignorarlo, más podrás deshacerte de él”. [bad security practices]“Cuanto más eficiente sea su programa de seguridad, menos rotación y gastos generales tendrá, y más reutilizable será su código. »
Las promesas y los peligros de la IA
La amplitud de la superficie de ataque de DevOps también representa una oportunidad para la automatización y la asistencia de inteligencia artificial (IA). DevOps ya obtiene gran parte de su agilidad y velocidad de la automatización, con la configuración y la infraestructura como código predominante, ya que expresar la arquitectura como archivos permite la repetibilidad de las operaciones, mientras que el análisis de instrucciones permite una infraestructura más segura.
Sin embargo, cuando se trata de seguridad, la mayoría de las empresas dudan en adoptar esta solución, explica Laurent Gil, director de producto de la plataforma de automatización de Kubernetes CAST AI.
“Casi todas las empresas de seguridad ofrecen automatización de una forma u otra y, sin embargo, nadie la utiliza”, afirma.[Security teams] “Debe saber que es completamente posible utilizar la automatización para bloquear cosas que deberían bloquearse o para corregir automáticamente las vulnerabilidades que encuentre. »
Pero el desarrollo de la IA también aporta nuevas formas de trabajar con código y datos: una superficie de ataque que no se comprende del todo y para la que los equipos de DevOps no están preparados, afirma Lemos.
“Es posible lanzar ataques a la antigua usanza porque se combinan datos y contenido en un modelo”, explica. “Si se utiliza un modelo con un archivo pickle en la estación de trabajo de un científico de datos, si lo deserializa y contiene una carga útil, simplemente habrá invitado código malicioso a su entorno. »