Como ya hablamos en una publicación anterior, el desarrollo de software moderno es prácticamente impensable sin el uso de componentes de código abierto. Pero en los últimos años, los riesgos asociados se han vuelto cada vez más diversos, complejos y numerosos. En primer lugar, las vulnerabilidades afectan a la infraestructura y al código de una empresa más rápido de lo que tardan en solucionarse; en segundo lugar, los datos son poco fiables e incompletos; y, en tercer lugar, el malware puede estar acechando en componentes populares, por lo que no basta con limitarse a comprobar los números de versión y enviar tickets de corrección al equipo de TI. La gestión de vulnerabilidades debe ampliarse para abarcar las políticas de descarga de software, las medidas de seguridad para los asistentes de IA y todo el proceso de compilación de software.

Un grupo fiable de componentes de código abierto

La parte principal de la solución es evitar el uso de códigos vulnerables y maliciosos. Se deben implementar las siguientes medidas:

• Tener un repositorio interno de artefactos. La única fuente de componentes para el desarrollo interno debe ser un repositorio unificado en el que se admitan los componentes solo después de una serie de comprobaciones.
• Realizar un riguroso análisis de los componentes. Estos incluyen verificaciones de versiones conocidas del componente, versiones conocidas vulnerables y maliciosas, fecha de publicación, historial de actividad y la reputación del paquete y sus autores. Es obligatorio analizar todo el contenido del paquete, incluidas las instrucciones de compilación, los casos de prueba y otros datos auxiliares. Para filtrar el registro durante la ingesta, utilice analizadores de código abierto especializados o una solución integral de seguridad de la carga de trabajo en la nube.
• Ejecutar la fijación de dependencias. Los procesos de compilación, las herramientas de IA y los desarrolladores no deben usar plantillas (como “más reciente”) al especificar versiones. Las compilaciones de proyectos deben basarse en versiones verificadas. Al mismo tiempo, las dependencias fijadas deben actualizarse regularmente a las versiones más recientes y verificadas que mantengan la compatibilidad y estén libres de vulnerabilidades conocidas. Esto reduce significativamente el riesgo de ataques a la cadena de suministro al vulnerar un paquete conocido.

Mejora de los datos de vulnerabilidad

Para identificar las vulnerabilidades de manera más eficaz y priorizarlas correctamente, una organización debe establecer varios procesos de TI y de seguridad:

• Enriquecimiento de datos de vulnerabilidad. Según las necesidades de la organización, esto es necesario para enriquecer la información combinando datos de NVD, EUVD, BDU, GitHub Advisory Database y osv.dev, o para comprar una fuente de inteligencia de vulnerabilidad comercial donde los datos ya están añadidos y enriquecidos. En cualquier caso, vale la pena controlar además las fuentes de inteligencia de amenazas para rastrear las tendencias de aprovechamiento en el mundo real y obtener una idea del perfil de los atacantes que apuntan a vulnerabilidades específicas. Kaspersky proporciona una fuente de datos especializada específicamente centrada en componentes de código abierto.
• Análisis en profundidad de la composición del software. Las herramientas de análisis de composición de software (SCA) especializadas permiten la navegación correcta de la cadena de dependencias en código abierto para hacer un inventario completo de las bibliotecas que se utilizan y descubrir componentes desactualizados o no compatibles. Los datos sobre componentes en buen estado también son útiles para enriquecer el registro de artefactos.
• Identificación de software abandonado. Incluso si un componente no es formalmente vulnerable y no se ha declarado oficialmente no compatible, el proceso de análisis debería marcar los componentes que no han recibido actualizaciones durante más de un año. Estos garantizan un análisis por separado y un posible reemplazo, al igual que los componentes EOL.

Protección del código de IA y de los agentes de IA

Las actividades de los sistemas de IA utilizados en la codificación deben estar envueltas en un conjunto integral de medidas de seguridad, desde el filtrado de datos de entrada hasta la formación del usuario:

• Restricciones sobre las recomendaciones de dependencias. Configure el entorno de desarrollo para asegurarse de que los asistentes y agentes de IA solo puedan hacer referencia a componentes y bibliotecas del registro de artefactos de confianza. Si no contienen las herramientas correctas, el modelo debería activar una solicitud para incluir la dependencia en el registro, en lugar de extraer algo de PyPI que simplemente coincida con la descripción.
• Filtro de las salidas del modelo. A pesar de estas restricciones, todo lo generado por el modelo también debe verificarse para garantizar que el código de IA no contenga dependencias desactualizadas, no compatibles, vulnerables o inventadas. Esta verificación debe integrarse directamente en el proceso de aceptación del código o en la etapa de preparación de la compilación. No reemplaza el proceso de análisis estático tradicional: las herramientas SAST aún deben estar integradas en el flujo de CI/CD.
• Formación de desarrolladores. Los equipos de TI y de seguridad deben estar íntimamente familiarizados con las características de los sistemas de IA, sus principios operativos y los errores comunes. Para lograr esto, el personal debe completar un curso de formación especializado adaptado a sus funciones específicas.

