SBOM y dependencias en el ciclo de vida del software

Saber qué se desplegó acelera la respuesta

Una lista de dependencias del repositorio no siempre representa lo que acabó dentro del artefacto publicado. Un SBOM (Software Bill of Materials) describe componentes y relaciones de un producto en una versión determinada; permite responder con más rapidez cuando aparece una vulnerabilidad o cambia el soporte de una biblioteca.

CISA publicó en 2025 elementos mínimos para un SBOM, incluyendo información que ayuda a identificar componentes y su procedencia. Adopta un formato mantenible por tus herramientas y receptores; que el fichero sea válido no demuestra que el inventario esté completo o actualizado.

Integrarlo en una entrega

1. Genera el inventario desde el artefacto que realmente se construye, no solo desde una rama o manifiesto parcial.
2. Conserva componente, proveedor, versión y relación de dependencia cuando la herramienta lo pueda determinar.
3. Vincula el SBOM al identificador del build, hash del artefacto, repositorio y fecha de generación.
4. Almacénalo junto a la versión publicada y controla quién puede modificarlo.
5. Cruza el inventario con avisos de seguridad y estado de soporte; asigna la evaluación al propietario del producto.
6. Regenera el documento en cada versión que cambie componentes y conserva la trazabilidad de versiones anteriores.

Qué no afirma un SBOM

El documento no prueba que el software sea seguro, que no contenga código malicioso ni que todos los componentes sean vulnerables. Es una entrada para la evaluación, no la conclusión. Comprueba además componentes descargados dinámicamente, dependencias transitivas que el generador no resuelva y módulos opcionales incluidos solo en ciertos entornos.

Define una vía para que seguridad, desarrollo y operaciones reciban una alerta, identifiquen las versiones afectadas y decidan si actualizar, mitigar, sustituir o aceptar temporalmente el riesgo. Conecta ese trabajo con el ciclo ALM de Power Platform y las prácticas de DevSecOps.