Resumen Técnico: El Estado de los Ecosistemas de Herramientas de SBOM

Declaración del Problema

Las cadenas de suministro de software modernas dependen en gran medida de dependencias de terceros, lo que crea riesgos significativos de seguridad y fiabilidad cuando existen vulnerabilidades en componentes menos seguros (por ejemplo, Log4Shell, SolarWinds). Si bien las Listas de Materiales de Software (SBOM, por sus siglas en inglés) han surgido como un mecanismo crítico para la transparencia y la rendición de cuentas —mandatado por la Orden Ejecutiva de EE. UU. en 2021 y adoptado globalmente— su utilidad depende en gran medida de las herramientas que las generan, analizan y gestionan.

A pesar de la existencia de dos formatos dominantes de SBOM, SPDX (establecido en 2010) y CycloneDX (introducido en 2017), existe una falta de comprensión empírica sobre la salud, madurez y capacidades funcionales de los ecosistemas de herramientas que rodean estos formatos. Los profesionales enfrentan desafíos al seleccionar las herramientas adecuadas debido a la limitada estandarización, la variabilidad en la madurez de las herramientas y la falta de datos sobre qué formatos soportan mejor casos de uso específicos (por ejemplo, automatización de construcción frente a cumplimiento de licencias). Estudios previos se han centrado en las especificaciones mismas o en encuestas limitadas a profesionales, dejando un vacío en el análisis cuantitativo de los ecoselos de herramientas reales.

Metodología

Los autores realizaron un estudio empírico exhaustivo comparando los ecosistemas de SPDX y CycloneDX a través de cuatro Preguntas de Investigación (RQ), utilizando un enfoque de recolección y análisis de datos en múltiples etapas:

