Una SBOM enumera los componentes y versiones de un software, pero no indica por sí sola cuáles tienen vulnerabilidades conocidas. Grype toma ese inventario, lo compara con su base local de vulnerabilidades y genera coincidencias que pueden revisarse en la terminal, conservarse como JSON o utilizarse como control en CI/CD.

En esta guía vas a analizar una SBOM existente, comprobar que el reporte sea válido, interpretar los hallazgos y aplicar un umbral de severidad sin confundir una coincidencia con una vulnerabilidad explotable confirmada.

Resultado esperado. Obtendrás un reporte reproducible que relaciona paquetes y versiones de la SBOM con identificadores de vulnerabilidad, severidad y versiones corregidas cuando esa información esté disponible.

Antes de comenzar

Necesitas:

• Una SBOM legible en Syft JSON, SPDX JSON/XML/tag-value o CycloneDX JSON/XML.
• Grype instalado en Ubuntu u otra distribución Linux con Bash.
• Acceso a Internet para descargar o actualizar inicialmente la base de vulnerabilidades.
• jq si quieres validar y consultar reportes JSON desde la terminal.
• Permisos de lectura sobre la SBOM y de escritura en el directorio donde guardarás el reporte.

Usa una versión estable actual de Grype. Al 31 de agosto de 2026, la versión más reciente publicada es v0.116.1. Como mínimo, evita versiones anteriores a v0.104.1: un aviso oficial corrigió en esa versión una posible exposición de credenciales de registro en ciertos reportes JSON.

Además, las versiones anteriores a v0.88.0 dejaron de recibir actualizaciones de la base de vulnerabilidades el 6 de marzo de 2026.

Protege los artefactos. Una SBOM y su reporte pueden revelar tecnologías, versiones y rutas internas. No los publiques automáticamente ni los adjuntes a un ticket abierto. Guárdalos con permisos restrictivos y aplica la política de retención de tu organización.

Cómo realiza Grype el cruce

Grype carga los paquetes descritos en la SBOM, los convierte en candidatos de coincidencia y consulta una base local construida a partir de distintas fuentes de vulnerabilidades. Después aplica los comparadores adecuados para cada ecosistema, elimina duplicados, procesa reglas de exclusión o documentos VEX si existen y presenta el resultado.

El análisis depende de la calidad del inventario. Si la SBOM omite paquetes, versiones, PURL, CPE o metadatos de la distribución, Grype tendrá menos información para realizar coincidencias precisas. Por eso, un reporte sin hallazgos no demuestra por sí solo que el artefacto sea seguro.

Flujo del análisis: el inventario y la base local entran en Grype; el resultado queda disponible para revisión humana y automatización.

Paso 1: registra la versión y prepara la SBOM

Comprueba primero qué versión está instalada:

grype version

Si todavía no tienes Grype en Linux, la documentación oficial ofrece este instalador:

curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin
grype version

En un entorno controlado, revisa el script antes de ejecutarlo o descarga el binario desde las publicaciones oficiales y verifica su checksum, firma o attestation según la guía de Anchore.

Grype también está disponible para macOS y Windows, pero los comandos de preparación y automatización de este artículo están escritos para Bash en Linux.

Crea un directorio de trabajo, copia allí la SBOM y registra su huella. Sustituye la ruta de ejemplo por la ubicación real:

install -m 0700 -d "$HOME/analisis-sbom"
cp /ruta/a/mi-sbom.json "$HOME/analisis-sbom/sbom.json"
cd "$HOME/analisis-sbom"
chmod 0600 sbom.json
sha256sum sbom.json > sbom.sha256

Si la SBOM es JSON, comprueba al menos que la sintaxis sea válida:

jq empty sbom.json

jq sin salida y con código 0 confirma que el JSON está bien formado; no confirma que cumpla un esquema SBOM ni que el inventario esté completo. La validación práctica del formato ocurrirá cuando Grype intente cargarlo.

Paso 2: actualiza y comprueba la base de vulnerabilidades

Grype mantiene una base local y normalmente busca actualizaciones al iniciar. Para hacer explícito el estado antes de un análisis reproducible, ejecuta:

grype db update
grype db status

Conserva la salida de grype db status junto con la versión de Grype y la huella de la SBOM.

La documentación actual indica que el escaneo falla de forma predeterminada si la base tiene más de cinco días. En un entorno sin conexión, actualiza y traslada la base mediante el procedimiento oficial para instalaciones aisladas; no desactives la validación de antigüedad sin documentar el riesgo.

