SBOM en Ciberseguridad Industrial: Guía Práctica para Saber Qué Software Corre en Tu Planta

Keywords secundarias: software bill of materials industria, sbom ot, sbom nis2 cumplimiento, inventario software planta industrial, sbom herramientas ot, gestión vulnerabilidades industrial Fecha: 2026-08-13 Autor: Carlos @ automatizatodo.com Categoría: Ciberseguridad Industrial / OT

---

Si te pregunto ahora mismo qué versiones de firmware corren en los PLC de tu planta, qué librerías usa el SCADA y qué componentes open source tiene el gateway IoT que instalaste el año pasado — ¿podrías responderme? Si la respuesta es “no tengo ni idea”, tranquilo: estás en la misma situación que el 90% de las plantas industriales.

Eso es exactamente lo que un SBOM (Software Bill of Materials) resuelve. Y ya no es opcional: con NIS2 en vigor y los ataques a infraestructuras OT disparándose, saber qué software tienes es el primer paso para protegerlo. Esta guía de SBOM en ciberseguridad industrial te lleva del concepto a la implementación práctica, con herramientas reales y ejemplos de planta.

Qué es un SBOM y por qué debería importarte

Un SBOM es un inventario detallado de todos los componentes de software que forman un producto o sistema. Piensa en ello como la lista de ingredientes de un alimento, pero aplicada al software: qué librerías usa, qué versiones, quién las mantiene, bajo qué licencias y qué dependencias tienen.

En el mundo IT esto ya es práctica habitual. Herramientas como npm, pip o Maven generan listas de dependencias automáticamente. Pero en OT la cosa cambia radicalmente:

• Los fabricantes de PLC, HMI y SCADA raramente publican SBOMs. El firmware de un Siemens S7-1500 o un Allen-Bradley ControlLogix contiene decenas de componentes de terceros (pilas TCP/IP, servidores web embebidos, librerías criptográficas), pero el usuario final no sabe cuáles.
• Los sistemas llevan años sin actualizar. Es habitual encontrar HMIs con Windows XP Embedded o gateways con versiones de OpenSSL de 2018. Sin un SBOM, no puedes saber si te afecta una vulnerabilidad publicada ayer.
• La cadena de suministro es opaca. Un integrador monta un sistema con componentes de cinco fabricantes distintos. ¿Quién tiene la visión completa de qué software hay? Nadie.

El concepto no es nuevo. La NTIA (National Telecommunications and Information Administration) de EE.UU. empezó a trabajar en estándares SBOM en 2018. En 2021, la Orden Ejecutiva 14028 de Biden lo hizo obligatorio para proveedores del gobierno federal. Y en Europa, NIS2 ha puesto el tema sobre la mesa de los responsables de ciberseguridad industrial.

NIS2 y el SBOM: de recomendación a obligación

La Directiva NIS2 (Network and Information Security Directive 2), en vigor desde octubre de 2024, amplía las obligaciones de ciberseguridad a sectores industriales que antes quedaban fuera: energía, agua, alimentación, fabricación, transporte y gestión de residuos, entre otros.

¿Qué tiene que ver NIS2 con el SBOM? Directamente, varias cosas:

• Gestión de riesgos de la cadena de suministro. NIS2 obliga a las entidades esenciales e importantes a evaluar los riesgos de ciberseguridad en su cadena de suministro de software. Sin un SBOM, esa evaluación es papel mojado.
• Gestión de vulnerabilidades. Cuando se publica un CVE que afecta a una librería (Log4Shell es el ejemplo clásico), necesitas saber en segundos si tienes esa librería en tu planta. El SBOM te da esa respuesta.
• Notificación de incidentes. Si sufres un incidente, los reguladores van a preguntar qué software estaba implicado. “No lo sé” no es una respuesta aceptable bajo NIS2.
• Responsabilidad de la dirección. NIS2 hace responsables a los directivos de las medidas de ciberseguridad. Ignorar qué software corre en tus sistemas ya no es una opción sin consecuencias.

