Los líderes de seguridad han invertido mucho en programas de gestión de vulnerabilidades. El escáner está funcionando. Creando SBOM. Mostrando números del tablero. Y, sin embargo, la mayoría de los programas operan sobre una suposición fundamental que no se cumple: que la salida del escáner es auténtica. No lo es.
Ejecute dos escáneres estándar de la industria en la misma imagen de contenedor y nunca obtendrá dos versiones de la misma respuesta. Obtendrás dos respuestas completamente diferentes. En una prueba reciente utilizando una imagen de Red Hat 8, Grype expuso 852 CVE mientras que Trivy expuso 3719.
El jefe del departamento de ingeniería de Manifesto.
Esa es una variación del 80,5%, con la misma entrada y al mismo tiempo. Ambos escáneres funcionan correctamente. Simplemente están tomando decisiones diferentes y la mayoría de las organizaciones no tienen idea de qué decisiones toman sus escáneres por ellos.
Este no es un problema de herramientas que pueda solucionar cambiando de proveedor. Este es un problema estructural relacionado con el funcionamiento de la comparación de vulnerabilidades, y comprenderlo ahora es esencial para cualquier líder de seguridad que quiera hacer que sus programas sean señales confiables.
Por qué emparejar es más difícil de lo que parece
Cada escáner sigue el mismo proceso básico: detecta paquetes en un contenedor o repositorio, asigna un identificador a cada paquete y luego relaciona ese identificador con una base de datos de vulnerabilidades. El resultado es una lista de CVE con puntuaciones e información de corrección. La fase de emparejamiento es donde los programas divergen silenciosamente.
Los paquetes se identifican mediante uno de dos formatos: CPE (enumeración de plataforma común) o PURL (URL de paquete). Los CPE son requeridos por la Base de datos nacional de vulnerabilidad (NVD) del NIST, al igual que la mayoría de los marcos de cumplimiento. Pero sus campos de proveedor y producto son gratuitos.
Las bifurcaciones y las distribuciones reempaquetadas habitualmente rompen la atribución. Tres repositorios distintos de Google protobuf, por ejemplo, comparten el mismo CPE. Los consultores modernos y conscientes del ecosistema prefieren cada vez más los PURL, pero sus campos de calificación no están estandarizados en absoluto y cada escáner los utiliza de manera diferente.
Las bases de datos complican aún más el problema de consulta del escáner.
NVD se selecciona manualmente, solo para CPE, y el enriquecimiento a menudo demora semanas o meses. OSV es nativo del ecosistema con actualizaciones rápidas pero una cobertura desigual entre los ecosistemas.
Las sugerencias de proveedores como Red Hat suelen ser las más precisas para sus paquetes, pero sus datos no siempre regresan a NVD y no están formateados para su ingesta pública.
Cada una de estas discrepancias es un lugar donde su escáner toma una decisión aleccionadora. La mayoría de estas decisiones nunca se revelan a las partes que actúan sobre el resultado.
Tu escáner está tomando esa decisión sin ti
La diferencia entre Gripe y Trivi no es un ruido aleatorio. Está estructurado y comprender la estructura separa un programa maduro de uno que simplemente genera números.
Trivy ha marcado 2.974 CVE para un paquete de encabezado del kernel. Gripe está marcado como cero, porque aplica una regla de supresión predeterminada: el encabezado del kernel es un paquete de desarrollo de solo encabezado, y se supone que su presencia no lo vincula a un CVE del kernel de Linux.
Ésa es una decisión razonable. Su equipo puede estar de acuerdo o no con esto. Pero su programa debe saber que se está creando.
Grype ha marcado tres CVE para la herramienta de configuración de Python. Trivi no marcó ninguno porque no catalogó esos paquetes durante el análisis. Trivy marcó 16 CVE por un frasco Tomcat Catalina. Grype marcó nulo porque adivinó el ID del grupo Maven a partir de la ruta del directorio y se equivocó.
En cada caso, un escáner diferente es más preciso. En cada caso, la corrección es invisible a menos que sepas mirar.
Nadie habla del problema del generador SBOM.
Si su programa depende de SBOM, ya sea proporcionado por el proveedor o desarrollado internamente, el problema se extiende hacia arriba del escáner. La herramienta que crea el SBOM da forma a lo que el escáner puede encontrar.
Escanear la misma imagen del contenedor pero usando un SBOM generado por Syft versus un SBOM generado por Trivi produce una diferencia del 66% en el resultado de Gripe. Syft inyecta calificadores de paquetes ascendentes en su PURL, lo que permite que el escáner compare un paquete mínimo con el historial de vulnerabilidades de su padre.
Trivi omite esos calificativos. Gripe no encuentra nada. La vulnerabilidad no está en el escáner. Esto está en los metadatos que el generador elige incluir.
Esto significa que un SBOM proporcionado por el proveedor escaneado con una herramienta que no coincide puede brindarle una falsa confianza en la situación de seguridad de ese componente. El formato SBOM también es importante: CycloNDX y SPDX, los dos formatos dominantes, producen resultados significativamente diferentes de la misma cadena de herramientas debido a cómo cada paquete de extensión maneja los metadatos.
¿Qué deberían hacer ahora los líderes de seguridad?
Tres decisiones que mejorarán inmediatamente la confiabilidad del programa:
Audite los emparejamientos de sus cadenas de herramientas. Identifique qué generador de SBOM en su entorno generó cada SBOM y verifique que el escáner se esté utilizando para ese generador. Combine Syft con Grype. Trivy construye y escanea como una herramienta unificada. Reduzca silenciosamente su cobertura combinada.
Sepa de dónde proviene su puntuación CVSS. Si su programa prioriza la corrección por umbral de gravedad, comprenda qué CNA utiliza de forma predeterminada su escáner. Grype utiliza puntuaciones NVD.
Trivy suele utilizar puntuaciones de proveedores, que reflejan mitigaciones específicas de cada proveedor. El mismo CVE puede ser calificado de crítico por uno y moderado por otro. Su política de crecimiento puede estar enviando una señal equivocada.
Cree reglas de supresión, no se limite a arreglar colas. Una regla de supresión documentada aplicada a escala de flota elimina miles de revisiones manuales. Cuando su equipo verifique que un hallazgo es un falso positivo, codifique ese juicio y generalícelo.
Un valor compuesto de biblioteca de supresión también retrasa una vulnerabilidad, pero en la dirección correcta.
Preguntas de auditoría honestas
Un análisis limpio no garantiza que su entorno sea seguro. Esto podría significar que el escáner omitió algo, que el generador omitió metadatos que el escáner necesitaba o que la base de datos no estaba actualizada con sugerencias recientes. Una búsqueda de cero requiere explicación, al igual que una búsqueda de 3.000.
Los programas que estarán bajo escrutinio no ejecutan la mayoría de los escáneres. Saben qué suposiciones hacen sus escáneres y han creado tareas para desafiar esas suposiciones.
Así es como se ven las prácticas maduras de gestión de vulnerabilidades.
Hemos presentado el mejor software de cifrado.
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
