Una lista de materiales de software es un inventario estructurado de los componentes que conforman un producto de software: las bibliotecas de código abierto, las dependencias comerciales y los módulos internos que en conjunto constituyen la implementación funcional del software. La Orden Ejecutiva 14028 de EE. UU., la Cyber Resilience Act de la UE y los requisitos regulatorios sectoriales han impulsado una adopción significativa de SBOM en los últimos años, y muchas empresas ahora solicitan SBOM a sus proveedores de software como actividad estándar de evaluación. Lo que estos mandatos han producido es una generación generalizada de SBOM sin un énfasis equivalente en la calidad, la vigencia o la utilidad práctica del SBOM: el documento existe, pero con frecuencia no cumple el propósito de gestión de riesgos que debería facilitar.
El problema de la vigencia es el problema de calidad del SBOM más inmediato. Los productos de software evolucionan continuamente: con cada versión se agregan, actualizan y eliminan dependencias. Un SBOM generado hace seis meses describe el conjunto de componentes de una versión de hace seis meses. Si la empresa ejecuta la versión actual del software, el SBOM de hace seis meses puede no representar con exactitud los componentes realmente implementados. A efectos de la gestión de vulnerabilidades, un SBOM que no refleja la versión implementada actual es un inventario de los componentes equivocados. El SBOM debe ser específico de la versión y actualizarse con cada versión.
La brecha del estado de vulnerabilidad es la segunda dimensión de calidad. Un SBOM que enumera componentes y versiones sin información sobre su estado de vulnerabilidad es un inventario de componentes, no un documento de gestión de riesgos. La empresa que recibe un SBOM con 847 componentes debe consultar por su cuenta una base de datos de vulnerabilidades (NVD, OSV o equivalente) para determinar qué componentes tienen vulnerabilidades conocidas. Un SBOM con información sobre el estado de vulnerabilidad, es decir, con anotaciones VEX (Vulnerability Exploitability eXchange), indica al consumidor qué vulnerabilidades conocidas afectan a los componentes listados, cuáles están en componentes que el proveedor ha confirmado que no son explotables en su implementación y cuáles se han corregido. La combinación de SBOM y VEX ofrece un panorama de vulnerabilidades sobre el que se puede actuar, algo que un SBOM por sí solo no ofrece.
Por qué es importante
La calidad del SBOM es importante para TPRM porque un SBOM desactualizado, incompleto o sin información sobre el estado de vulnerabilidad da la apariencia de transparencia en la cadena de suministro sin su sustancia. La empresa que recopila SBOM de los proveedores y los almacena sin revisar su vigencia, su integridad y sus implicaciones en materia de vulnerabilidades tiene un archivero lleno de artefactos de cumplimiento y ninguna inteligencia adicional sobre los riesgos de la cadena de suministro.
- SBOM recopilado sin verificar su vigencia: un SBOM de hace seis meses para el software actual
- Sin estado de vulnerabilidad: un SBOM sin VEX requiere una consulta de vulnerabilidades independiente
- Sin proceso de revisión del SBOM: documentos recopilados pero no analizados
- Vulnerabilidades conocidas del SBOM sin atender: listadas pero sin seguimiento para su corrección
- Información de licencias ausente: no se abordan el cumplimiento ni el riesgo de IP
Cómo se ve una buena práctica
Los programas maduros de SBOM solicitan SBOM específicos de la versión con cada versión principal, revisan los SBOM en busca de vulnerabilidades críticas conocidas mediante herramientas automatizadas, solicitan información VEX para los componentes con vulnerabilidades conocidas y hacen un seguimiento de la vigencia del SBOM como métrica de salud del programa.
- SBOM específico de la versión de software implementada
- Análisis automatizado de vulnerabilidades de los SBOM recibidos frente a NVD/OSV
- Solicitud de VEX para componentes con vulnerabilidades conocidas: contexto de explotabilidad
- Revisión de licencias para el cumplimiento de las licencias de código abierto
- Seguimiento de la vigencia del SBOM: antigüedad del SBOM respecto a la versión implementada
Herramientas
Análisis de SBOM: Dependency-Track, Grype y Trivy para el análisis de vulnerabilidades del SBOM
Las herramientas de análisis de SBOM pueden incorporar SBOM en formato CycloneDX o SPDX y analizar automáticamente sus componentes frente a bases de datos de vulnerabilidades, identificando vulnerabilidades conocidas en los componentes listados sin necesidad de consultas manuales a las bases de datos. Dependency-Track ofrece una gestión persistente de SBOM con supervisión automatizada de vulnerabilidades. Para los programas de TPRM que reciben SBOM de proveedores, estas herramientas convierten el documento en un panorama de vulnerabilidades sobre el que se puede actuar.
Herramientas de VEX: OpenVEX y CycloneDX VEX para el intercambio de información sobre explotabilidad de vulnerabilidades
Los documentos VEX aportan contexto sobre la explotabilidad de las vulnerabilidades junto con las listas de componentes del SBOM, especificando qué vulnerabilidades conocidas de los componentes listados no son explotables en la configuración de implementación del proveedor. Solicitar VEX junto con el SBOM para los componentes con vulnerabilidades críticas conocidas convierte una lista de vulnerabilidades en una prioridad de corrección sobre la que se puede actuar.
Desafíos de gobernanza
El desafío de gobernanza en los programas de SBOM es el requisito de volumen y de herramientas. Los productos de software de gran tamaño pueden tener cientos o miles de componentes. La revisión manual de un SBOM de 847 componentes frente a bases de datos de vulnerabilidades no es un enfoque viable. Las herramientas de análisis automatizado de SBOM son el mecanismo de gobernanza que convierte la recopilación de SBOM de una actividad de cumplimiento en una actividad de inteligencia de riesgos.
- Implementar herramientas de análisis automatizado de SBOM para todos los SBOM recibidos
- Solicitar SBOM específicos de la versión implementada
- Solicitar VEX para los componentes con vulnerabilidades críticas conocidas
- Hacer un seguimiento de las vulnerabilidades conocidas identificadas en los SBOM para su corrección por el proveedor
- Establecer un estándar de vigencia del SBOM: los SBOM con más de 90 días se marcan como posiblemente desactualizados
Si usted forma parte de un equipo pequeño
Tome el SBOM más reciente que haya recibido de su proveedor de software de mayor riesgo. Analícelo con Grype o Trivy: ambas son herramientas gratuitas y de código abierto que pueden analizar SBOM frente a bases de datos de vulnerabilidades en minutos. Revise los resultados en busca de vulnerabilidades críticas y de gravedad alta. Luego compruebe cuándo se generó el SBOM y si es específico de la versión que tiene implementada. Ese análisis de quince minutos producirá más inteligencia práctica sobre la cadena de suministro que confirmar que se entregó el SBOM.
- Analizar con Grype o Trivy los SBOM recibidos para detectar vulnerabilidades
- Comprobar la vigencia del SBOM: fecha de generación frente a la versión de software implementada
- Solicitar VEX para las vulnerabilidades críticas identificadas
- Hacer un seguimiento de la corrección por el proveedor de las vulnerabilidades críticas identificadas en el SBOM
Qué exigir
Pregunte directamente:
"¿Puede proporcionar un SBOM específico de la versión que estamos ejecutando, en formato CycloneDX o SPDX? Y, para los componentes con vulnerabilidades críticas conocidas, ¿puede proporcionar documentación VEX que confirme su estado de explotabilidad en su configuración de implementación?"
Evidencia que debe esperar
- SBOM específico de la versión en un formato estándar (CycloneDX o SPDX)
- Documentación VEX para componentes con vulnerabilidades críticas conocidas
- Proceso de generación del SBOM y frecuencia de actualización
- Información de licencias de los componentes de código abierto
A un proveedor que entrega un SBOM se le debe preguntar si es específico de la versión y si hay VEX disponible para las vulnerabilidades conocidas. Un SBOM sin vigencia ni VEX es un artefacto de cumplimiento. Un SBOM con ambos es una herramienta de gestión de riesgos.
Cómo demostrarlo
- Registros del análisis automatizado de vulnerabilidades del SBOM
- Verificación de la vigencia del SBOM
- Registros de solicitud y revisión de VEX
- Seguimiento de la corrección de vulnerabilidades por el proveedor a partir de los hallazgos del SBOM
Conclusión clave
SBOM entregado. 847 componentes. 14 con vulnerabilidades críticas conocidas en el momento de la generación. Antigüedad del SBOM: 6 meses. Estado de vulnerabilidad: no incluido. El SBOM existía y satisfacía la solicitud regulatoria de contar con uno. La primera revisión del regulador encontró tres problemas. El mandato produjo el documento. El mandato no produjo la vigencia, el estado de vulnerabilidad ni la acción que hacen útil el documento. Los SBOM específicos de la versión, el VEX para las vulnerabilidades conocidas y el análisis automatizado de los SBOM recibidos convierten un artefacto de cumplimiento en inteligencia sobre los riesgos de la cadena de suministro.