Paso 3: analiza la SBOM en la terminal

Usa el prefijo explícito sbom: para que la intención del comando no dependa de la detección automática:

grype sbom:./sbom.json

Grype admite también una ruta sin prefijo y puede leer una SBOM desde una tubería. Sin embargo, la documentación advierte que grype < sbom.json no funciona como entrada redirigida en una sesión interactiva; la ruta con sbom: es más clara y predecible.

La tabla puede incluir estas columnas:

• NAME: paquete de la SBOM que produjo la coincidencia.
• INSTALLED: versión encontrada en el inventario.
• FIXED IN: versión que corrige la vulnerabilidad, si el proveedor la informa.
• TYPE: ecosistema o tipo de paquete.
• VULNERABILITY: identificador original, que puede ser CVE o un aviso de otro proveedor.
• SEVERITY: severidad publicada.
• EPSS: probabilidad estimada de explotación en los próximos 30 días, cuando existe.
• RISK: señal compuesta que combina impacto y amenaza para ayudar a ordenar los resultados.

Puedes añadir --by-cve si necesitas orientar los identificadores a CVE cuando sea posible. No todas las vulnerabilidades tienen una correspondencia CVE.

Paso 4: guarda un reporte JSON verificable

Genera una salida estructurada y redirige la salida estándar a un archivo:

grype sbom:./sbom.json --output json > grype-report.json
chmod 0600 grype-report.json
jq empty grype-report.json
jq '.matches | length' grype-report.json

El primer comando crea el reporte; jq empty comprueba que sea JSON válido y el último muestra la cantidad de coincidencias no ignoradas.

En versiones afectadas por el aviso GHSA-6gxw-85q2-q646, la redirección de la salida estándar era además la mitigación recomendada para evitar que determinadas credenciales configuradas aparecieran en el archivo. Actualizar Grype sigue siendo la solución correcta.

Para obtener una lista compacta sin perder el archivo original:

jq -r '.matches[] | [
  .vulnerability.id,
  .vulnerability.severity,
  .artifact.name,
  .artifact.version,
  ((.vulnerability.fix.versions // []) | join(", "))
] | @tsv' grype-report.json

Paso 5: interpreta y prioriza los hallazgos

Una fila significa que Grype encontró una correspondencia entre un componente inventariado y una entrada de vulnerabilidad. No demuestra por sí sola que la vulnerabilidad sea alcanzable o explotable en tu aplicación.

Revisa, en este orden:

1. Identidad del componente. Confirma nombre, versión, tipo, PURL/CPE y distribución. Las coincidencias directas suelen ofrecer más confianza; las basadas en CPE requieren más revisión por posibles ambigüedades.
2. Corrección disponible. Si FIXED IN tiene una versión, comprueba que sea compatible y actualiza en un entorno de prueba. Un campo vacío puede significar que todavía no hay corrección o que la fuente no aporta ese dato; no equivale a ausencia de riesgo.
3. Amenaza y exposición. Considera KEV, EPSS, RISK, exposición de red, privilegios, datos accesibles y si el código vulnerable se ejecuta realmente. La severidad sola no describe el riesgo de negocio.
4. Fuente y contexto. Contrasta los casos críticos con el aviso del proveedor o la distribución. Las distribuciones pueden aplicar parches sin cambiar la versión ascendente del paquete.
5. Acción registrada. Corrige, mitiga o documenta una excepción con responsable, justificación y criterio de vencimiento. Utiliza VEX cuando exista evidencia sobre la explotabilidad; no como una lista de silenciamiento permanente.

Imagen relacionada: segunda imagen mostrada arriba.

Un hallazgo se convierte en acción al combinar identidad, corrección disponible y contexto de explotación.

Paso 6: aplica un umbral en CI/CD

--fail-on cambia el código de salida si Grype encuentra vulnerabilidades en la severidad indicada o por encima de ella. Por ejemplo, high incluye hallazgos High y Critical:

grype_rc=0
grype sbom:./sbom.json --output json --fail-on high \
  > grype-report.json || grype_rc=$?

case "$grype_rc" in
  0)
    echo "Sin hallazgos en el umbral configurado"
    ;;
  2)
    echo "Hay hallazgos High o Critical"
    ;;
  *)
    echo "El escaneo falló por un error técnico" >&2
    exit "$grype_rc"
    ;;
esac

