En este blog se resumen los puntos clave de nuestro seminario webSupply Chain deSoftware : los puntos débiles que aprovechan los atacantes». Puedes ver el seminario web completo aquí.
Los riesgos de la cadena Software han aumentado drásticamente, ya que las organizaciones recurren cada vez más a componentes de código abierto, paquetes externos y procesos de desarrollo automatizados. Pequeñas brechas que antes parecían inofensivas ahora acarrean consecuencias reales, sobre todo a medida que las dependencias se vuelven más complejas y difíciles de verificar.
Un claro ejemplo de este cambio lo constituyen los recientes gusanos «npm Shai-Hulud» y «Shai-Hulud 2.0», que se propagaron a través de paquetes comprometidos y afectaron a miles de proyectos derivados en cuestión de horas. Incidentes como este dejan una cosa clara: las vulnerabilidades de la cadena de suministro ya no se limitan a un ámbito concreto, sino que se propagan en cadena por ecosistemas enteros.
Dado que entre el 70 % y el 90 % del software moderno está compuesto por componentes de código abierto —la mayoría de los cuales los desarrolladores nunca ven directamente—, los pequeños problemas pueden convertirse rápidamente en grandes riesgos. Sin embargo, solo el 15 % de las organizaciones se siente seguro respecto a cómo gestiona ese riesgo relacionado con el código abierto. Teniendo en cuenta que se prevé que, para 2025, el 70 % de los ataques maliciosos basados en IA tengan como objetivo las cadenas de suministro, ahora es esencial identificar los eslabones débiles de la cadena de suministro de software.
Para los equipos de ingeniería y seguridad, la ventaja es clara: saber dónde se encuentran estos puntos débiles se traduce en menos sorpresas, tiempos de respuesta más rápidos y una probabilidad mucho menor de acabar en los titulares relacionados con la cadena de suministro.
Las listas de materiales de seguridad (SBOM) ya no son opcionales
Para gestionar los riesgos de la cadena de suministro de software y hacer frente a las vulnerabilidades, las organizaciones necesitan tener una visión clara de los componentes que conforman su pila de software. La base de esta visibilidad es la SBOM (lista de materiales de software), que aporta la transparencia necesaria para comprender los riesgos de los componentes y actuar con rapidez cuando surgen problemas.
Una SBOM se define como un inventario detallado de todos los componentes, licencias y dependencias —tanto de código cerrado como de código abierto— que se utilizan en una aplicación. Este inventario proporciona datos esenciales para la transparencia, el cumplimiento normativo y la gestión de riesgos.
Lo que hoy no es vulnerable ni malicioso puede llegar a serlo fácilmente mañana. Dado que continuamente se descubren vulnerabilidades, incluso en versiones antiguas, es necesario llevar a cabo una supervisión y un inventario constantes.
George PrichiciVicepresidente de Productos, OPSWAT
SBOM frente a SCA
Un aspecto importante es la distinción entre SBOM y SCA (análisisSoftware ). El SBOM es el inventario, es decir, una lista de componentes. El SCA evalúa si alguno de esos componentes es vulnerable, está obsoleto o supone un riesgo. Juntos, proporcionan a las organizaciones la información necesaria para tomar decisiones fundamentadas, responder con mayor rapidez a los problemas de seguridad y reforzar la gestión global de riesgos.
| Categoría | SBOM | SCA |
|---|---|---|
Objetivo | Lista de componentes |
Identificar vulnerabilidades en los componentes
|
Cobertura de riesgos | Cumplimiento normativo y transparencia | Riesgos de seguridad, CVE, riesgos en tiempo de ejecución |
Momento oportuno | Previa a la implementación / adquisición | Continuo / compilación y tiempo de ejecución |
Las tendencias mundiales, impulsadas en parte por ataques como el de SolarWinds, exigen ahora el uso de SBOM, y las presiones normativas procedentes de organismos como la CISA, la NSA y el NIST, así como de la UE y los países aliados de la OTAN, hacen que la transparencia de las SBOM ya no sea opcional, sino una exigencia fundamental para cualquier proveedor de software.
Los 7 puntos débiles clave que aprovechan los atacantes
El rápido ritmo del desarrollo actual, unido a la gran dependencia del código de terceros y de código abierto, ha dado lugar a graves vulnerabilidades. Los atacantes están aprovechando siete puntos débiles principales:
1. Código abierto y riesgo de dependencia
Cuando los desarrolladores dan prioridad a la velocidad, suelen utilizar grandes bibliotecas de código abierto sin realizar una revisión completa del código. Un solo componente puede introducir dependencias transitivas adicionales. Si solo se supervisa el nivel superior, se puede pasar por alto el código malicioso inyectado en esas dependencias transitivas ocultas.
Este patrón es algo que seguimos observando en los ecosistemas de código abierto. Un solo paquete comprometido puede propagarse a través de las cadenas de dependencias y alcanzar millones de descargas antes de que nadie se dé cuenta. Un reciente ataque a la cadena de suministro de npm relacionado con cripto-malware pone de manifiesto exactamente cómo ocurre esto en la práctica.
Buenas prácticas:
- Analiza todos los paquetes de código abierto y sus cadenas de dependencias completas para identificar vulnerabilidades, componentes obsoletos o malware oculto antes de que lleguen a tu código fuente.
- Supervisa constantemente las dependencias a lo largo del tiempo, ya que los componentes que antes eran seguros pueden volverse peligrosos a medida que surgen nuevas vulnerabilidades (CVE) o actualizaciones maliciosas.
- Utiliza repositorios de confianza y comprueba la integridad de los paquetes para asegurarte de que los que descargas no han sido manipulados.
- Aplica políticas que marquen o bloqueen las licencias de riesgo para que no se cuelen en tus compilaciones condiciones de licencia incompatibles o maliciosas.
- Aplaza el uso de los paquetes recién publicados hasta que hayan sido revisados, lo que reducirá la probabilidad de incorporar a tu entorno versiones sin revisar o maliciosas.
2. Riesgo relacionado con las licencias
Las cuestiones relacionadas con las licencias afectan hoy en día tanto al ámbito de la ingeniería como al jurídico. Las licencias «virales», como la GPL, pueden obligar a que la aplicación resultante se publique bajo la misma licencia, lo que podría provocar que su empresa perdiera su propia propiedad intelectual (PI). Es necesario realizar un seguimiento continuo, ya que las condiciones de las licencias pueden cambiar, incluso en el caso de versiones anteriores que antes cumplían con los requisitos.
Buenas prácticas:
- Utiliza una herramienta de detección automática de licencias para identificar las licencias de alto riesgo o incompatibles en las primeras fases del desarrollo. Aquí se explica con más detalle por qué es importante: «El papel crucial de la detección de licencias en la seguridad del código abierto».
- Realice un seguimiento continuo de los cambios en las licencias para detectar modificaciones que puedan afectar al cumplimiento normativo o a la exposición de la propiedad intelectual.
- Bloquea o revisa los componentes con licencias restrictivas o de código abierto antes de que se incorporen al código fuente.
- Mantenga un inventario claro de todas las licencias en uso para simplificar las auditorías y las evaluaciones de riesgos.
3. Lagunas en los datos de la SBOM o ausencia de SBOM
Aunque la normativa exige compartir las listas de componentes de software (SBOM), una lista general no es suficiente. Para una mitigación y prevención eficaces, se necesitan datos detallados, como el autor, los colaboradores, la frecuencia de lanzamiento y el estado de mantenimiento.
Buenas prácticas:
- Mejora los informes SBOM volviendo a analizar los componentes para enriquecerlos con datos actualizados sobre licencias, el estado de las vulnerabilidades y otros metadatos esenciales. Aquí se ofrece un ejemplo detallado de cómo hacerlo, en la sección «Validación y enriquecimiento de informes SBOM de CycloneDX».
- Validar y enriquecer las listas de materiales de seguridad (SBOM) mediante herramientas automatizadas para garantizar que la información sea completa, precisa y útil.
- Exigir a los proveedores que faciliten una lista completa de componentes de software (SBOM), incluyendo las dependencias transitivas y todos los metadatos pertinentes.
- Actualizar y supervisar continuamente los inventarios de SBOM a medida que los componentes evolucionan o surgen nuevas vulnerabilidades.
4. Proveedores externos
Cada proveedor en el que confías pasa a formar parte de tu cadena de suministro. Si estos envían componentes obsoletos o comprometidos, tú asumes ese riesgo. Las listas completas de materiales (SBOM), que incluyen las dependencias transitivas, permiten comprender rápidamente tu exposición al riesgo, en lugar de tener que perseguir a los proveedores durante un incidente. Una publicación reciente sobre la gestión de vulnerabilidades de dependencia enSupply Chain Software analiza cómo los equipos pueden reforzar esta parte del proceso.
5. La IA en Supply Chain
Debido a la rápida adopción de la IA, los equipos suelen eludir las restricciones habituales, lo que convierte esto en un importante vector de ataque. Los atacantes inyectan código malicioso en modelos de aprendizaje automático, archivos PICO o bibliotecas de código abierto. El typosquatting es habitual en entornos como PyTorch, donde los usuarios pueden descargar la biblioteca equivocada, lo que puede introducir malware y dar lugar a la ejecución remota completa de código en el equipo de un ingeniero.
6.Container
El análisis de contenedores debe ir más allá de centrarse únicamente en las vulnerabilidades. La seguridad moderna también debe detectar malware, mineros de criptomonedas y amenazas de rápida propagación publicadas en imágenes de contenedores de acceso público. Un análisis reciente del CVE-2024-0132 Container NVIDIA Container muestra lo fácil que es pasar por alto estos problemas.
7. Filtración de contraseñas y credenciales
Cuando los equipos trabajan con prisas, suelen incluir claves de acceso o credenciales de forma explícita en el código fuente durante las pruebas. Aunque posteriormente se sobrescriban, estos datos confidenciales suelen permanecer en el historial de Git, donde los atacantes pueden encontrarlos fácilmente mediante análisis. El artículo «Desenmascarando amenazas ocultas: cómo detectar datos confidenciales en el código» explica cómo se producen estas filtraciones y qué pueden hacer los equipos para evitarlas.
El camino hacia unaSupply ChainSoftware Secure
Para hacer frente a estas amenazas, el departamento de seguridad debe adoptar una mentalidad de «shift left», lo que significa que las mismas políticas que se aplican antes del lanzamiento deben aplicarse en una fase más temprana del ciclo de desarrollo. El objetivo es integrar la seguridad como una capa adicional sobre el proceso de CI/CD existente. Este enfoque automatizado garantiza el cumplimiento de las normas cuando es necesario, sin afectar a la productividad del equipo de ingeniería.
Una solución integral debe ofrecer:
- Escaneo automatizado de la cadena de suministro a lo largo de todo el proceso
- Visibilidad sobre el código fuente, los contenedores y los archivos proporcionados por los proveedores
- Análisis que va más allá de las vulnerabilidades CVE para detectar malware, problemas de licencias y secretos expuestos
Cómo OPSWAT a subsanar estas deficiencias
- Multiscanning detectar malware en una fase temprana del proceso
- Puertas de seguridad de CI/CD integradas para GitHub, GitLab, TeamCity, Jenkins y otras plataformas
- Generación automatizada de la lista de materiales de software (SBOM) y análisis de vulnerabilidades
- Firma de artefactos y validación de la integridad
- Escaneo de secretos y aplicación de prácticas de seguridad en las credenciales
Habla hoy mismo con uno de nuestros expertos para encontrar soluciones a medida para tu entorno tecnológico.