Eliminación sistemática de componentes EOL

Si los sistemas de una empresa utilizan componentes de código abierto desactualizados, se debe adoptar un enfoque sistemático y congruente para abordar sus vulnerabilidades. Hay tres métodos principales para hacerlo:

• Migración. Este es el método más complejo y costoso desde el punto de vista organizativo, que implica el reemplazo total de un componente seguido de la adaptación, reescritura o reemplazo de las aplicaciones creadas sobre él. Decidirse por una migración es especialmente abrumador cuando exige una revisión masiva de todo el código interno. Esto afecta con frecuencia a los componentes principales: es imposible migrar fuera de Node.js 14 o Python 2 fácilmente.
• Soporte a largo plazo (LTS). Existe un mercado de servicios de soporte dedicado para proyectos heredados a gran escala. A veces, esto implica una bifurcación del sistema heredado mantenido por desarrolladores externos; en otros casos, los equipos especializados respaldan los parches que corrigen vulnerabilidades específicas en versiones anteriores no compatibles. La transición a LTS generalmente requiere costes de soporte continuos, pero esto aún puede ser más rentable que una migración completa en muchos casos.
• Controles compensatorios. Según los resultados de un análisis detallado, se puede establecer un conjunto de medidas de seguridad integrales para mitigar el riesgo de aprovechamiento de las vulnerabilidades dentro del producto heredado. Tanto la eficacia como la viabilidad económica de este enfoque dependen de la función del software dentro de la organización.

La seguridad, la TI y la empresa deben trabajar juntos para escoger una de estas tres rutas para cada EOL documentado o componente abandonado, y reflejar la elección realizada en los registros de activos y SBOM de la empresa.

Gestión de vulnerabilidades de código abierto basada en riesgos

Todas las medidas enumeradas anteriormente reducen el volumen de software y componentes vulnerables que entran en la organización y simplifican la detección y reparación de fallos. A pesar de esto, es imposible eliminar todos los defectos: el número de aplicaciones y componentes simplemente está creciendo demasiado rápido.

Por lo tanto, priorizar las vulnerabilidades según el riesgo del mundo real sigue siendo esencial. El modelo de evaluación de riesgos debe ampliarse para tener en cuenta las características del código abierto, respondiendo a las siguientes preguntas:

• ¿Se ejecuta realmente la rama del código vulnerable en el entorno de la organización? Se debe realizar un análisis de accesibilidad para las vulnerabilidades descubiertas. Muchos fragmentos de código defectuosos nunca se ejecutan realmente dentro de la implementación específica de la organización, lo que hace que la vulnerabilidad sea imposible de explotar. Ciertas soluciones SCA pueden realizar este análisis. Este mismo proceso permite evaluar un escenario alternativo: ¿qué sucede si los procedimientos o componentes vulnerables se eliminan por completo del proyecto? A veces, este método de reparación resulta sorprendentemente indoloro.
• ¿Se está aprovechando el defecto en ataques del mundo real? ¿Hay una PoC disponible? Las respuestas a estas preguntas son parte de marcos de priorización estándar como EPSS, pero el seguimiento debe realizarse a través de un conjunto mucho más amplio de fuentes de inteligencia.
• ¿Se ha denunciado actividad cibercriminal en este registro de dependencia o en componentes relacionados y similares? Estos son factores adicionales para la priorización.

Tener en cuenta estos factores permite al equipo asignar recursos de manera efectiva y remediar primero los defectos más peligrosos.

La transparencia está de moda

El nivel de exigencia en seguridad para el software de código abierto seguirá subiendo. Las empresas que desarrollan aplicaciones, incluso para uso interno, se enfrentarán a presiones regulatorias que exigen ciberseguridad documentada y verificable dentro de sus sistemas. Según las estimaciones de los expertos de Sonatype, el 90 % de las empresas a nivel mundial ya se encuentran bajo uno o más requisitos para proporcionar evidencia de la fiabilidad del software que utilizan; por lo tanto, los expertos consideran la transparencia “la moneda de cambio de la seguridad en la cadena de suministro de software”.

Al controlar el uso de aplicaciones y componentes de código abierto, enriquecer la inteligencia de amenazas y supervisar estrictamente los sistemas de desarrollo impulsados por la IA, las organizaciones pueden introducir las innovaciones que la empresa anhela, todo mientras se eliminan los altos estándares establecidos por los reguladores y clientes.