SBOM: conocer lo que se instala, controlar lo que se expone

• Alex De los Llanos Dueñas
• Mayo 2025

A medida que el software se vuelve más complejo, más conectado y más rápido de desplegar, también se vuelve más opaco. Hoy en día, una aplicación ya no está compuesta únicamente por el código que desarrolla un equipo interno. De hecho, ese código es, en muchos casos, solo una parte del total. La mayor parte del software moderno se construye a partir de componentes externos, bibliotecas de terceros, frameworks, herramientas open source y una larga cadena de dependencias que rara vez se examinan de cerca.

Ese modelo de desarrollo permite innovar más rápido, reducir costes y aprovechar soluciones ya probadas. Pero también introduce un problema enorme: la visibilidad. ¿Qué hay realmente dentro del software que se está ejecutando? ¿Qué versión exacta de cada librería se está usando? ¿Esa librería, a su vez, qué otras dependencias arrastra? ¿Hay alguna parte de ese conjunto que tenga una vulnerabilidad conocida y crítica?

Aquí es donde entra en juego el concepto de SBOM, siglas de Software Bill of Materials, o lo que se podría traducir como “lista de materiales del software”. Un término heredado del mundo industrial —donde saber exactamente qué piezas componen un producto final es esencial para poder repararlo, mantenerlo o retirarlo del mercado— y que, poco a poco, está ganando el lugar que le corresponde también en el ámbito digital.

Lo que no se ve, no se puede proteger

Hasta hace no tanto, pocas organizaciones se preocupaban realmente de lo que había bajo la superficie del software que utilizaban. Se confiaba en que los proveedores se ocupaban de eso. Y si algo fallaba, la reacción era buscar el parche, aplicar el fix y seguir adelante. Pero en los últimos años, esa confianza se ha roto en muchos frentes.

El punto de inflexión más evidente fue el caso Log4Shell, una vulnerabilidad crítica en una librería Java ampliamente utilizada, que puso en evidencia un problema estructural: la mayoría de las empresas afectadas no sabían ni que esa librería estaba presente en sus sistemas. Ni cómo había llegado ahí, ni qué versiones estaban expuestas, ni en qué aplicaciones concretas se usaba. La única forma de saberlo era mirar dentro, y para muchas, eso era imposible.

Ese caso, junto con otros similares, hizo que el SBOM dejara de verse como un “extra” interesante y pasara a ser un requisito necesario para cualquier estrategia seria de ciberseguridad.

Tener un SBOM no significa estar a salvo. Pero sí permite saber con precisión qué se está utilizando, y eso, en ciberseguridad, ya es mucho. Porque si mañana se detecta una nueva vulnerabilidad crítica en una biblioteca popular, no tener un SBOM significa empezar a buscar a ciegas. Pero tenerlo permite saber al instante si el sistema está en riesgo, dónde está la pieza vulnerable y cómo se puede aislar o reemplazar.

Además, contar con esta información estructurada permite automatizar parte del análisis. Las herramientas de escaneo pueden cruzar los datos del SBOM con bases de datos de vulnerabilidades conocidas, generando alertas proactivas. No es ciencia ficción. Ya existe. Y quienes lo están aplicando, llegan antes a los problemas y sufren menos impacto.

No es una lista por cumplir, es una forma de trabajar

A veces, el concepto de SBOM se malinterpreta como un documento que hay que generar una vez, guardarlo y, si acaso, entregarlo si alguien lo pide. Pero ese enfoque está completamente equivocado. El valor del SBOM no está en su existencia, sino en su actualización constante y en cómo se utiliza dentro de los procesos reales de desarrollo y despliegue.

Cada vez que se lanza una nueva versión de una aplicación, se debe generar o actualizar el SBOM. Cada nueva dependencia que se añade, cada cambio en una librería, cada actualización de un framework, todo eso tiene que quedar reflejado. No por cumplir una norma, sino porque esa trazabilidad permite actuar con velocidad si algo cambia.

En muchos equipos, eso requiere un cambio cultural. Hasta hace poco, se asumía que “el software simplemente funciona” y que lo importante era la entrega. Pero cuando se trabaja bajo una filosofía donde todo se audita, donde se sabe qué versión se ha desplegado, en qué entorno, y con qué componentes exactos, entonces se gana algo que no tiene precio: control.

Ese control también tiene implicaciones legales. En ciertos sectores, especialmente aquellos regulados o que manejan información crítica, poder demostrar qué contiene el software que se está usando no solo es una cuestión de buenas prácticas. Puede marcar la diferencia en una auditoría, en una revisión de cumplimiento o ante un incidente donde haya que rendir cuentas.

A futuro, todo apunta a que este tipo de prácticas serán la norma. De hecho, ya lo están siendo. Estados como EE.UU. han empezado a exigir SBOMs a los proveedores de software que trabajan con organismos públicos. Y en Europa, con la evolución del marco NIS2, se empieza a ver una tendencia similar: mayor trazabilidad, más transparencia, menos margen para la opacidad tecnológica.

Por eso, muchas empresas están anticipando el cambio y adoptando el SBOM como parte natural de su flujo de desarrollo. Algunas lo integran en sus pipelines de CI/CD, otras lo gestionan con herramientas específicas que automatizan su generación. Lo importante no es cómo se hace, sino que forme parte del proceso, no de la urgencia.

Conclusión

El SBOM no es un capricho ni una moda. Es una respuesta lógica a un problema que ha crecido sin control durante años: el desconocimiento real de lo que se ejecuta dentro del software. Y ese desconocimiento ya no es aceptable.

Conocer los componentes, entender su origen, saber qué dependencias arrastran y poder actuar rápido cuando una de ellas presenta un riesgo ya no es una ventaja competitiva. Es parte de la responsabilidad básica de construir, mantener y proteger software en condiciones.

Las organizaciones que trabajan con SBOM no eliminan los riesgos, pero están mejor preparadas para enfrentarlos. No reaccionan, actúan. Y en un escenario donde la velocidad del ataque muchas veces supera la velocidad de respuesta, esa preparación es lo que marca la diferencia.

Y si tu empresa necesita ayuda para implementar una estrategia sólida de gestión de componentes y dependencias, contacta con nosotros.