El software moderno depende de cientos o miles de paquetes. Sin inventario, una vulnerabilidad en una dependencia se convierte en una búsqueda manual contra el reloj.
Un SBOM permite saber qué componentes existen, dónde se usan y qué riesgo representan cuando aparece una alerta.
Crear inventario desde la pipeline
El SBOM debe generarse automáticamente en CI/CD, no en una hoja aparte. Si el inventario no acompaña cada build, se desactualiza rápido.
También conviene almacenar el SBOM junto al artefacto desplegado para saber exactamente qué estaba en producción en una fecha determinada.
Priorizar por exposición real
No todas las vulnerabilidades tienen el mismo riesgo. Una dependencia vulnerable en una herramienta de desarrollo no equivale a una librería expuesta en runtime público.
La priorización debe considerar severidad, explotabilidad, alcance, permisos y si el componente está realmente cargado en producción.
- Cruzar alertas con rutas expuestas.
- Distinguir dependencias directas, transitivas y de desarrollo.
- Definir SLA de remediación por nivel de riesgo.
Automatizar actualizaciones con pruebas
Automatizar PRs de dependencias reduce trabajo, pero solo es seguro si hay pruebas que cubran flujos críticos.
Para cambios mayores conviene usar entornos de staging y releases graduales. La velocidad de parche no debería romper estabilidad.
Revisar origen y permisos
La cadena de suministro incluye más que paquetes: acciones de CI, imágenes base, plugins, scripts y permisos de publicación.
Un paquete sano puede volverse riesgoso si la cuenta que lo publica es comprometida o si el pipeline acepta cambios sin revisión.
Checklist para aplicar
- SBOM generado por cada build.
- Escaneo de dependencias directas y transitivas.
- Reglas de aprobación para cambios de alto riesgo.
- Inventario de imágenes, acciones CI y herramientas externas.
La seguridad de cadena de suministro no se resuelve con una herramienta única. Se resuelve combinando inventario, criterio de riesgo y capacidad real de actualizar rápido.