En España, la transposición de NIS2 refuerza el papel de INCIBE-CERT para la coordinación de vulnerabilidades en sectores estratégicos. Las empresas industriales que caen bajo el paraguas de NIS2 van a necesitar demostrar que gestionan su software de forma proactiva — y el SBOM es la herramienta para hacerlo.

Los tres formatos estándar de SBOM que debes conocer

No todo SBOM es igual. Existen tres formatos principales, y saber cuál usar te ahorra dolores de cabeza:

SPDX (Software Package Data Exchange)

Desarrollado por la Linux Foundation, SPDX es un estándar ISO (ISO/IEC 5962:2021). Se centra en la identificación precisa de componentes y licencias. Es el formato preferido por la comunidad open source y cada vez más adoptado en contextos regulatorios.

• Formato: JSON, RDF, YAML, XML o tag-value.
• Ideal para: Proyectos con fuerte componente open source, cumplimiento de licencias.
• Punto fuerte: Estándar ISO reconocido internacionalmente.

CycloneDX

Creado por OWASP, CycloneDX nació con un enfoque claro en seguridad. Además de listar componentes, permite incluir información de vulnerabilidades conocidas (VEX — Vulnerability Exploitability eXchange), dependencias y servicios.

• Formato: JSON o XML.
• Ideal para: Gestión de vulnerabilidades, análisis de seguridad, entornos donde la seguridad prima sobre la gestión de licencias.
• Punto fuerte: Soporte nativo de VEX, lo que facilita saber no solo qué tienes, sino si lo que tienes es vulnerable y explotable.

SWID Tags (Software Identification Tags)

Estándar ISO/IEC 19770-2. Menos usado en la práctica que SPDX y CycloneDX, pero relevante en entornos enterprise con gestión de activos de software (SAM).

• Formato: XML.
• Ideal para: Organizaciones que ya usan herramientas de gestión de activos de software tipo ServiceNow o Flexera.
• Punto fuerte: Integración con ITAM/SAM.

¿Mi recomendación para entornos industriales? CycloneDX. Su enfoque en seguridad y el soporte nativo de VEX lo hacen perfecto para OT, donde la prioridad es saber si tienes una vulnerabilidad explotable — no tanto quién tiene la licencia de qué librería.

El problema específico del SBOM en entornos OT

Generar un SBOM en IT es relativamente sencillo: escaneas el servidor, analizas los binarios, miras el gestor de paquetes y listo. En OT la historia es completamente distinta, y si no entiendes por qué, vas a chocar con un muro.

Firmware propietario y opaco

El firmware de un PLC, un variador de frecuencia o un relé de protección es una caja negra. Siemens no te va a dar la lista de librerías que usa TIA Portal internamente ni los componentes de terceros del firmware del S7-1500. Lo mismo aplica a Rockwell, ABB, Schneider y cualquier otro fabricante de automatización.

Esto significa que para los componentes más críticos de tu planta, el SBOM tiene que venir del fabricante. Y aquí está la buena noticia: la presión regulatoria está forzando a los fabricantes a proporcionar SBOMs. Siemens ya publica SBOMs parciales para algunos productos a través de su portal ProductCERT. Otros fabricantes están empezando.

Sistemas legacy sin soporte

¿Ese PC industrial con Windows 7 que lleva corriendo tu SCADA desde 2014? ¿El gateway Modbus con un Linux embebido que nadie ha actualizado en cinco años? Esos sistemas no tienen SBOM y probablemente nadie recuerde qué versiones de qué librerías hay dentro.

Para estos casos, la estrategia es el análisis pasivo: herramientas que inspeccionan el tráfico de red o escanean binarios sin necesidad de instalar nada en el equipo. Más adelante te explico cómo.

Redes aisladas y restricciones de escaneo

En muchas plantas, las redes OT están (o deberían estar) segmentadas de IT. Eso complica el despliegue de herramientas de inventario que necesitan conectividad. Además, hacer un escaneo activo (tipo Nessus) en una red OT puede tumbar un PLC o un HMI — algo que nadie quiere.

La regla de oro: en OT, siempre pasivo primero, activo solo con mucho cuidado y ventana de mantenimiento.

Ciclos de vida larguísimos

En IT actualizas un servidor cada 3-5 años. En OT hay equipos funcionando 15-20 años. Eso significa que el SBOM no es un documento estático — necesita mantenerse durante toda la vida útil del sistema, que en industria puede ser dos décadas.

Cómo generar un SBOM en tu planta: paso a paso

Vamos a la práctica. Este proceso está pensado para una planta industrial típica con una mezcla de sistemas modernos y legacy.

Paso 1: Inventaria tus activos OT

Antes de hablar de SBOM necesitas saber qué equipos tienes. Parece obvio, pero la mayoría de plantas no tienen un inventario actualizado de activos OT. Empieza con:

• PLCs y RTUs: Marca, modelo, versión de firmware.
• HMIs y paneles de operador: Sistema operativo, versión del software de visualización.
• SCADA/DCS: Servidores, estaciones de ingeniería, versiones de software.
• Gateways y pasarelas de protocolo: Firmware, protocolos soportados.
• Dispositivos IoT/IIoT: Sensores inteligentes, edge gateways, cámaras IP.
• PCs industriales: Sistema operativo, software instalado, librerías.

Herramientas como Nozomi Networks, Claroty o Dragos hacen inventario pasivo de redes OT analizando tráfico. Si no tienes presupuesto para estas soluciones comerciales, puedes empezar con GRASSMARLIN (de la NSA, open source) o simplemente con un documento estructurado y trabajo de campo.

Paso 2: Clasifica por criticidad

No todos los activos necesitan el mismo nivel de detalle en su SBOM. Clasifica en tres niveles:

• Nivel 1 — Crítico: Sistemas cuyo fallo detiene la producción o pone en riesgo la seguridad (SIS, PLC principales, SCADA central). Necesitan SBOM completo con seguimiento de vulnerabilidades.
• Nivel 2 — Importante: Sistemas auxiliares que afectan a la eficiencia pero no paran la planta (HMIs secundarios, gateways, historiadores). SBOM básico con revisión periódica.
• Nivel 3 — Bajo impacto: Sistemas de soporte (impresoras industriales, terminales de información). Inventario de software, sin SBOM detallado.

Paso 3: Solicita SBOMs a tus proveedores

Para el firmware propietario, la única vía es pedirlo al fabricante. Prepara una solicitud formal que incluya:

• Referencia al artículo 21 de NIS2 y la gestión de riesgos de la cadena de suministro.
• Formato solicitado (CycloneDX o SPDX).
• Lista específica de productos y versiones de firmware para los que necesitas el SBOM.
• Compromiso de confidencialidad si el fabricante lo requiere.

No todos los fabricantes responderán con un SBOM completo (todavía). Pero la presión de clientes es lo que está moviendo la industria. Cada solicitud cuenta.

Paso 4: Genera SBOMs para los sistemas que controlas

Para los equipos donde sí tienes acceso al software (PCs industriales, servidores SCADA, edge gateways Linux), puedes generar SBOMs tú mismo. Herramientas:

Syft (de Anchore) — Para sistemas Linux/contenedores:

# Instalar Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generar SBOM de un sistema Linux completo
syft dir:/ -o cyclonedx-json > sbom-servidor-scada.json

# Generar SBOM de una imagen Docker
syft docker:mi-gateway-iot:latest -o cyclonedx-json > sbom-gateway.json

cdxgen — Para proyectos de software y aplicaciones:

# Instalar cdxgen
npm install -g @cyclonedx/cdxgen

# Generar SBOM de un proyecto Python (ej: tu aplicación de monitorización)
cdxgen -t python -o sbom-app-monitorizacion.json /ruta/al/proyecto

Microsoft SBOM Tool — Para entornos Windows:

# Descargar desde GitHub: microsoft/sbom-tool
# Generar SBOM de una carpeta de instalación
sbom-tool generate -b C:\SCADA\Instalacion -bc C:\SCADA -pn "SCADA-Planta" -pv "3.2.1" -ps "MiEmpresa"

Paso 5: Automatiza el análisis de vulnerabilidades

Tener un SBOM sin analizar vulnerabilidades es como tener la lista de ingredientes de un alimento sin comprobar si alguno está en mal estado. Herramientas para cruzar tu SBOM con bases de datos de vulnerabilidades:

Grype (de Anchore) — Análisis de vulnerabilidades sobre SBOM:

# Instalar Grype
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Analizar el SBOM que generaste
grype sbom:sbom-servidor-scada.json

# Filtrar solo vulnerabilidades críticas y altas
grype sbom:sbom-servidor-scada.json --only-fixed --fail-on high

Dependency-Track (OWASP) — Plataforma completa de gestión de SBOM:

Dependency-Track es una aplicación web que importa SBOMs, los almacena, monitoriza vulnerabilidades continuamente y genera alertas. Es open source y es probablemente la herramienta más completa para gestionar SBOMs a escala.

# Desplegar con Docker Compose
docker compose -f docker-compose-bundled.yml up -d

# Acceder en http://localhost:8080
# Importar SBOMs vía API o interfaz web

Para entornos industriales, Dependency-Track es oro: lo despliegas en un servidor de la zona DMZ, importas los SBOMs de todos tus activos y tienes un panel centralizado de vulnerabilidades que se actualiza automáticamente cuando se publican nuevos CVEs.

Paso 6: Establece un proceso de mantenimiento

El SBOM no es un documento que generas una vez y guardas en un cajón. Define:

• Frecuencia de actualización: Cada vez que actualices firmware, software o apliques parches. Mínimo una revisión trimestral.
• Responsable: Alguien (persona o equipo) tiene que ser dueño del proceso. En muchas plantas el responsable natural es el ingeniero de automatización con soporte de IT/ciberseguridad.
• Alertas de vulnerabilidades: Configura Dependency-Track o equivalente para que te envíe alertas cuando se publique un CVE que afecte a algún componente de tus SBOMs.
• Revisión de proveedores: Una vez al año, solicita SBOMs actualizados a tus fabricantes de equipos OT.

Caso práctico: SBOM en una planta de tratamiento de aguas

Para aterrizar todo esto, veamos cómo se aplicaría en una planta ETAP (Estación de Tratamiento de Agua Potable) — un escenario típico en infraestructuras críticas reguladas por NIS2.

Activos identificados:

Equipo	Tipo	Software / Firmware
PLC principal	Siemens S7-1500	FW V3.0.2
HMI	Siemens Comfort Panel	WinCC V18
SCADA	Servidor Windows + WinCC OA	V3.19
Gateway IoT	Linux embebido (Raspberry Pi)	Debian 11 + Python + MQTT
RTU remota	Schneider M580	FW V4.10
Historiador	OSIsoft PI	2023 R2

Acciones:

1. PLC Siemens y RTU Schneider: Solicitar SBOM al fabricante vía canal de soporte/ciberseguridad. Referenciar NIS2.
2. SCADA y HMI: SBOM parcial generado con herramientas de inventario sobre el servidor Windows. Complementar con información del fabricante.
3. Gateway IoT (Linux): SBOM completo generado con Syft. Análisis de vulnerabilidades con Grype. Resultado: se detectan 3 CVEs críticas en la versión de OpenSSL instalada → actualización programada.
4. Historiador OSIsoft: Solicitar SBOM a AVEVA (ahora propietaria). Mientras tanto, inventario de componentes .NET y librerías de terceros.

Resultado: En dos semanas, la planta pasa de “no sabemos qué software tenemos” a un inventario completo con seguimiento de vulnerabilidades. El SBOM del gateway IoT permite detectar y parchear tres vulnerabilidades críticas antes de que un atacante las explote.

Errores comunes al implementar SBOM en industria

Después de ver varios intentos de implementación, estos son los errores que se repiten:

Querer empezar por todo a la vez

No intentes generar SBOMs de los 200 equipos de tu planta en un mes. Empieza por los 10-15 activos más críticos (nivel 1) y expande gradualmente. Un SBOM incompleto de tus sistemas críticos es infinitamente más valioso que no tener ninguno.

Ignorar el firmware de los dispositivos de red OT

