Comunidad de Byte TI

Únete a la Comunidad de Directivos de Tecnología, Ciberseguridad e Innovación Byte TI

Encontrarás un espacio diseñado para líderes como tú.

ReeVo riesgo de software

Código vulnerable y el riesgo del software de terceros 

Código vulnerable y el riesgo del software de terceros  1
Sara Trappetti, Product Marketing Manager Cloud Native EMEA, ReeVo 

El software moderno ha dejado de ser una estructura estática para convertirse en un ecosistema dinámico que integra de manera constante líneas de código creadas por terceros. Y aquí radica el verdadero desafío, ya que importar una sola solución implica heredar silenciosamente una red de dependencias secundarias cuyo control y actualización escapan del alcance directo de la organización. 

El software empresarial ya no se desarrolla únicamente dentro de las organizaciones. Aplicaciones, plataformas y servicios digitales incorporan librerías, paquetes, imágenes de contenedores y componentes de código abierto creados por terceros. Este modelo acelera la innovación y permite desplegar nuevas funcionalidades con rapidez, pero también amplía una superficie de riesgo que muchas organizaciones todavía no comprenden en profundidad. 

La cadena de suministro de software abarca todo el flujo de aplicaciones, dependencias, herramientas y dispositivos digitales que intervienen desde el desarrollo hasta la puesta en producción. Dado que cada componente añadido puede arrastrar nuevas dependencias, una vulnerabilidad, un paquete malicioso o una actualización manipulada también puede propagarse por distintos sistemas sin que la organización afectada sea el objetivo inicial. 

El problema no es el código abierto 

El código abierto es esencial para la economía digital. El riesgo no radica en usarlo, sino en integrarlo sin controles homogéneos, sin conocer su procedencia o sin contar con visibilidad sobre dónde está desplegado. Los equipos pueden incorporar software mediante gestores públicos de paquetes, repositorios, archivos comprimidos, binarios, submódulos o fragmentos copiados directamente en el código. De esto se deduce que, cuando cada equipo sigue un método distinto, proteger la cadena de suministro se vuelve una tarea especialmente compleja.  

Esta falta de uniformidad genera puntos ciegos, ya que una organización puede desconocer que una librería vulnerable está presente en varios servicios críticos, o también recibir una alerta y no saber qué productos, clientes o procesos dependen del componente afectado. En ese escenario, el tiempo de respuesta se alarga y la exposición aumenta. 

De ahí que el primer paso para reducir el riesgo sea saber qué se utiliza y dónde. Mantener un inventario completo de los componentes y dependencias de código abierto permite reaccionar con rapidez ante paquetes comprometidos, vulnerabilidades conocidas o herramientas que han llegado al final de su vida útil. 

Ese inventario debe complementarse con análisis continuos de vulnerabilidades y malware, controles sobre las fuentes de descarga y mecanismos para validar la integridad de los artefactos. También es necesario conservar una cadena de custodia que demuestre que los componentes desplegados han seguido el proceso autorizado y no han sufrido modificaciones no permitidas. Recordemos que el riesgo es dinámico, es decir, aparecen nuevas vulnerabilidades al tiempo que las técnicas de ataque evolucionan, por lo que estas medidas deben revisarse de forma periódica y las actualizaciones deben aplicarse con rapidez. 

De las medidas aisladas a la gobernanza 

La protección de la cadena de suministro no puede depender de la buena voluntad de cada desarrollador ni de revisiones manuales al final del proyecto. Requiere una política común para incorporar, analizar, inventariar, actualizar y auditar los componentes. 

Frameworks como S2C2F plantean una evolución progresiva. En un primer nivel, las organizaciones pueden utilizar gestores de paquetes, conservar copias locales, analizar vulnerabilidades y licencias e inventariar los componentes. En etapas posteriores, es posible automatizar actualizaciones, reforzar la procedencia del software, analizar malware o incluso recompilar los artefactos en infraestructuras de confianza para defenderse frente a amenazas avanzadas.  

No todas las empresas necesitan aplicar el nivel más exigente en todos sus proyectos. La clave está en adaptar los controles al nivel de riesgo e implementar las medidas más avanzadas para las dependencias y aplicaciones críticas. 

Las organizaciones seguirán dependiendo del código abierto y de terceros para innovar, por supuesto, pero la diferencia estará en su capacidad para saber qué consumen, de dónde procede y cómo responder cuando algo falla. En la cadena de suministro digital, la seguridad empieza mucho antes de que el software llegue a producción. 

Un cambio cultural y tecnológico 

Proteger la cadena de suministro exige integrar la seguridad desde las primeras fases del desarrollo, siguiendo el paradigma shift left, y coordinar a los equipos de desarrollo, operaciones y ciberseguridad. Igualmente, implica asumir que la velocidad de entrega no puede medirse al margen de la trazabilidad y la confianza. 

Desde la experiencia de ReeVo en entornos cloud native, este cambio no consiste en añadir una herramienta más, sino en establecer estándares, responsabilidades y evidencias que acompañen al software durante todo su ciclo de vida. 

Por supuesto, las organizaciones seguirán dependiendo del código abierto y de terceros para innovar, pero la diferencia estará en su capacidad para saber qué consumen, de dónde proviene y cómo responder cuando algo falla. En la cadena de suministro digital, la seguridad empieza mucho antes de que el software llegue a producción.  

Por Sara Trappetti, Product Marketing Manager Cloud Native EMEA, ReeVo  

Deja un comentario

Scroll al inicio