Introducción SBOMs
¿Qué es un SBOM?
Un Software Bill of Materials (SBOM) es un inventario estructurado de los componentes que forman parte de una aplicación o artefacto de software. En términos simples, cumple un rol similar al de una lista de ingredientes: identifica bibliotecas, paquetes, dependencias, herramientas y otros elementos utilizados durante el desarrollo, la compilación y la distribución de un sistema. Su valor no está solo en enumerar componentes, sino también en aportar contexto sobre su origen, sus versiones y la relación que mantienen entre sí.
En el desarrollo moderno, donde es habitual reutilizar paquetes de código abierto, imágenes de contenedores y dependencias de terceros, contar con esa visibilidad se ha vuelto especialmente importante. Un SBOM permite comprender mejor qué software se está utilizando realmente, qué tan amplio es el árbol de dependencias y cuáles son los puntos que podrían requerir revisión desde una perspectiva de seguridad, cumplimiento o mantenimiento.
¿Por qué los SBOMs han tomado tanta relevancia?
La seguridad de la cadena de suministro de software se ha convertido en una preocupación central para organizaciones públicas y privadas. Incidentes ampliamente conocidos, como ataques a proveedores de software o vulnerabilidades críticas en componentes reutilizados de manera masiva, han demostrado que no basta con revisar solo el código propio. También es necesario saber con precisión qué componentes externos forman parte de una solución y cómo impactan en su nivel de riesgo.
En ese contexto, los SBOMs aportan una base concreta para mejorar la trazabilidad y la transparencia. Permiten identificar dependencias potencialmente vulnerables, revisar si existen licencias incompatibles con políticas internas y fortalecer la capacidad de respuesta ante nuevos hallazgos de seguridad. Además, su adopción ha ido creciendo no solo por razones técnicas, sino también por exigencias regulatorias y por una demanda cada vez mayor de evidencia sobre el origen y la composición del software.
Estándares y automatización
Para que un SBOM sea realmente útil, su generación e interpretación deben poder automatizarse. Por eso existen estándares de intercambio que facilitan producir, compartir y procesar esta información de manera consistente. Entre los formatos más conocidos se encuentran CycloneDX, actualmente desarrollado como estándar abierto para transparencia de la cadena de suministro, y SPDX, estándar internacional abierto utilizado ampliamente para describir componentes, licencias y relaciones entre artefactos de software. Ambos son ampliamente utilizados en prácticas de seguridad y cumplimiento.
La automatización es clave porque un SBOM pierde valor si se genera una sola vez y luego queda desactualizado. En entornos de desarrollo continuos, donde cambian dependencias, versiones y artefactos con frecuencia, lo recomendable es integrar la generación de SBOMs al flujo de trabajo habitual. De esa forma, el inventario puede mantenerse vigente y complementarse con procesos de análisis de vulnerabilidades y revisión de licencias.
Como referencia institucional más general sobre el tema, también resulta útil revisar los materiales de CISA sobre SBOM y los recursos de NTIA sobre Software Bill of Materials, ya que ambos reúnen lineamientos, definiciones y documentos introductorios ampliamente utilizados en la conversación pública sobre transparencia de componentes de software.
Contenido del Módulo
En este módulo, los materiales siguientes aterrizan esta idea general en un contexto práctico. Por una parte, se muestra cómo generar SBOMs para un conjunto de repositorios y cómo aprovechar esos resultados para obtener una visión consolidada de los componentes detectados. Por otra, se presenta la lógica general del script que automatiza ese proceso, de modo que resulte claro cómo llevar esta práctica desde una explicación conceptual a una ejecución reproducible.
Así, esta introducción busca responder el por qué de los SBOMs, mientras que los notebooks posteriores desarrollan el cómo incorporarlos a un flujo de trabajo real. La combinación de ambas perspectivas es relevante: no se trata solo de producir archivos con dependencias, sino de entender por qué esos datos son útiles para la gestión de riesgos, la observabilidad del software y la seguridad de la cadena de suministro.