¿Qué es una SBOM? La lista de materiales de software

¿Por qué se necesita una SBOM?

El software moderno está compuesto en gran medida por código externo: bibliotecas de código abierto, frameworks y dependencias que a su vez traen más dependencias. Sin una lista de piezas (SBOM), a menudo nadie sabe con precisión qué contiene un producto. Exactamente esta ceguera se convirtió en un problema en Log4Shell, cuando la ampliamente utilizada biblioteca Log4j tenía una vulnerabilidad crítica.

La pregunta crucial entonces en cada empresa era: ¿Qué de nuestras aplicaciones contiene Log4j en absoluto? Quien mantiene una SBOM por producto, responde mediante una consulta. Quien no la tiene, busca manualmente a través de todo el panorama de software. La SBOM transforma una búsqueda que dura días en una verificación dirigida.

Qué constituye una SBOM adecuada

Una SBOM es más que un anexo PDF. Para aportar valor, debe ser legible por máquinas y poder evaluarse automáticamente. Se han establecido dos formatos: SPDX del entorno Linux y CycloneDX del ámbito de la seguridad de aplicaciones. Ambos describen componentes, versiones y relaciones en una forma estructurada.

Lo importante también es la actualidad. Una SBOM que solo se crea en el lanzamiento y nunca se actualiza queda obsoleta con cada actualización. Lo adecuado es generar la SBOM automáticamente en el proceso de compilación, de modo que cada versión tenga su propia lista de componentes correcta. Sólo entonces se puede comparar confiablemente una nueva vulnerabilidad con el inventario.

Qué cambia con el Cyber Resilience Act

El Cyber Resilience Act (Reglamento (UE) 2024/2847) obliga a los fabricantes de productos con elementos digitales a una mayor seguridad a lo largo de todo el ciclo de vida. La parte II del anexo I exige explícitamente que los fabricantes elaboren una SBOM en un formato legible por máquinas y ampliamente utilizado, que cubra al menos los componentes y dependencias de nivel superior. Es parte de la documentación técnica y debe estar disponible para las autoridades de supervisión, sin que se requiera su publicación a los usuarios finales.

Las obligaciones se implementan de forma escalonada: las obligaciones de notificación de vulnerabilidades activamente explotadas y de incidentes graves entrarán en vigor el 11. septiembre de 2026, mientras que el resto de las obligaciones del CRA lo harán el 11. diciembre de 2027. Para los fabricantes, esto significa establecer la SBOM como una parte fija del proceso de desarrollo. Quienes la integren desde el principio cumplen con las próximas obligaciones con mucho menos esfuerzo que quienes la adopten después.

Cómo una SBOM sigue viva en funcionamiento

Una SBOM (lista de componentes del software) solo muestra su valor durante la operación activa. Cada día aparecen nuevas vulnerabilidades, por eso la lista de materiales debe compararse continuamente con las bases de datos de vulnerabilidades actuales. Sólo este intercambio automático convierte la lista estática en un sistema de alerta temprana que indica inmediatamente los productos afectados cuando surge una nueva brecha.

Además, se ha establecido el concepto VEX, abreviatura de Vulnerability Exploitability eXchange. Con ello, los fabricantes informan si una vulnerabilidad incluida en la SBOM es realmente exploitable en el producto concreto. Esto evita falsas alarmas cuando la biblioteca afectada está presente, pero el código vulnerable no está activo. SBOM y VEX juntos ofrecen una visión realista de la superficie de ataque efectiva.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿Cuál es la diferencia entre SPDX y CycloneDX?

Ambos son formatos de Software Bill of Materials (SBOM) consolidados. El SPDX proviene del entorno del código abierto y está ampliamente estandarizado, mientras que CycloneDX se originó en el ámbito de la seguridad de aplicaciones. Ambos son legibles por máquinas y aptos para comparar con bases de datos de vulnerabilidades.

¿Obliga el Acta de Resiliencia Cibernética a los SBOM?

Sí. El Anexo I Parte II del Reglamento (EU) 2024/2847 obliga a los fabricantes a elaborar una lista de materiales de software (SBOM) legible por máquina y a mantenerla en la documentación técnica. La publicación pública a los clientes finales no está obligatoria.

¿Basta con una SBOM una vez por producto?

No. Cada versión de software debería tener su propia SBOM, porque los componentes y versiones cambian con cada actualización. Lo ideal es que se genere automáticamente durante el proceso de compilación.

¿Ayuda un SBOM (Software Bill of Materials) contra ataques?

No impide el ataque, pero reduce significativamente el tiempo de respuesta. Ante una nueva vulnerabilidad, la SBOM muestra de inmediato qué productos están afectados, en lugar de desencadenar una búsqueda manual laboriosa.

¿Debe exigirse la lista de materiales de software (SBOM) a los proveedores?

Sí. Quien compre o integre software debe exigir una SBOM (lista de materiales de software) para poder supervisar su propia cadena de suministro. Sin esta información, una parte del riesgo permanece invisible.

Selección de la redacción

RecomendadoDos vulnerabilidades de Joomla en la lista KEV de CISA

Más de la red MBF Media

Digital ChiefsCinco lugares donde se rompe el software de la cadena de suministrocloudmagazinFlexera 2026: Lo que la pyme realmente puede asumirMyBusinessFuturePasaporte digital de producto: qué deben hacer los fabricantes