A medida que los desarrolladores se ven sometidos a una presión cada vez mayor para entregar proyectos rápidamente, aumenta el nivel de conflicto entre los equipos de desarrollo y seguridad. Y los atacantes se están aprovechando de este conflicto para apuntar a las cadenas de suministro de software.
Entonces, ¿qué tipo de amenazas enfrentan las empresas y qué pueden hacer para protegerse? Hablamos con Pete Morgan, cofundador y CSO de la empresa de seguridad de la cadena de suministro Phylum para averiguarlo.
BN: ¿Por qué la cadena de suministro de software es un objetivo tan atractivo para los atacantes?
PM: Hay tres razones principales por las que los malos actores apuntan a las cadenas de suministro de software:
Los desarrolladores son los nuevos de alto valor objetivos: Los atacantes conocen los objetivos de un suministro el compromiso de la cadena son los desarrolladores de software o la infraestructura privilegiada. El compromiso de cualquiera de los objetivos produce claves de acceso a la nube, claves SSH, claves de firma y otros secretos. Estas claves a menudo viven durante largos períodos de tiempo, lo que significa que un compromiso no detectado permite a los atacantes mucho acceso y tiempo para planificar las siguientes etapas con cuidado. Hay una serie de puntos ciegos que explotar: La cadena de suministro de software es un concepto en constante cambio. Los paquetes de código abierto se utilizan en el 85 por ciento-95 por ciento de las aplicaciones y son creados y mantenidos por extraños en Internet. Los desarrolladores usan estos paquetes sin supervisión o controles del equipo de seguridad. Mapear la verdadera superficie de ataque para la cadena de suministro de software de una organización es complicado y varía según la organización, lo que deja muchos vacíos. Mantenerlo constantemente a lo largo del tiempo es aún más difícil, lo que brinda varias oportunidades para los atacantes. La defensa tiene que ser perfecta, los atacantes solo tienen que ganar una vez. Bajas inversiones para grandes beneficios: el costo de atacar la cadena de suministro de software es extremadamente bajo y, a menudo, gratuito. Algunos ataques solo requieren ejecutar un script y esperar. Hasta que las organizaciones eleven el nivel de sus programas de seguridad de la cadena de suministro de software, los atacantes saben que no tienen que trabajar tan duro ni usar ataques sofisticados para tener éxito.
BN: ¿Cuáles son los principales puntos de fricción entre los equipos de desarrollo y seguridad?
PM: Los equipos de seguridad quieren más visibilidad y control sobre el proceso de desarrollo, y los desarrolladores quieren menos obstáculos a la innovación como sea posible. Cuando los objetivos, la política y el proceso no están bien alineados o, en este caso, a menudo son conflictivos, la fricción existirá naturalmente.
BN: ¿Cómo puede la seguridad mejorar la relación con los equipos de desarrollo?
PM: La empatía es un factor muy importante para encontrar puntos en común entre estos dos equipos, y es esencial que estos dos equipos trabajen en armonía para cumplir con los objetivos comerciales críticos. Los equipos de seguridad deben incorporar a los desarrolladores en las primeras etapas de la toma de decisiones de seguridad y facilitarles la adopción de políticas, y los desarrolladores deben tener la mente abierta cuando se les solicite incorporar prácticas de seguridad en sus procesos. Abrir líneas de comunicación, compartir comentarios regulares sobre lo que funciona y lo que no, y adoptar tecnología que automatice la aplicación de políticas y contextualice los problemas sin interrumpir el proceso de desarrollo conducirá a una cooperación más efectiva.
BN: ¿Por qué? ¿Es tan peligroso el malware en paquetes de código abierto?
PM: Oh, ¡por dónde empezar! Los paquetes maliciosos se diferencian del malware tradicional en que la mayoría de los paquetes maliciosos no necesitan explotar ninguna vulnerabilidad ni engañar a un usuario para que los ejecute. Un desarrollador que instala el paquete incorrecto o instala un paquete que tiene la dependencia incorrecta puede verse comprometido, y el 99 por ciento de las veces nunca lo sabrá.
La mayoría de los desarrolladores simplemente no tienen el tiempo o las herramientas para analizar el riesgo de los envases que utilizan. Los paquetes tienen dependencias que tienen dependencias, y esa cadena puede ser de 20 a 30 niveles que abarcan decenas de miles de paquetes de código abierto. La mayoría de las organizaciones todavía solo analizan en busca de vulnerabilidades y uso indebido de licencias, por lo que el malware pasa fácilmente desapercibido: es un robo y captura de claves y secretos para luego montar más ataques.
BN: ¿Cuáles son algunos ¿Otros riesgos asociados con el código fuente abierto que a menudo se pasan por alto?
PM: Hay muchos, pero uno que se destaca es la transición del mantenedor. No es una vulnerabilidad de software o un paquete malicioso; es uno de los muchos riesgos de autor que se derivan de las prácticas comunes en el ecosistema de código abierto. A veces, un desarrollador ya no tiene el interés o el tiempo para mantener un paquete popular de código abierto. A menudo quieren mantenerlo funcional para los usuarios que confían en él, por lo que transfieren el mantenimiento a otra persona o grupo. Es increíblemente difícil investigar los motivos e incentivos del nuevo mantenedor, por lo que el control de estos paquetes simplemente se pone en manos de un extraño diferente de Internet. Si un autor malintencionado toma el control de un paquete que se utiliza en una aplicación, introduce un nuevo riesgo que no se tuvo en cuenta en la compilación inicial.
BN: ¿Qué tan importante es estar al tanto de y administrar dependencias?
PM: Debemos ser críticos con las dependencias porque la inclusión a largo plazo de cada paquete amplía drásticamente la superficie de ataque. Necesitamos comprender el riesgo de reutilizar un código que cambia constantemente para defender el software de manera efectiva. De lo contrario, las organizaciones continuarán reutilizando código de extraños en Internet con una estrategia de esperar lo mejor. Esta es la razón por la cual la cadena de suministro de software está tan presente en las noticias en este momento.
BN: ¿Cómo pueden los SBOM ayudar con la visibilidad y la seguridad?
PM: Los SBOM son un paso en la dirección correcta, pero me preocupa que las reglamentaciones y los mandatos para adoptar el proceso SBOM al por mayor den lugar a mucho movimiento sin mejoras significativas en la seguridad del software. La idea de obtener visibilidad de los componentes de un proyecto de software es una obviedad, pero el proceso de SBOM que veo es lamentablemente deficiente, ya que solo proporciona instantáneas incompletas en el tiempo.
La información proporcionada por SBOM es insuficiente para cubrir la superficie de ataque de la cadena de suministro de software, y las implicaciones para las organizaciones de proveedores y consumidores de adoptar el proceso de usar SBOM supone una realidad en la que los presupuestos de seguridad de aplicaciones y/o seguridad de productos son efectivamente ilimitados. Los formatos y procesos de SBOM deben evolucionar significativamente antes de que puedan adoptarse de manera significativa.
BN: ¿Qué estándares, normas o comportamientos deben cambiar para que las organizaciones protejan mejor sus cadenas de suministro de software?
PM: Se requiere un cambio de mentalidad fundamental. Las empresas deben comprender que ahora están expuestas a un riesgo significativo en la cadena de suministro de software, y probablemente lo hayan estado durante mucho tiempo. La seguridad de la cadena de suministro de software está en su infancia, por lo que los ataques evolucionan a diario y las defensas solo se han creado en los últimos dos años. Suponga que sus desarrolladores están siendo atacados activamente y que tiene una exposición no realizada al riesgo de la cadena de suministro de software. Una vez que supere la falsa sensación de seguridad, puede comenzar desde un lugar honesto para crear un programa eficaz que pueda escalar en función de sus necesidades únicas.
Crédito de la imagen: Manczurov/Shutterstock