Seguridad en la cadena de suministro de contenedores
La seguridad de la cadena de suministro de contenedores exige imágenes verificadas, SBOM y controles antes del despliegue.
La seguridad de la cadena de suministro de contenedores exige controles antes del despliegue, no solo después del incidente.
Lo esencial en breve
- 604 vulnerabilidades por imagen: Las 70 imágenes de contenedores de Docker Hub más utilizadas contienen, en promedio, 604 vulnerabilidades conocidas, más del 40 % de ellas críticas o altas (NetRise, diciembre 2024).
- 75 % afectadas: Tres de cada cuatro organizaciones experimentaron, en el transcurso de un año, un ataque a la cadena de suministro de software (BlackBerry, 2024).
- 704.102 paquetes maliciosos: Desde 2019 se han identificado más de 700 000 paquetes dañinos en repositorios públicos, con un crecimiento del 156 % respecto al año anterior (Sonatype, 2024).
- Obligación de SBOM a partir de 2027: El EU Cyber Resilience Act exige Software Bills of Materials legibles por máquina para todos los productos digitales. Sanciones: hasta 15 millones de euros (EU CRA, 2024).
- NIS2 afecta directamente a la logística: Transporte, almacén y expedición forman parte de los sectores incluidos. Obligación de notificación: 24 horas después del descubrimiento de un incidente.
Por qué la cadena de suministro de software es la nueva puerta de entrada
La superficie de ataque se ha desplazado. En lugar de atacar directamente a empresas individuales, los atacantes comprometen componentes de software que miles de organizaciones utilizan simultáneamente. El incidente XZ-Utils de marzo 2024 (CVE‑2024‑3094, CVSS 10.0) demostró el riesgo: un único atacante infiltró, durante tres años, un proyecto de código abierto – de forma similar a la campaña GlassWorm de marzo 2026 – y colocó una puerta trasera que habría permitido la ejecución remota de código a través de SSH. El ataque solo se descubrió por casualidad, cuando un desarrollador de Microsoft notó una demora inusual (CISA Alert, marzo 2024).
Para la logística el riesgo es especialmente alto. NotPetya demostró en 2017 lo que ocurre cuando una actualización de software comprometida afecta a una cadena de suministro: Maersk perdió el acceso a unas 50 000 terminales y a 76 puertos en 130 países. El daño: alrededor de 300 millones de dólares estadounidenses solo en Maersk, con una estimación global de 10 mil millones de dólares (CSOOnline).
Fuente: NetRise Supply Chain Visibility Study, diciembre 2024
Qué contiene los contenedores
El estudio NetRise de diciembre 2024 analizó las 70 imágenes de contenedores de Docker Hub más utilizadas y encontró, en promedio, 604 vulnerabilidades conocidas por imagen. Más del 40 % de ellas se clasifican como críticas o altas. Cada imagen contiene, en promedio, 389 componentes de software, y en una de cada ocho componentes falta cualquier manifiesto de software (Help Net Security, 2024).
Más del 45 % de las vulnerabilidades detectadas tienen entre dos y diez años. Esto significa que vulnerabilidades conocidas y ya parcheadas se reintroducen en nuevos despliegues mediante imágenes base obsoletas. Synopsys confirma la tendencia: el 91 % de las bases de código comerciales auditadas contienen componentes que tienen al menos diez versiones de antigüedad (OSSRA Report, 2024).
Los vectores de ataque: paquetes maliciosos en repositorios públicos
Sonatype identificó hasta agosto de 2024 un total de 704.102 paquetes maliciosos en repositorios públicos como npm, PyPI y Maven Central. El crecimiento respecto al año anterior: 156 por ciento. En 2024 se descubrieron más de 400.000 nuevos paquetes maliciosos. Con 6.600 mil millones de descargas de código abierto previstas hasta finales de 2024, la superficie de ataque crece más rápido que la capacidad de defensa (Sonatype, 10.º State of the Software Supply Chain Report).
La consecuencia para la TI logística: cualquier software de gestión de almacenes, cualquier sistema de gestión de transporte y cualquier plataforma IoT para el seguimiento de flotas se basan en componentes de código abierto. Quien no conoce el origen de esos componentes tiene un punto ciego en su propia arquitectura de seguridad.
SBOM: la lista de materiales para software
Un Software Bill of Materials enumera todos los componentes de una aplicación, incluidas versiones, licencias y vulnerabilidades conocidas. Lo que en la cadena de suministro física es evidente (todo logista conoce el contenido de sus contenedores), a menudo falta por completo en la cadena de suministro de software.
El mercado de SBOM crece en consonancia: de aproximadamente 1,2 mil millones de dólares en 2024 a unos 6,2 mil millones previstos para 2033, con una tasa de crecimiento anual del 21,5 por ciento (Anchore, 2025). Las grandes empresas representan el 58 por ciento de los usuarios. Herramientas como Trivy (código abierto, de Aqua Security), Snyk Container y Sysdig generan SBOMs automáticamente como parte de la canalización CI/CD.
CRA y NIS2: llega la regulación
El EU Cyber Resilience Act (Reglamento 2024/2847) está en vigor desde diciembre de 2024 y afecta a todos los productos con elementos digitales que se venden en la UE. A partir del 11 de septiembre de 2026 deberán notificarse las vulnerabilidades activamente explotadas. A partir del 11 de diciembre de 2027 será obligatoria una SBOM legible por máquinas. No se prescribe un formato, considerándose aceptados estándares como SPDX y CycloneDX. Las infracciones pueden costar hasta 15 millones de euros o el 2,5 por ciento de la facturación anual global (EU Digital Strategy).
NIS2 afecta a la logística de forma aún más directa. El transporte, el almacenamiento, la expedición y los servicios de mensajería forman parte de los sectores cubiertos. Las empresas con más de 50 empleados o con una facturación superior a 10 millones de euros quedan sujetas a la directiva. Los requisitos del artículo 21 incluyen expresamente la evaluación y aseguramiento de todos los proveedores y subcontratistas de TIC. Los incidentes deben notificarse en un plazo de 24 horas, evaluarse en 72 horas y reportarse de forma definitiva en un mes. La responsabilidad personal de la dirección en caso de negligencia aumenta la presión adicionalmente (nFlo, Dataguard).
Seguridad de contenedores en la práctica
El mercado de seguridad de contenedores alcanzó en 2024 los 2,87 mil millones de dólares y se prevé que crezca hasta 14,09 mil millones para 2032 (MarketsandMarkets). Las herramientas están maduras: Trivy escanea imágenes de contenedores, archivos Infrastructure-as-Code y SBOMs en segundos. Sysdig utiliza eBPF para detección en tiempo real directamente en el clúster Kubernetes. Snyk Container se integra en el IDE y genera pull‑requests de corrección automáticos.
Para los equipos de TI logística la recomendación práctica es: actualizar regularmente las imágenes base (el 45 por ciento de vulnerabilidades conocidas durante años es evitable), incorporar la generación de SBOM en la canalización CI/CD y obligar al escaneo del registro antes de cada despliegue. Quien esté sujeto a NIS2 debe documentar estas medidas de todos modos.
Conclusión
La cadena de suministro de software es hoy la superficie de ataque más crítica para las empresas logísticas. 604 vulnerabilidades por imagen de contenedor, 704.000 paquetes maliciosos en repositorios públicos y un entorno regulatorio que obliga a la transparencia. SBOM, escaneo de contenedores y seguridad de la cadena de suministro no son innovaciones. Son requisitos de cumplimiento con fecha límite, similar a los riesgos de vendor lock‑in con VMware.
Preguntas frecuentes
¿Qué es una Software Bill of Materials (SBOM)?
Una SBOM es una lista legible por máquina de todos los componentes de software de una aplicación, incluidas versiones, licencias y vulnerabilidades conocidas. Hace transparente la composición del software, de forma similar a una lista de ingredientes en los alimentos. El EU Cyber Resilience Act obliga a usar SBOMs a partir de diciembre de 2027 para todos los productos digitales.
¿Afecta NIS2 también a las empresas logísticas medianas?
Sí, si emplean a más de 50 trabajadores o generan más de 10 millones de euros de facturación. El transporte, el almacenamiento, la expedición y los servicios de mensajería forman parte explícita de los sectores cubiertos. Los requisitos incluyen, entre otros, la garantía de seguridad de todos los proveedores de TIC y una obligación de notificación en un plazo de 24 horas.
¿Cuál es la diferencia entre CRA y NIS2 en la seguridad del software?
El CRA regula la seguridad de los productos con elementos digitales (software y hardware) y se dirige a los fabricantes. NIS2 regula la ciberseguridad de las organizaciones en sectores críticos y se dirige a los operadores. Para las empresas logísticas esto significa: el CRA afecta al software utilizado, NIS2 afecta a la propia organización. Ambos exigen transparencia sobre la cadena de suministro de software.
¿Cómo encuentro vulnerabilidades en mis imágenes de contenedores?
Herramientas de código abierto como Trivy (Aqua Security) escanean imágenes de contenedores en segundos y proporcionan una lista detallada de todas las vulnerabilidades con puntuaciones CVSS. Plataformas comerciales como Snyk, Sysdig y Aqua Security ofrecen, además, correcciones automáticas, aplicación de políticas e integración en pipelines CI/CD.
¿Con qué frecuencia deberían actualizarse las imágenes base?
Al menos mensualmente, y de forma inmediata ante vulnerabilidades críticas. El estudio NetRise muestra que más del 45 % de las vulnerabilidades en imágenes de contenedores tienen entre dos y diez años. Las pipelines de reconstrucción automatizadas, que vuelven a generar las imágenes base de forma regular, eliminan este riesgo en gran medida.
Lectura adicional
- Seguridad de la cadena de suministro de contenedores: Docker y SBOM – cloudmagazin
- NIS2 y cadena de suministro SaaS: brecha de cumplimiento – cloudmagazin
Más del MBF Media Network
- GlassWorm: más de 400 herramientas de desarrollo comprometidas – SecurityToday
- CSRD y sostenibilidad en la dirección – Digital Chiefs
- Cyber Resilience Act: lo que los fabricantes deben hacer – MyBusinessFuture
Fuente imagen de portada: Pexels / Markus Spiske (px:2061168)
