Software bill of materials (SBOM)
Para las organizaciones resulta una tarea ardua pero necesaria hacer un seguimiento de todos los materiales que se utilizarán para crear un producto. Es entonces cuando resulta útil una lista de materiales (BOM). Se trata de una lista exhaustiva de materiales, componentes y subconjuntos necesarios para fabricar, construir o arreglar un producto. Sirve como inventario detallado y organizado que describe la estructura de un producto, incluyendo todas las piezas necesarias y sus cantidades. Las listas de materiales se utilizan habitualmente en varios sectores, como la fabricación, la construcción, la electrónica, entre otros. Hay distintos tipos de listas de materiales, y pueden aplicarse tanto a productos físicos como a software. En el contexto del desarrollo de software, una lista de materiales de software (SBOM) es un tipo especializado de lista de materiales que enumera los componentes y dependencias de un producto de programación.
¿Qué es la lista de materiales de software?
En años recientes se ha prestado mayor atención a promover el uso de SBOMs en la industria del software para mejorar la transparencia, la colaboración y la seguridad en todo el ciclo de vida de desarrollo de software. Al adoptar la lista de materiales de software las organizaciones pueden adoptar un enfoque proactivo en la gestión de su cadena de suministro de software y protegerse de una amplia gama de riesgos.
Una lista de materiales de software (SBOM) es una lista exhaustiva de todos los componentes y sus dependencias, así como los metadatos asociados a una aplicación concreta. Funciona como un inventario de todos los componentes básicos que conforman un producto de software. Con un SBOM, las organizaciones pueden entender, gestionar y proteger mejor sus aplicaciones.
Beneficios del SBOM
Los beneficios de implementar y mantener un SBOM son muchos; no solo facilita la supervisión de los recursos sino que también mejora la eficiencia y la seguridad. Un SBOM tiene los siguientes beneficios:
Mejora en la seguridad: Los SBOMs ayudan a las organizaciones a identificar y priorizar las vulnerabilidades de seguridad en sus aplicaciones de software debido a elementos de terceros, lo que les permite tomar medidas correctivas a tiempo.
Reducción del riesgo de ataques a la cadena de suministro: Los SBOMs pueden ayudar a las organizaciones a identificar y mitigar los riesgos asociados a componentes maliciosos en su cadena de suministro de software.
Mejora de cumplimiento: Los SBOMs pueden ayudar a las organizaciones a cumplir con los requisitos reguladores que obligan a revelar de los componentes de software.
Mayor transparencia: Los SBOMs proporcionan una mayor visibilidad de los componentes de las aplicaciones de software, permitiendo a las organizaciones demostrar a las partes interesadas y/o a toda la comunidad el grado de seguridad de dichos componentes.
Integración en los flujos de trabajo: Los SBOMs pueden integrarse en DevOps y en los pipelines CI/CD, lo que permite la generación y actualización automatizada durante el ciclo de vida de desarrollo.
El alto costo de la invisibilidad: Lecciones de la vida real
La necesidad de un SBOM se vuelve evidente al analizar ataques importantes a la cadena de suministro:
Log4Shell (2021): Cuando se descubrió la vulnerabilidad crítica en la librería de Java Log4j, la mayoría de las empresas pasaron semanas revisando manualmente sus códigos para saber si estaban en riesgo. Quienes contaban con un SBOM activo pudieron identificar cada instancia de la librería vulnerable en todos sus proyectos en cuestión de minutos, permitiendo una actualización inmediata.
SolarWinds (2020): En este sofisticado ataque, se inyectó código malicioso en una actualización de software legítima. Un SBOM generado en la etapa de compilación sirve como una "línea base" confiable, pues al comparar el SBOM del producto final con la lista esperada de componentes, los equipos de seguridad pueden detectar cambios no autorizados o funciones "extra" que no deberían estar ahí.
Ataque de phishing a npm (2025): Un solo correo de phishing comprometió la cuenta de un mantenedor de npm de confianza, permitiendo a los atacantes inyectar código malicioso en 18 paquetes de JavaScript ampliamente utilizados, con más de 2.600 millones de descargas semanales en conjunto. Las organizaciones con SBOMs actualizados pudieron consultar su inventario de inmediato para verificar si alguna de las versiones comprometidas —como debug, chalk o ansi-styles— estaba presente en sus aplicaciones, lo que les permitió reaccionar antes de que el malware pudiera ejecutarse.
¿Qué contiene una lista de materiales de software?
Cuando un SBOM incorpora los tres elementos cruciales (campos de datos, soporte de automatización y prácticas y procesos) se convierte en una poderosa herramienta para mejorar la transparencia, seguridad y eficacia en la cadena de suministro de software. Los elementos clave de una lista de materiales de software son:
Datos del producto
Componentes: Una lista detallada de todos los componentes de software utilizados en la aplicación. Esto puede incluir APIs, librerías, módulos, paquetes y otras dependencias.
Información sobre versiones: Las versiones específicas de cada componente incluido en el software, lo que ayuda a rastrear posibles vulnerabilidades o actualizaciones.
Información sobre licencias: Detalles sobre las licencias asociadas con cada componente, asegurando el cumplimiento de los acuerdos de uso y licencias de código abierto, así como los requisitos legales.
Dependencias: Información sobre las relaciones y dependencias entre los distintos componentes de software, permitiendo una mejor comprensión de cómo los cambios en un componente pueden afectar a otros.
Vulnerabilidades de seguridad: Campos de datos que hacen referencia a vulnerabilidades de seguridad conocidas y asociadas a cada componente que pueden ayudar a los usuarios a evaluar y mitigar posibles riesgos.
Hashes y sumas de verificación: Campos de datos para hashes criptográficos o sumas de verificación para verificar la integridad de cada componente.
Sello de tiempo: Fecha y hora en que se creó el SBOM en cuestión.
Apoyo para la automatización
Integración de herramientas: El soporte de automatización implica la integración consistente y automática de herramientas de generación de SBOM en los procesos de software.
Supervisión continua: La automatización permite una supervisión continua de la cadena de suministro de software que permite estar al día cuando se producen cambios como nuevas versiones de componentes o parches de seguridad.
Integración con herramientas DevOps: La automatización implica integrar sistemas de generación de SBOM en las herramientas DevOps más populares, permitiendo a los equipos de desarrollo y operaciones incorporar SBOMs en sus flujos de trabajo.
Prácticas y procesos
Gestión del ciclo de vida del SBOM: Establecimiento de prácticas para la gestión del ciclo de vida completo de los SBOM, desde la creación inicial hasta las actualizaciones y desinstalaciones.
Formatos estandarizados: Adhesión a formatos estandarizados para los SBOM, como Software Package Data Exchange (SPDX) o CycloneDX, garantiza la coherencia y la interoperatividad entre las industrias.
Gobernanza y cumplimiento: Seguir prácticas de gobernanza y cumplimiento, las cuales deberían incluir auditorías periódicas para garantizar que los SBOMs son precisos y están actualizados.
Prácticas educativas: Implementación de prácticas para educar a los interesados sobre la importancia de los SBOMs y cómo interpretarlos y utilizarlos eficazmente.
Al incorporar estos tres elementos a una lista de materiales de software las organizaciones pueden establecer una base sólida para la gestión y la seguridad de la cadena de suministro de software.
Elegir una herramienta SBOM
Las organizaciones pueden utilizar varias herramientas para crear y mantener los SBOMs. Estas herramientas pueden escanear automáticamente e identificar los componentes y sus dependencias. Algunas de las mejores opciones son:
Syft: Fácil de usar, se integra con pipelines CI/CD, compatible con diversos gestores de paquetes y lenguajes
SPDX SBOM generator: Herramienta CLI ligera, genera SBOMs compatibles con SPDX, fácil de integrar con scripts
FOSSA: Solución integral para creación de SBOM, gestión de vulnerabilidades, cumplimiento de licencias y más
Spectral: Se integra con procesos CI/CD, ofrece análisis e informes avanzados de vulnerabilidades
MergeBase: Fácil de usar para crear flujos de trabajo de creación de SBOMs autónomos.
Microsoft SBOM: Herramienta de código abierto que genera SBOMs completos, incluyendo librerías de código abierto, dependencias y marcos de trabajo.
Al elegir una herramienta, es importante tener en cuenta factores como el tipo de software que se va a desarrollar, ya que algunas herramientas se especializan en lenguajes concretos; el nivel de detalle necesario, la integración con el flujo de trabajo existente, y, por supuesto, el presupuesto, ya que hay herramientas de código abierto y otras pagas.
Estándares y formatos SBOM
Estos formatos tienen un enfoque estructurado que representan los componentes y dependencias de una aplicación de software, lo que facilita la comprensión y la gestión de los riesgos de seguridad relacionados con estos componentes. Existen tres formatos principales estandarizados:
Software Package Data Exchange: SPDX es un formato de código abierto para representar componentes de software, dependencias y metadatos. Cuenta con un amplio respaldo de la industria y ha sido adoptado por varias organizaciones, como Microsoft, Google e IBM.
CycloneDX: Un formato de código abierto, de código abierto, ligero y flexible que se adapta bien al uso en DevOps y CI/CD. Proporciona capacidades de cadena de suministro para reducir el riesgo cibernético.
Software Identification: SWID es un formato estándar de la industria para describir componentes de software y sus metadatos asociados. Lo utilizan principalmente los editores de software comercial y se utiliza a menudo para fines de cumplimiento de licencias.
Todos los formatos están respaldados por organizaciones de confianza como OWASP e ISO, y están comprometidos con el enriquecimiento de sus respectivos conjuntos de herramientas, que permiten a los desarrolladores crear y editar sus propios SBOMs.
SPDX vs. CycloneDX vs. SWID: ¿Cuál elegir?
Característica | SPDX | CycloneDX | SWID |
|---|---|---|---|
Origen | Linux Foundation | OWASP Foundation | NIST/ISO |
Enfoque Principal | Licenciamiento y cumplimiento de PI | Seguridad y análisis de vulnerabilidades | Ciclo de vida de despliegue del software |
Estándar ISO | Sí (ISO/IEC 5962:2021) | No (estándar de la industria) | Sí (ISO/IEC 19770-2:2015) |
Ideal para | Equipos legales, PI compleja, archivo a largo plazo | DevOps, automatización de CI/CD, reporte VEX | Gestión de activos, TI empresarial |
Formato de datos | JSON, YAML, RDF, Tag-Value, XML | JSON, XML, Protobuf | XML |
Ventaja clave | Precisión alta en datos legales y de licencia | Ligero y optimizado para la velocidad y automatización | Visibilidad nativa en endpoints e integración con ITAM |
Exigencias regulatorias y cumplimiento global
Ante el aumento de ataques a la cadena de suministro, los gobiernos han pasado de recomendar la generación de SBOMs a hacerla una obligaciones legal:
Orden Ejecutiva 14028 (EE. UU.): Emitida en 2021, obliga a cualquier proveedor de software del gobierno federal estadounidense a entregar un SBOM. La NTIA se encargó de definir los "Elementos Mínimos" para garantizar la uniformidad en la industria.
Ley de Ciberresiliencia de la UE (CRA): Adoptada formalmente en 2024, esta ley exige que los fabricantes de productos con componentes digitales en la Unión Europea incluyan un SBOM en su documentación técnica. El incumplimiento puede acarrear multas severas y el retiro de productos del mercado europeo.
Mandatos específicos de la industria: La FDA ahora exige la entrega de SBOMs para las solicitudes de comercialización de dispositivos médicos, y el estándar PCI DSS 4.0 destaca la importancia de mantener un inventario de componentes para proteger los entornos de pagos.
Retos para adoptar los SBOMs
Aunque la implementación de los SBOMs tiene sus beneficios, como cualquier nueva práctica, existen retos que la acompañan. Uno de los principales retos es la ausencia de formatos estandarizados para los SBOMs. Cada sector puede tener requisitos y formatos para crear y compartir listas de materiales. Esta falta de normalización puede dificultar la interoperabilidad y crear confusión.
Las aplicaciones informáticas modernas se construyen a menudo utilizando componentes de terceros y librerías de código abierto. Crear un SBOM completo para ecosistemas de software complejos puede ser todo un reto, especialmente cuando se trata de dependencias agrupadas y componentes cargados dinámicamente. Aquí es donde las herramientas de terceros que realizan análisis de composición de software (SCA) pueden ayudar.
Cómo generar un SBOM con SCA
El análisis de la composición de software juega un papel crucial en la construcción de un SBOM robusto. Un SCA ayuda analizando e identificando los diversos componentes y dependencias dentro de un proyecto de software. Las herramientas SCA pueden determinar qué componentes de terceros están integrados en el software, y también pueden proporcionar información sobre las versiones de los componentes identificados, lo que es crucial para el seguimiento y la gestión de las versiones de software, especialmente en términos de vulnerabilidades de seguridad y actualizaciones.
Las herramientas SCA pueden integrarse en pipelines CI/CD y a menudo admiten formatos SBOM estandarizados, como SPDX o CycloneDX. Las herramientas contrastan los componentes con bases de datos de vulnerabilidades conocidas como el CVE, para asociarlos a versiones concretas e informar de cualquier vulnerabilidad de seguridad asociadas a los componentes. También pueden permitir a las organizaciones aplicar políticas relacionadas con el uso de componentes de código abierto, lo que podría incluir la verificación del cumplimiento de las políticas de licencias y las estándares de seguridad.
SCA no es necesariamente un proceso de una sola vez, puede configurarse para una supervisión continua. Esto garantiza que los SBOMs se mantengan actualizados a medida que evoluciona el software y se descubren nuevas vulnerabilidades.
Generando SBOMs con Fluid Attacks
Aprovechando nuestro análisis de composición de software, puedes sistemáticamente y exhaustivamente identificar, analizar, y documentar los componentes y dependencias dentro de tus proyectos de software. Mientras que los SBOMs pueden ensamblarse manualmente, el SCA de Fluid Attacks automatiza el proceso y proporciona un conocimiento más profundo de las vulnerabilidades y otros posibles problemas. Nuestro SCA puede ser el motor que te genera SBOMs detallados y precisos.
Además de SCA, nuestras propias herramientas realizan pruebas como SAST y DAST, que arrojan tasas mínimas de falsos positivos y ayudan a mejorar la transparencia, la seguridad y el cumplimiento en la cadena de suministro de software. La gestión de vulnerabilidades es mucho más práctica con nuestra plataforma única, que proporciona informes comprensibles que mantienen a todas las partes interesadas actualizadas ya que se generan continuamente.
Ofrecemos dos planes, plan Advanced y plan Essential, y ambos contribuyen al desarrollo seguro e implementación de software sin retrasar el tiempo de lanzamiento al mercado de tus aplicaciones. No dudes en contactarnos y empieza hoy mismo tu proceso con nosotros.
Preguntas frecuentes (FAQ)
¿SBOM es lo mismo que un análisis de composición de software (SCA)?
No. El SCA es el proceso o la herramienta de escaneo; el SBOM es el inventario entre varios resultantes o documentos generados por el SCA.
¿Debo hacer público mi SBOM?
No necesariamente. Muchas empresas los comparten bajo acuerdos de confidencialidad (NDA) para no dar una "hoja de ruta" a los atacantes, aunque las regulaciones actuales podrían obligar a entregarlos a las autoridades.
¿Con qué frecuencia se debe actualizar un SBOM?
Debe generarse con cada nueva versión o compilación (build). Debido a que las dependencias cambian constantemente, un SBOM estático queda obsoleto rápidamente para el monitoreo de seguridad.
¿Un SBOM puede detectar zero days?
Un SBOM no encuentra vulnerabilidades por sí mismo; te dice lo que tienes. Cuando se anuncia un zero-day, revisas tu SBOM para ver si ese componente está en tu entorno, permitiéndote reaccionar antes de que ocurra un ataque.
¿Qué es VEX y cómo se relaciona con los SBOM?
VEX (Vulnerability Exploitability eXchange) es un documento complementario al SBOM que comunica si un producto es realmente vulnerable debido a uno de sus componentes. Mientras que el SBOM te dice qué hay en el software, el VEX puede aclarar que una vulnerabilidad no es explotable en tu implementación específica. Juntos, ayudan a las organizaciones a priorizar efectivamente sus esfuerzos de remediación.
