¿Qué es un SBOM y por qué importa?
Respuesta breve
Un SBOM es un inventario legible por máquina de cada componente, biblioteca y dependencia de un software, con versiones e idealmente hashes. Importa porque cuando aparece una nueva vulnerabilidad, puedes consultar tus SBOM para responder al instante a «¿estamos afectados y dónde?» en lugar de improvisar. Los dos estándares dominantes son SPDX y CycloneDX, y los SBOM son cada vez más exigidos por la normativa y las compras.
Un Software Bill of Materials (SBOM) es al software lo que una etiqueta de ingredientes es a los alimentos: una lista completa y legible por máquina de lo que hay dentro.
Qué contiene
Un SBOM enumera cada componente que compone una aplicación — dependencias directas y transitivas, sus versiones, proveedores e idealmente los hashes criptográficos y los datos de licencia. También captura las relaciones, así que puedes ver qué componente depende de cuál. Como es información estructurada, las herramientas pueden consumirlo automáticamente en vez de que un humano lea una lista.
Por qué importa
El caso de uso estrella es la velocidad de respuesta a incidentes. Cuando se divulgó Log4Shell, las organizaciones pasaron días o semanas solo averiguando si usaban Log4j vulnerable y dónde. Con SBOM archivados para cada build, eso se convierte en una consulta: «muéstrame cada artefacto que contenga log4j-core < 2.17». Más allá de los incidentes, los SBOM apoyan el cumplimiento de licencias, la evaluación de riesgo de proveedores y — cada vez más — los requisitos normativos y de compras (p. ej. la Executive Order 14028 de EE. UU. impulsó los SBOM en las cadenas de suministro de software federales).
Los dos estándares
- SPDX — un estándar ISO/IEC originalmente centrado en el cumplimiento de licencias, ahora amplio.
- CycloneDX — un proyecto de OWASP diseñado con la seguridad primero, con fuerte soporte para vulnerabilidades (VEX) y relaciones de dependencias.
La mayoría de las herramientas pueden emitir ambos. Genera el SBOM durante el build, no después, para que refleje exactamente lo que se entregó, y guárdalo como un artefacto versionado junto al binario.
Lo que buscan los entrevistadores
Quieren el enfoque de respuesta a incidentes, conocimiento de SPDX frente a CycloneDX, y la idea de que un SBOM solo es útil si se genera en el momento del build y realmente se almacena y se puede consultar.
Posibles preguntas de seguimiento
- ¿Cuáles son las diferencias entre SPDX y CycloneDX?
- ¿En qué punto del pipeline debe generarse un SBOM?
- ¿Cómo ayuda un SBOM durante un incidente como Log4Shell?