1. Recolección y Clasificación de Herramientas (RQ1):

   • Fuente de Datos: Centros oficiales de herramientas para CycloneDX (219 herramientas) y SPDX (47 herramientas) al 27 de enero de 2024.
   • Filtrado: La verificación manual identificó 108 herramientas de código abierto (OSS) y 62 herramientas propietarias. Se encontró que 78 herramientas admiten ambos formatos (Formato Dual).
   • Análisis: Dos autores categorizaron manualmente 187 herramientas (140 de CycloneDX, 47 de SPDX) utilizando la Taxonomía de Clasificación de Herramientas de la NTIA (categorías de Producir, Consumir, Transformar) mediante clasificación por tarjetas cerradas. Se estableció la confiabilidad inter-evaluador (Krippendorff's $\alpha$ = 0.872).

2. Análisis de Salud del Ecosistema (RQ2):

   • Conjunto de Datos: Se expandió el conjunto de datos OSS para incluir bifurcaciones (forks) contribuyentes de GitHub, resultando en 171 repositorios de CycloneDX y 470 de SPDX.
   • Métricas: Evaluado mediante métricas de salud comunitaria CHAOSS (Estrellas, Observadores, Forks, Contribuidores, Pull Requests, Versiones, Commits).
   • Normalización: Todas las métricas fueron normalizadas por la edad del repositorio (días) para dar cuenta de las diferencias de madurez. La significancia estadística se probó mediante la prueba Mann-Whitney U con corrección de Bonferroni.

3. Análisis de Reportes de Problemas (RQ3):

   • Conjunto de Datos: Se extrajeron 36,990 reportes de problemas (posteriores a 2018) de 90 repositorios de herramientas de CycloneDX y 191 de SPDX.
   • Construcción de Taxonomía: Se derivaron 14 categorías de problemas distintas a partir de etiquetas de problemas.
   • Clasificación: Se validó un enfoque de anotación basado en LLM (usando mistralai/devstral-small-2-2) contra la anotación humana en una muestra aleatoria estratificada (379 problemas, $\alpha$ = 0.768). El modelo clasificó todos los 33,840 problemas.
   • Métricas: Se analizó la prevalencia de problemas y los tiempos de resolución entre categorías.

4. Análisis de Adopción de Proyectos (RQ4):

   • Conjunto de Datos: Se identificaron 2,426 proyectos de GitHub que utilizan herramientas de SBOM en sus canales de CI (enfocándose en casos de uso de "Construcción").
   • Selección: Se compararon los 250 proyectos con más estrellas que usan solo herramientas de CycloneDX frente a los 250 que usan solo herramientas de SPDX.
   • Análisis: Se compararon las métricas de salud de los proyectos y las distribuciones de lenguajes de programación (GPL vs. DSL).

Contribuciones Clave y Resultados

1. Cobertura de Casos de Uso (RQ1)

• Propietario vs. OSS: Las herramientas propietarias soportan una gama más amplia de casos de uso (1.14 veces más) que las herramientas OSS. Específicamente, las herramientas propietarias son más fuertes en Analizar y Ver (visualización), mientras que las herramientas OSS sobresalen en Soporte (integración/APIs).
• Diferencias de Formato:
  • Las herramientas exclusivas de CycloneDX muestran una fuerte asociación positiva con los casos de uso de Construcción y Soporte, pero carecen de soporte para Diferencia (comparación).
  • Las herramientas exclusivas de SPDX están fuertemente asociadas con Traducción (conversión de formato) y Diferencia, pero muestran un soporte limitado de herramientas de Construcción en el conjunto de datos (aunque el documento señala que Microsoft proporciona la generación de SPDX nativa para GitHub).
  • Las herramientas de formato dual son prevalentes en casos de uso de Importación, pero carecen de capacidades de Soporte.

2. Salud Comunitaria de las Herramientas (RQ2)

• Compromiso: A pesar de tener menos repositorios totales (171 frente a 470), las herramientas de CycloneDX exhiben un mayor compromiso comunitario. Tienen valores medianos más altos en Estrellas, Observadores, Forks, Contribuidores y Pull Requests.
• Actividad: Las herramientas de CycloneDX muestran una mayor actividad de commits y frecuencia de versiones.
• Contribuidores Recurrentes: Aunque hay diferencias insignificantes en la tasa de contribuidores recurrentes en la mayoría de los grupos de conteo de commits, las herramientas de SPDX atraen un mayor volumen de contribuciones de colaboradores con más de 1,000 commits, lo que sugiere un compromiso profundo a largo plazo en contribuyentes específicos de alto volumen.

3. Prevalencia de Problemas y Resolución (RQ3)

• Volumen de Problemas: Las herramientas de CycloneDX tienen un número medio de reportes de problemas normalizados (tanto abiertos como cerrados) mayor que las de SPDX.
• Velocidad de Resolución: Las herramientas de CycloneDX resuelven los problemas significativamente más rápido (un 67.69% menos de tiempo de resolución en promedio).
  • CycloneDX: Dominado por Corrección de Errores y Defectos (41.90%). Resuelve esto un 174% más rápido que SPDX.
  • SPDX: Dominado por Desarrollo de Funcionalidades y Mejoras (36.25%). Resuelve problemas de Licenciamiento un 51.85% más rápido que CycloneDX, consistente con los orígenes de SPDX como un formato enfocado en licencias.
• Implicación: El ecosistema de CycloneDX parece estar en una fase de rápida corrección de errores y estabilización, mientras que el ecosistema de SPDX está enfocado en la expansión de funciones y el cumplimiento de licencias complejas.

4. Patrones de Adopción de Proyectos (RQ4)

• Salud del Proyecto: Los proyectos que utilizan herramientas de CycloneDX demuestran métricas de salud comunitaria más altas (más estrellas, forks, contribuidores y commits) en comparación con aquellos que usan herramientas de SPDX.
• Preferencias de Lenguaje:
  • CycloneDX es prevalente en proyectos de Go y Python (asociados frecuentemente con DevOps enfocados en seguridad y microservicios).
  • SPDX es prevalente en proyectos de Java y C# (alineándose con el cumplimiento empresarial y las necesidades formales de licencias).
• Correlación de Actividad: Los proyectos con mayores conteos de commits tienden a usar herramientas que soportan Ver, Diferenciar e Importar (categoría de Consumo), mientras que los proyectos de menor actividad prefieren Editar, Fusionar y Analizar (categorías de Producción/Transformación).

Significado y Reivindicaciones

El documento sostiene que la elección de un formato de SBOM no debe hacerse de forma aislada, sino que debe considerar la madurez y la salud del ecosistema de herramientas circundante.

• Para DevOps Enfocado en Seguridad: El estudio sugiere que CycloneDX puede ser preferible para proyectos de Go/Python que requieren una rápida automatización de construcción, resolución de errores y un alto compromiso comunitario.
• Para Cumplimiento Empresarial: SPDX sigue siendo la opción más sólida para proyectos de Java/C# que priorizan el cumplimiento de licencias, la traducción de formatos y la diferenciación, respaldada por un ecosistema más maduro (aunque menos activo).
• Para Desarrolladores de Herramientas: El estudio identifica brechas específicas: las herramientas OSS necesitan mejorar sus capacidades de Analizar y Ver (actualmente dominadas por herramientas propietarias), mientras que los desarrolladores de herramientas de SPDX deberían enfocarse en reducir los retrasos de funciones, y los de CycloneDX deben mantener su alto rendimiento de corrección de errores.
• Impacto Regulatorio: El análisis observa una inflexión visible en la actividad de problemas tras el mandato del gobierno de EE. UU. en 2021, ilustrando cómo los eventos regulatorios remodelan la dinámica del desarrollo de código abierto a escala de ecosistema.

Los autores concluyen que, si bien ambos formatos son esenciales, sus ecosistemas de herramientas exhiben etapas evolutivas y prioridades distintas. Comprender estas diferencias permite a los profesionales tomar decisiones informadas que se alineen con sus necesidades específicas de proyecto, pilas de lenguaje y requisitos de cumplimiento.