Del SBOM a la puerta de vulnerabilidades: Syft y Grype en la CI de los MSP

Los proveedores de servicios gestionados que operan pipelines de CI para sus clientes pueden combinar dos herramientas de código abierto de Anchore, Syft y Grype, en una única puerta de control para la cadena de suministro de software: Syft cataloga cada paquete de un build en una lista de materiales de software (SBOM), y Grype compara ese inventario con vulnerabilidades conocidas antes de dejar pasar el build. Esta guía explica qué hace cada herramienta, cómo encajan entre sí y dónde la combinación se queda corta.

Genera primero el inventario, con Syft

Syft, mantenido por Anchore bajo licencia Apache-2.0, genera una lista de materiales de software SPDX o CycloneDX a partir de imágenes de contenedor, sistemas de archivos y paquetes. Anchore publicó syft v1.52.0 el 17 de septiembre, corrigiendo dos errores de catalogador que producían inventarios inexactos: el catalogador de la base de datos RPM reportaba una versión de biblioteca obsoleta de una imagen Rocky Linux 10 de una sola capa, y el catalogador de archivos Java devolvía una versión desconocida para los uber-jar. La versión también incluye mantenimiento de dependencias: 52 cambios que corrigen seis vulnerabilidades conocidas, incluida una actualización de la biblioteca grpc-go que cerró varios avisos publicados. Las correcciones del catalogador importan sobre todo a los equipos que usan imágenes basadas en RPM o uber-jar de Java, donde una versión obsoleta o desconocida en el SBOM terminaría ocultando lo que un escáner posterior realmente está comprobando.

Grype convierte el inventario en una puerta de control

Grype, también mantenido por Anchore, analiza imágenes de contenedor, sistemas de archivos y SBOM en busca de vulnerabilidades conocidas. A 23 de septiembre de 2026, su repositorio en GitHub mostraba alrededor de 12.900 estrellas y un commit de dos días antes, señal de mantenimiento activo. Integrado en una pipeline de CI justo después de generar el SBOM, Grype permite fallar un build automáticamente cuando aparece una CVE conocida, en lugar de depender de que alguien se acuerde de revisarlo más tarde. El flujo habitual genera el SBOM durante el build, normalmente con Syft, y luego ejecuta Grype contra ese SBOM y, opcionalmente, contra la imagen construida directamente, comprobando cada componente listado frente a los datos de vulnerabilidades conocidas. Un umbral de gravedad decide si el job falla: todo lo que lo supere bloquea el merge salvo que exista una excepción registrada, con responsable y plazo.

Haz visibles las excepciones, no las escondas

Una puerta fail-closed solo sirve si las excepciones son visibles y tienen un responsable. Sin un proceso escrito, los equipos acaban desactivando la puerta la primera vez que bloquea algo urgente, o acumulan anulaciones silenciosas que anulan el sentido mismo del análisis. Una excepción debe indicar un responsable, un motivo y una fecha de caducidad tras la cual el hallazgo se reevalúa, no quedar exenta indefinidamente.

Lo que la puerta no hace

Grype indica qué es vulnerable en lo que se está a punto de publicar; no aplica parches, no impone el principio de mínimo privilegio ni sustituye la monitorización en tiempo de ejecución una vez desplegada la carga de trabajo. También depende de que su base de datos de vulnerabilidades esté actualizada, así que fijar el escáner a un feed obsoleto anula el propósito. Al estandarizar este enfoque entre las pipelines de los clientes, lo práctico es probar antes los umbrales de gravedad en una pipeline que no sea de producción, porque un umbral demasiado agresivo solo enseñará a los equipos a esquivar la puerta. Archivar cada SBOM junto a su artefacto de build también convierte ese mismo inventario en un paquete de evidencia para clientes o aseguradoras, sin coste adicional de análisis. Los proveedores que necesiten ayuda externa con pruebas de penetración, evaluación de vulnerabilidades, respuesta a incidentes o cumplimiento NIS2/DORA/GDPR pueden recurrir a los servicios de ciberseguridad de Altovar.

Qué hacer

• Añade Syft como paso de build que emita un SBOM SPDX o CycloneDX para cada imagen o artefacto, y haz fallar el build si la generación da error.
• Ejecuta Grype contra ese SBOM, y opcionalmente contra la imagen construida, justo después, con un umbral de gravedad probado antes en una pipeline que no sea de producción.
• Documenta el proceso de excepción antes de activar la puerta: quién puede concederla, qué debe registrar y cuándo caduca.
• Archiva cada SBOM junto a su artefacto de build para que pueda servir después como paquete de evidencia para clientes o aseguradoras.
• Mantén actualizada la base de datos de vulnerabilidades de Grype; un feed obsoleto deja pasar builds que la puerta debería haber bloqueado.
• Combina la puerta con parches y monitorización en tiempo de ejecución, porque ninguna de las dos herramientas cubre lo que ocurre tras el despliegue.

Fuentes: Grype en GitHub, versiones de anchore/syft.