El código 2 indica que el análisis terminó y activó el umbral; no debe etiquetarse como un fallo de ejecución de Grype.

Si tu shell o runner usa set -e, captura el código en un bloque que permita continuar hasta el case. Conserva grype-report.json como artefacto incluso cuando la puerta bloquee la entrega.

El umbral debe responder a una política de riesgo definida: no lo reduzcas solo para que el pipeline quede verde.

La evidencia se guarda antes de evaluar la puerta, de modo que ambos resultados puedan auditarse.

Paso 7: corrige, regenera y vuelve a comprobar

Después de actualizar una dependencia o imagen base:

1. Construye nuevamente el artefacto desde fuentes controladas.
2. Genera una SBOM nueva a partir de ese artefacto exacto.
3. Registra la nueva huella.
4. Repite el escaneo con la misma política y una base actualizada.
5. Confirma que el identificador desapareció, cambió a una versión corregida o quedó tratado mediante una decisión documentada.

No edites la SBOM para borrar un componente vulnerable. La SBOM debe representar el artefacto real; si el software cambió, genera un inventario nuevo.

Cómo comprobar el resultado

El procedimiento queda verificado cuando puedes conservar esta evidencia:

• Versión de Grype utilizada.
• Estado de la base de vulnerabilidades.
• Fecha y hora UTC del análisis.
• Huella SHA-256 de la SBOM.
• Comando y código de salida.
• Reporte JSON válido.
• Decisión de remediación o excepción.
• Nuevo reporte posterior al cambio.

Para la revisión posterior, compara siempre reportes obtenidos con el mismo alcance. Un cambio de versión de Grype, de base, de formato SBOM o de catalogador puede alterar las coincidencias aunque el software no haya cambiado.

Problemas frecuentes

Grype no reconoce la SBOM

Comprueba la ruta, los permisos y la sintaxis con jq empty para JSON. Confirma que el archivo sea Syft JSON, SPDX o CycloneDX y prueba el prefijo sbom:.

Si el productor genera una versión de esquema reciente, actualiza Grype antes de convertir el archivo.

El reporte no contiene coincidencias

Revisa que la SBOM tenga paquetes y versiones, y no solo metadatos generales. Comprueba también la antigüedad de la base y el tipo de ecosistema.

Cero coincidencias puede ser un resultado válido, pero también una señal de inventario incompleto.

La base está desactualizada o el entorno no tiene Internet

Ejecuta grype db status y actualiza desde una red permitida. Para un entorno aislado, usa el flujo oficial de importación de base y registra su fecha.

Evita desactivar permanentemente la comprobación de antigüedad.

El pipeline informa un error aunque el reporte existe

Revisa el código de salida. Con --fail-on, el código 2 significa que se alcanzó el umbral; otros códigos requieren revisar stderr, permisos, formato de entrada o estado de la base.

Aparecen coincidencias que no parecen aplicables

Examina matchDetails en JSON y la identidad del paquete. Las coincidencias CPE necesitan especial atención.

Contrasta el resultado con el proveedor y documenta la evaluación. Si cuentas con evidencia formal de no afectación, incorpora un documento VEX en lugar de una exclusión genérica.

Buenas prácticas

• Fija la versión de Grype en automatizaciones reproducibles y planifica su actualización.
• Conserva la SBOM original, su huella y el reporte como un conjunto de evidencia.
• Genera la SBOM a partir del artefacto que realmente vas a desplegar.
• Separa la detección de la priorización: combina corrección disponible, KEV, EPSS, riesgo y exposición.
• Revisa las exclusiones; cada una debe tener evidencia, responsable y vencimiento.
• Protege la SBOM y los reportes como información técnica sensible.
• Repite el escaneo después de cada corrección y después de actualizar la base.

Conclusión

Cruzar una SBOM con Grype convierte un inventario estático en una lista de vulnerabilidades conocidas que puede revisarse y automatizarse.

El valor no está solo en ejecutar el comando: está en conservar la versión y la base utilizadas, interpretar cada coincidencia con contexto y demostrar mediante un segundo escaneo que la corrección llegó al artefacto real.

Como siguiente paso, integra la generación de la SBOM y el análisis en tu pipeline, conserva ambos artefactos y define una política de priorización acorde con la exposición de cada servicio.

Un Cloud Server de DonWeb puede utilizarse como entorno aislado de análisis, pero Grype no requiere un servicio de red, DNS ni puertos abiertos para escanear una SBOM local.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting