Seguridad en la cadena de suministro de software: cómo las SBOM generan la transparencia que ha faltado
SolarWinds, Log4Shell, MOVEit – cada gran ataque a la cadena de suministro de los últimos años podría haberse contenido más rápidamente con una Lista de materiales de software (SBOM). Las SBOM enumeran cada componente del software y permiten determinar en minutos lo que sin ellas llevaría semanas: saber si uno está afectado.
En resumen
- La Orden Ejecutiva de EE.UU. 14028 hace obligatoria la SBOM para proveedores de agencias federales
- La Ley de Resiliencia Cibernética de la UE exige SBOM a partir de 2027 para todos los productos digitales
- Formatos: SPDX (Linux Foundation) y CycloneDX (OWASP)
- La NTIA define requisitos mínimos: Proveedor, Componente, Versión, Dependencia
Qué es exactamente una SBOM
Una SBOM es una lista legible por máquina de todos los componentes del software: bibliotecas, frameworks, dependencias – con nombre, versión, licencia y origen. Es comparable a una lista de ingredientes en los alimentos: se sabe qué contiene.
En la práctica: cuando se descubre una nueva vulnerabilidad como Log4Shell, una empresa con SBOM puede determinar en minutos qué productos incluyen el componente afectado. Sin SBOM, comienza una búsqueda manual que puede durar semanas.
La presión regulatoria aumenta
Estados Unidos ha tomado la delantera: la Orden Ejecutiva 14028 obliga a los proveedores de software del gobierno federal a proporcionar SBOM. La UE sigue con la Ley de Resiliencia Cibernética (CRA), que exige SBOM a partir de 2027 para todos los productos digitales vendidos en la UE.
Para las empresas de software alemanas y fabricantes de productos digitales, esto es una cuenta atrás: quien no pueda entregar una SBOM en 2027, perderá el acceso al mercado – tanto en Estados Unidos como en la UE.
Integración en el proceso de desarrollo
Las SBOM no deben crearse a posteriori, sino generarse automáticamente durante el proceso de compilación. Herramientas como Syft, Trivy, CycloneDX CLI o las herramientas SPDX se integran en las canalizaciones CI/CD y generan SBOM con cada lanzamiento.
El flujo de trabajo: la compilación genera la SBOM, la SBOM se verifica contra bases de datos de vulnerabilidades (NVD, OSV), y si se detectan problemas críticos, el lanzamiento se bloquea. Esto es DevSecOps en la práctica – transparencia como estándar de calidad automatizado.
SBOM-Management: más que solo crearla
Generar una SBOM es solo el primer paso. El verdadero valor surge del manejo continuo de la SBOM: nuevas CVE se verifican automáticamente contra las SBOM existentes, los clientes reciben notificaciones proactivas si hay componentes afectados, y la SBOM se actualiza con cada nueva versión.
Plataformas como Dependency-Track (OWASP, código abierto) o soluciones comerciales como Anchore y Sonatype automatizan este ciclo de vida. El esfuerzo es reducido – el beneficio en caso de incidente, enorme.
Datos clave
Transparencia: la SBOM reduce el tiempo de reacción ante nuevas CVE de semanas a minutos
Regulación: la EO 14028 de EE.UU. y la CRA de la UE hacen obligatoria la SBOM hasta 2027
Adopción: la creación de SBOM aumentó un 300 por ciento tras Log4Shell (Sonatype)
Preguntas frecuentes
Cada pregunta está bloqueada. Un toque desbloquea la respuesta.
¿Qué formato debo utilizar?
CycloneDX (OWASP) para SBOM centradas en seguridad, SPDX (Linux Foundation) para cumplimiento de licencias. Ambos formatos son legibles por máquina y se pueden convertir entre sí. CycloneDX tiene mejor integración con VEX (Vulnerability Exploitability eXchange).
¿Debo crear SBOM para dependencias de código abierto?
Sí – precisamente aquí reside el mayor beneficio. La mayoría de las aplicaciones modernas están compuestas en un 70-90 por ciento por componentes de código abierto. Sin SBOM de estas dependencias, la gestión de vulnerabilidades es ciega.
¿Cómo comparto SBOM con mis clientes?
Tres modelos: entrega directa con cada lanzamiento, acceso a un portal de SBOM o entrega bajo demanda. Es probable que la CRA exija la entrega proactiva. Establezca ahora un proceso antes de que entre en vigor la obligación.
Artículos relacionados
- El código abierto es el mayor riesgo de seguridad del mundo – y todos lo ignoramos
- Seguridad por diseño en el desarrollo de software: por qué parchear a posteriori no es suficiente
- El hackeo de MOVEit: anatomía de un ataque a la cadena de suministro que afectó a miles
Más del ecosistema MBF Media
