Las aplicaciones nativas de la nube hacen que la cadena de suministro de program …



Las implementaciones nativas de la nube tienden a ser pequeñas, intercambiables y más fáciles de proteger, pero sus cadenas de suministro de software requieren una mayor atención.

Los desarrolladores escriben código. Así es como la mayoría de la gente entiende el trabajo de un desarrollador de software package. La realidad, sin embargo, es más compleja. Si bien los desarrolladores escriben mucho código, casi nunca escriben todos el código en la aplicación. ¿De dónde viene el código adicional? Online, por supuesto.

Los lenguajes de programación modernos usan bloques de construcción en forma de paquetes para manejar cosas como matemáticas, manipulación de texto y redes. Esto tiene mucho sentido. No es necesario que cada programador escriba sus propios algoritmos para operaciones básicas. Muchos lenguajes de programación también admiten (y a menudo fomentan) la programación modular, lo que hace que los complementos estén disponibles para manejar tareas más complejas y bien definidas. Con el tiempo, surgieron importantes bibliotecas de paquetes y módulos, escritas por la comunidad y compartidas libremente en plataformas como GitHub.

La razón principal por la que las organizaciones aprovechan el software de código abierto es para acelerar el desarrollo. La creación de una aplicación completamente desde cero es extremadamente rara, por lo que se estima que el 99% de las bases de código contienen componentes de código abiertoy hasta el 70% del código empresarial ahora se basa en código abierto. Los desarrolladores están ocupados fusionando piezas listas para usar con código personalizado para lograr el resultado deseado sin reinventar la rueda. De manera equivalent, DevOps es un proceso de ensamblaje de imágenes de foundation de contenedores, middleware de código abierto, plantillas de máquinas virtuales y servicios en la nube, como almacenamiento, redes y Kubernetes.

Cuando se tiene en cuenta todo eso, solo una fracción de la potencia informática de una organización ejecutará código desarrollado internamente. El resto vendrá de fuentes externas. Para las organizaciones de seguridad, esto presenta un universo de riesgos.

A junio de 2020 reporte sobre las vulnerabilidades en el software líder de código abierto revela que su número full se duplicó con creces entre 2018 y 2019, de 421 vulnerabilidades y exposiciones comunes (CVE) a 968. Los datos recopilados por GitHub en octubre de 2020 sugieren que el 17% de los errores de software hubo insertado intencionalmente por actores maliciosos. Juntos, estos informes muestran que la contaminación intencional de proyectos de código abierto, o «envenenamiento por repo», se está convirtiendo en una amenaza mayor.

Se necesitan un promedio de 54 días para que se agregue una vulnerabilidad descubierta a la Foundation de datos nacional de vulnerabilidades (NVD), lo que hace que el infame ataque de día cero dure casi dos meses. Incluso después de que se informan las vulnerabilidades, se dedica poco tiempo a solucionarlas. Desarrolladores encuestados por la Fundación Linux informaron en promedio que solo el 2.27% de su tiempo lo dedican a errores de seguridad, lo que deja a las organizaciones con conocimiento del riesgo pero sin una forma directa de resolverlo.

Sin embargo, las vulnerabilidades representan un riesgo potencial que solo puede explotarse cuando el componente vulnerable está en uso, sin parchear, sin controles de compensación. Para aumentar sus posibilidades de éxito, los atacantes han recurrido a envenenar proyectos de código abierto con malware directo, destinado a incorporarse a la cadena de suministro de software package y ejecutarse junto con el código de la aplicación.

Los repositorios de paquetes populares como npm, PyPI y RubyGems se han convertido, para los actores de amenazas, un canal de distribución de malware confiable y escalable. Durante el año pasado, el número de ataques a la cadena de suministro ha aumentado un 430%. Con DevOps, la dependencia del software program externo invita a más ataques dirigidos a las cadenas de suministro específicas de los entornos nativos de la nube, como colocar malware oculto en imágenes de contenedores disponibles públicamente. El equipo de investigación de Aqua Stability, Nautilo, reveló recientemente que varios servicios SaaS utilizados por los desarrolladores de contenedores son susceptibles a minería de criptomonedas. Si bien los riesgos son reales, las organizaciones no dejarán de usar program de código abierto. Los beneficios de eficiencia son demasiado grandes como para simplemente volver atrás y escribir program desde cero. El código abierto llegó para quedarse.

Las organizaciones que tengan la intención de reducir estos riesgos deben comenzar por obtener visibilidad y manage sobre el computer software de origen externo. Los escáneres de vulnerabilidades pueden ayudar a gestionar los riesgos de errores de seguridad en los componentes de código abierto. Estas herramientas deben incluir automatización, priorización, consejos prácticos y métricas para medir cómo se solucionan las vulnerabilidades con el tiempo. La automatización es importante porque depender de la evaluación handbook y los procesos de corrección lleva demasiado tiempo y muchos desarrolladores carecen del conocimiento para priorizar los riesgos y abordarlos.

Los paquetes, los módulos listos para usar e incluso las imágenes de contenedores completos también pueden ser producto de atacantes que intentan ingresar y colarse código malicioso en las aplicaciones. Estos artefactos contaminados no estarán en el NVD, no se les asignará un CVE y no se detectarán como vulnerabilidades publicadas. Un ejemplo del peor de los casos es una imagen de contenedor mal configurada, con un usuario root predeterminado, construida sobre una imagen foundation que contiene una puerta trasera y desplegada en un entorno de nube con redes abiertas.

Para prevenir tales escenarios, las organizaciones deben considerar toda su cadena de suministro: cómo el software program ingresa a la organización, desde dónde y por quién. Debe haber pautas claras sobre la calidad y reputación del computer software de código abierto, prefiriendo proyectos con compromisos recientes, colaboradores comprometidos y buen gobierno.

El application entrante no solo debe escanearse en busca de vulnerabilidades, sino también analizarse mientras se ejecuta en un entorno de espacio aislado antes de usarse. Esto revelará el código malicioso que se insertó intencionalmente y solo será noticeable en la ejecución. Además, el inventario, la versión y la configuración de los servicios en un entorno de nube deben considerarse como parte de la cadena de suministro, incluidos los scripts utilizados por DevOps para aprovisionarlos.

Muchas prácticas de seguridad de la información se establecieron en un momento en que el desarrollo y las operaciones eran relativamente confiables, pero los servidores de larga duración eran difíciles de proteger. Hoy, el estado de seguridad se invierte. Las implementaciones nativas de la nube, al ser pequeñas, inmutables e intercambiables, son más fáciles de proteger. Pero las cadenas de suministro que los alimentan requieren más atención que nunca.

Tsvi Korren, CISSP, ha sido un profesional de seguridad de TI durante más de 20 años. Tsvi es actualmente el CTO de campo en Aqua, donde lidera el esfuerzo de permitir que las organizaciones utilicen tecnologías Cloud Native y mejoren su seguridad a través de DevSecOps. Ver biografía completa

Más información





Enlace a la noticia primary