Switches industriales, firewalls OT, routers de celda — también tienen firmware con componentes vulnerables. El caso de VPNFilter (malware que infectó routers industriales explotando vulnerabilidades conocidas) demostró que estos dispositivos son vectores de ataque reales.

No integrar el SBOM con la gestión de vulnerabilidades

Un SBOM almacenado en un Excel en una carpeta compartida no sirve de nada. Tiene que estar conectado a un sistema que cruce componentes con CVEs en tiempo real. Dependency-Track hace esto automáticamente.

Olvidar las estaciones de ingeniería

Las estaciones de ingeniería (donde se programa TIA Portal, Studio 5000, etc.) tienen decenas de componentes de software, plugins y librerías. Son un vector de ataque frecuente (malware que se distribuye a través de proyectos de ingeniería infectados) y necesitan SBOM tanto como el propio PLC.

Tratar el SBOM como proyecto de IT, no de OT

Si IT lidera la iniciativa SBOM sin involucrar al equipo de automatización/OT, el resultado será un inventario de servidores Windows con cero visibilidad sobre los PLCs, HMIs y controladores que son el verdadero objetivo de los ataques. El SBOM industrial necesita a alguien que entienda la planta.

Herramientas clave para SBOM industrial: resumen

Herramienta	Función	Coste	Ideal para
Syft	Generar SBOMs (Linux, contenedores)	Gratis (open source)	Gateways IoT, servidores Linux
Grype	Análisis de vulnerabilidades sobre SBOM	Gratis (open source)	Validación rápida de CVEs
Dependency-Track	Plataforma centralizada de gestión SBOM	Gratis (open source)	Gestión a escala, alertas continuas
cdxgen	Generar SBOMs de proyectos software	Gratis (open source)	Aplicaciones Python, Node.js, Java
Microsoft SBOM Tool	Generar SBOMs en Windows	Gratis (open source)	Servidores SCADA Windows
Nozomi/Claroty/Dragos	Inventario pasivo + detección OT	Comercial (~50K€+/año)	Redes OT grandes, tiempo real
GRASSMARLIN	Mapeo pasivo de redes ICS	Gratis (NSA, open source)	Primer inventario sin presupuesto

El SBOM como pieza del puzzle de ciberseguridad OT

El SBOM no es la solución a todos los problemas de ciberseguridad industrial. Es una pieza — fundamental, pero una pieza — de una estrategia más amplia que incluye:

• Segmentación de red OT/IT según IEC 62443 y el modelo Purdue.
• Monitorización de tráfico OT para detectar anomalías.
• Gestión de parches OT con ventanas de mantenimiento planificadas.
• Respuesta a incidentes adaptada a entornos industriales.
• Formación del personal de planta en ciberseguridad básica.

El SBOM encaja como la base de la gestión de vulnerabilidades: si no sabes qué tienes, no puedes protegerlo. Es así de simple. Si quieres una visión más amplia del panorama de ciberseguridad en entornos industriales, te recomiendo leer nuestra guía de ciberseguridad industrial OT.

Con NIS2 en vigor y la Cyber Resilience Act (CRA) europea avanzando hacia su implementación (que hará obligatorio el SBOM para cualquier producto con elementos digitales vendido en la UE), las empresas industriales que empiecen ahora van a estar un paso por delante cuando la normativa apriete de verdad.

Próximos pasos y recursos

Si quieres profundizar en SBOM para ciberseguridad industrial, estos recursos son punto de partida sólido:

• CISA — Software Bill of Materials (SBOM) — Portal oficial con documentación, guías y recursos de la agencia de ciberseguridad de EE.UU.
• OWASP Dependency-Track — Documentación y despliegue de la plataforma open source de gestión de SBOM.
• IEC 62443 — La norma de referencia para ciberseguridad de sistemas de automatización industrial.

---

¿Necesitas ayuda para implementar SBOMs en tu planta o cumplir con NIS2? En automatizatodo.com ayudamos a empresas industriales a poner en marcha programas de ciberseguridad OT con enfoque práctico y sin complicaciones innecesarias. Contacta con nosotros y hablamos.