Un escáner de vulnerabilidades para imágenes de contenedores y sistemas de archivos. Instale fácilmente el binario para probarlo. Funciona con Syft, la poderosa herramienta SBOM (lista de materiales de software) para imágenes de contenedores y sistemas de archivos.
Admite formatos de imagen Docker, OCI y Singularity.
Soporte OpenVEX para filtrar y aumentar los resultados del escaneo.
Si encuentra algún problema, háganoslo saber utilizando el rastreador de problemas.
Instalación
Recomendado
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Instalar opciones de script:
-b : especifica un directorio de instalación personalizado (el valor predeterminado es ./bin )
-d : niveles de registro más detallados ( -d para depuración, -dd para seguimiento)
-v : Verifica la firma del artefacto descargado antes de la instalación (requiere la instalación de cosign )
chocolateado
La distribución de chocolate de grype es mantenida por la comunidad y no distribuida por el equipo presentador.
choco instala grype -y
cerveza casera
ancla/grype del grifo de cerveza
cerveza instalar grype
Puertos Mac
En macOS, Grype también se puede instalar desde el puerto mantenido por la comunidad a través de MacPorts:
puerto sudo instalar grype
Nota : Actualmente, Grype está diseñado solo para macOS y Linux.
De la fuente
Consulte DEVELOPING.md para obtener instrucciones para compilar y ejecutar desde el código fuente.
Acciones de GitHub
Si está utilizando GitHub Actions, puede usar nuestra acción basada en Grype para ejecutar análisis de vulnerabilidades en su código o imágenes de contenedor durante sus flujos de trabajo de CI.
Verificando los artefactos
Las sumas de comprobación se aplican a todos los artefactos y el archivo de suma de comprobación resultante se firma mediante cosign.
Necesita la siguiente herramienta para verificar la firma:
cofirmar
Los pasos de verificación son los siguientes:
Descargue los archivos que desee y los archivos checksums.txt, checksums.txt.pem y checksums.txt.sig desde la página de lanzamientos:
Una vez que se confirma que la firma es válida, puede proceder a validar que las sumas SHA256 se alineen con el artefacto descargado:
sha256sum --ignore-missing -c sumas de comprobación.txt
Empezando
Instale el binario y asegúrese de que grype esté disponible en su ruta. Para buscar vulnerabilidades en una imagen:
grype
El comando anterior busca vulnerabilidades visibles en el contenedor (es decir, la representación aplastada de la imagen). Para incluir software de todas las capas de la imagen en el análisis de vulnerabilidades, independientemente de su presencia en la imagen final, proporcione --scope all-layers :
grype --scope all-layers
Para ejecutar grype desde un contenedor Docker para que pueda escanear un contenedor en ejecución, use el siguiente comando:
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Grype Anchore/grype:latest $(ImageName):$(ImageTag)
Fuentes compatibles
Grype puede escanear una variedad de fuentes además de las que se encuentran en Docker.
# scan a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
grype path/to/image.tar
# scan a Singularity Image Format (SIF) container
grype path/to/image.sif
# scan a directory
grype dir:path/to/dir
Las fuentes pueden contar explícitamente con un esquema:
podman:yourrepo/yourimage:tag use images from the Podman daemon
docker:yourrepo/yourimage:tag use images from the Docker daemon
docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk
dir:path/to/yourproject read directly from a path on disk (any directory)
file:path/to/yourfile read directly from a file on disk
sbom:path/to/syft.json read Syft JSON from path on disk
registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
Si no se proporciona una fuente de imagen y no se puede detectar a partir de la referencia proporcionada, se supone que la imagen debe extraerse del demonio Docker. Si la ventana acoplable no está presente, se intenta a continuación utilizar el demonio Podman y, por último, comunicarse directamente con el registro de imágenes.
Este comportamiento predeterminado se puede anular con la opción de configuración default-image-pull-source (consulte Configuración para obtener más detalles).
Utilice SBOM para un escaneo de vulnerabilidades aún más rápido en Grype:
# Then scan for new vulnerabilities as frequently as needed
grype sbom:./sbom.json
# (You can also pipe the SBOM into Grype)
cat ./sbom.json | grype
Grype admite la entrada de formatos Syft, SPDX y CycloneDX SBOM. Si Syft ha generado alguno de estos tipos de archivos, debería tener la información adecuada para funcionar correctamente con Grype. También es posible utilizar SBOM generados por otras herramientas con distintos grados de éxito. Dos cosas que hacen que la coincidencia de Grype sea más exitosa son la inclusión de información de distribución de Linux y CPE. Si un SBOM no incluye ninguna información de CPE, es posible generarla en función de la información del paquete utilizando el indicador --add-cpes-if-none . Para especificar una distribución, utilice el indicador --distro : . Un ejemplo completo es:
No se admite ninguna versión de Grype anterior a la v0.40.1. Las versiones no compatibles no recibirán actualizaciones de software ni actualizaciones de bases de datos de vulnerabilidades. Aún puede crear bases de datos de vulnerabilidades para versiones de Grype no compatibles utilizando versiones anteriores de vunnel para recopilar los datos ascendentes y grype-db para crear bases de datos para esquemas no compatibles.
Trabajar con atestaciones
Grype admite el escaneo de SBOM como entrada a través de stdin. Los usuarios pueden usar cosign para verificar certificaciones con un SBOM como contenido para escanear una imagen en busca de vulnerabilidades:
Vulnerabilidad : toda la información sobre la vulnerabilidad específica que coincidió directamente (por ejemplo, ID, gravedad, puntuación CVSS, información de corrección, enlaces para obtener más información).
Vulnerabilidades relacionadas : información relativa a las vulnerabilidades encontradas relacionadas con la principal vulnerabilidad reportada. Quizás la vulnerabilidad con la que coincidimos fue un aviso de seguridad de GitHub, que tiene un CVE ascendente (en la base de datos nacional autorizada de vulnerabilidades). En estos casos, enumeramos aquí las vulnerabilidades ascendentes.
MatchDetails : esta sección intenta explicar qué buscamos mientras buscábamos una coincidencia y exactamente qué detalles sobre el paquete y la vulnerabilidad conducen a una coincidencia.
Artefacto : este es un subconjunto de la información que conocemos sobre el paquete (en comparación con la salida de Syft json, resumimos la sección de metadatos). Esto tiene información sobre dónde dentro de la imagen o directorio del contenedor encontramos el paquete, qué tipo de paquete es, información de licencia, pURL, CPE, etc.
Excluyendo rutas de archivos
Grype puede excluir archivos y rutas para que no se analicen dentro de una fuente mediante el uso de expresiones globales con uno o más parámetros --exclude :
grype --exclude './out/**/*.json' --exclude /etc
Nota: en el caso del escaneo de imágenes , dado que se escanea todo el sistema de archivos, es posible usar rutas absolutas como /etc o /usr/**/*.txt , mientras que los escaneos de directorios excluyen archivos relativos al directorio especificado . Por ejemplo: escanear /usr/foo con --exclude ./package.json excluiría /usr/foo/package.json y --exclude '**/package.json' excluiría todos los archivos package.json en /usr/foo . Para los análisis de directorios , es necesario comenzar las expresiones de ruta con ./ , */ o **/ , todas las cuales se resolverán en relación con el directorio de análisis especificado . Tenga en cuenta que su shell puede intentar expandir los comodines, así que coloque esos parámetros entre comillas simples, como: '**/*.json' .
Fuentes externas
Grype se puede configurar para incorporar fuentes de datos externas para mayor fidelidad en la comparación de vulnerabilidades. Actualmente, esta función está deshabilitada de forma predeterminada. Para habilitar esta función, agregue lo siguiente a la configuración de grype:
También puede configurar la URL base si está utilizando otro registro como punto final de Maven.
Formatos de salida
El formato de salida de Grype también es configurable:
grype -o
Donde los formatos disponibles son:
table : un resumen en columnas (predeterminado).
cyclonedx : un informe XML que cumple con la especificación CycloneDX 1.6.
cyclonedx-json : un informe JSON que cumple con la especificación CycloneDX 1.6.
json : ¡Utilice esto para obtener la mayor cantidad de información posible de Grype!
sarif : Utilice esta opción para obtener un informe SARIF (Formato de intercambio de resultados de análisis estático)
template : permite al usuario especificar el formato de salida. Consulte "Usar plantillas" a continuación.
Usando plantillas
Grype te permite definir formatos de salida personalizados, utilizando plantillas Go. Así es como funciona:
Defina su formato como una plantilla de Go y guarde esta plantilla como un archivo.
Establezca el formato de salida en "plantilla" ( -o template ).
Especifique la ruta al archivo de plantilla ( -t ./path/to/custom.template ).
El procesamiento de plantillas de Grype utiliza los mismos modelos de datos que el formato de salida json , por lo que si se pregunta qué datos están disponibles al crear una plantilla, puede usar la salida de grype -o json como referencia.
Tenga en cuenta: las plantillas pueden acceder a información sobre el sistema en el que se ejecutan, como las variables de entorno. Nunca debes ejecutar plantillas que no sean de confianza.
Hay varias plantillas de ejemplo en el directorio de plantillas del código fuente de Grype que pueden servir como punto de partida para un formato de salida personalizado. Por ejemplo, csv.tmpl genera un informe de vulnerabilidad en formato CSV (valores separados por comas):
También puede encontrar la plantilla para el formato de salida de "tabla" predeterminado en el mismo lugar.
Grype también incluye una amplia gama de funciones de plantillas de utilidad de sprig, además del texto/plantilla golang predeterminado, para permitir a los usuarios personalizar la salida de Grype.
Control de la gravedad de las vulnerabilidades
Puede hacer que Grype salga con un error si se informa alguna vulnerabilidad en el nivel de gravedad especificado o por encima de él. Esto resulta útil cuando se utiliza Grype dentro de un script o canalización de CI. Para hacer esto, use el indicador CLI --fail-on .
Por ejemplo, así es como podría desencadenar una falla en la canalización de CI si se encuentra alguna vulnerabilidad en la imagen ubuntu:latest con una gravedad de "media" o superior:
grype ubuntu:latest --fail-on medium
Especificar coincidencias para ignorar
Si ve que Grype informa falsos positivos o cualquier otra coincidencia de vulnerabilidad que simplemente no desea ver, puede indicarle a Grype que ignore las coincidencias especificando una o más "reglas de ignorar" en su archivo de configuración de Grype (por ejemplo, ~/.grype.yaml ). Esto hace que Grype no informe ninguna coincidencia de vulnerabilidad que cumpla con los criterios especificados por cualquiera de sus reglas de ignorar.
Cada regla puede especificar cualquier combinación de los siguientes criterios:
ID de vulnerabilidad (por ejemplo "CVE-2008-4318" )
espacio de nombres (por ejemplo, "nvd" )
estado de corrección (valores permitidos: "fixed" , "not-fixed" , "wont-fix" o "unknown" )
nombre del paquete (por ejemplo, "libcurl" )
versión del paquete (por ejemplo, "1.5.1" )
lenguaje del paquete (por ejemplo, "python" ; estos valores se definen aquí)
tipo de paquete (por ejemplo, "npm" ; estos valores se definen aquí)
ubicación del paquete (por ejemplo, "/usr/local/lib/node_modules/**" ; admite patrones globales)
Aquí hay un ejemplo ~/.grype.yaml que demuestra el formato esperado para las reglas de ignorar:
ignorar: # Este es el conjunto completo de campos de reglas admitidos:
- vulnerabilidad: CVE-2008-4318 estado de corrección: desconocido # Los campos VEX se aplican cuando Grype lee datos vex: vex-status: not_affected vex-justification: vulnerable_code_not_present paquete: nombre: libcurl versión: 1.5.1 tipo: npm ubicación: "/ usr/local/lib/node_modules/**" # Podemos crear reglas para que coincidan solo por ID de vulnerabilidad:
- vulnerabilidad: CVE-2014-54321 # ...o simplemente por un único campo de paquete:
- paquete: tipo: gema
Las coincidencias de vulnerabilidad se ignorarán si se aplica alguna regla a la coincidencia. Se considera que una regla se aplica a una coincidencia de vulnerabilidad determinada solo si todos los campos especificados en la regla se aplican a la coincidencia de vulnerabilidad.
Cuando ejecuta Grype mientras especifica reglas de ignorar, sucede lo siguiente con las coincidencias de vulnerabilidad que se "ignoran":
Las coincidencias ignoradas están completamente ocultas de la salida de Grype, excepto cuando se utilizan los formatos de salida json o template ; sin embargo, en estos dos formatos, las coincidencias ignoradas se eliminan del campo de matriz matches existente y se colocan en un nuevo campo de matriz ignoredMatches . Cada coincidencia ignorada enumerada también tiene un campo adicional, appliedIgnoreRules , que es una matriz de las reglas que causaron que Grype ignorara esta coincidencia de vulnerabilidad.
Las coincidencias ignoradas no influyen en la decisión del estado de salida de Grype cuando se usa --fail-on . Por ejemplo, si un usuario especifica --fail-on critical y todas las coincidencias de vulnerabilidad encontradas con una gravedad "crítica" han sido ignoradas , Grype saldrá de cero.
Nota: ¡Continúe informando cualquier falso positivo que vea! Incluso si puede filtrar de manera confiable los falsos positivos usando reglas de ignorar, es muy útil para la comunidad de Grype si tenemos el mayor conocimiento posible sobre los falsos positivos de Grype. ¡Esto nos ayuda a mejorar Grype continuamente!
Mostrando sólo vulnerabilidades "reparadas"
Si solo desea que Grype informe vulnerabilidades que tienen una solución confirmada , puede usar la opción --only-fixed . (Esto agrega automáticamente reglas de ignorar a la configuración de Grype, de modo que las vulnerabilidades que no estén corregidas serán ignoradas).
Por ejemplo, aquí hay un escaneo de Alpine 3.10:
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3711 Critical
libcrypto1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3712 High
libssl1.1 1.1.1k-r0 CVE-2021-3711 Critical
...y aquí está el mismo escaneo, pero agregando la bandera --only-fixed :
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Si desea que Grype solo informe vulnerabilidades que no tienen una solución confirmada , puede usar la opción --only-notfixed . Alternativamente, puede usar el indicador --ignore-states para filtrar los resultados de vulnerabilidades con estados específicos como wont-fix (consulte --help para obtener una lista de estados de reparación válidos). Estos indicadores agregan automáticamente reglas de ignorar en la configuración de Grype, de modo que las vulnerabilidades que se corrigen o que no se corregirán serán ignoradas.
Soporte VEX
Grype puede utilizar datos VEX (Vulnerability Exploitability Exchange) para filtrar falsos positivos o proporcionar contexto adicional, aumentando las coincidencias. Al escanear una imagen de contenedor, puede usar el indicador --vex para señalar uno o más documentos OpenVEX.
Las declaraciones VEX relacionan un producto (una imagen de contenedor), una vulnerabilidad y un estado VEX para expresar una afirmación del impacto de la vulnerabilidad. Hay cuatro estados VEX: not_affected , affected , fixed y under_investigation .
A continuación se muestra un ejemplo de un documento OpenVEX simple. (consejo: utilice vexctl para generar sus propios documentos).
De forma predeterminada, Grype utilizará cualquier declaración en documentos VEX específicos con un estado not_affected o fixed para mover coincidencias al conjunto de ignorar.
Cualquier coincidencia ignorada como resultado de declaraciones VEX se marca cuando se usa --show-suppressed :
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
Solo se considerará que las declaraciones con un estado affected o under_investigation aumentan el conjunto de resultados cuando se solicite específicamente mediante la variable de entorno GRYPE_VEX_ADD o en un archivo de configuración.
VEX ignorar reglas
Se pueden escribir reglas de ignorar para controlar cómo Grype respeta las declaraciones VEX. Por ejemplo, para configurar Grype para que solo actúe en declaraciones VEX cuando la justificación sea vulnerable_code_not_present , puede escribir una regla como esta:
Consulte la lista de justificaciones para obtener más detalles. Puede combinar vex-status y vex-justification con otros parámetros de reglas de ignorar.
Base de datos de Grype
Cuando Grype realiza un análisis en busca de vulnerabilidades, lo hace utilizando una base de datos de vulnerabilidades que se almacena en su sistema de archivos local, que se construye extrayendo datos de una variedad de fuentes de datos de vulnerabilidades disponibles públicamente. Estas fuentes incluyen:
SecDB de Alpine Linux: https://secdb.alpinelinux.org/
Amazon Linux ALAS: https://alas.aws.amazon.com/AL2/alas.rss
SecDB de Chainguard: https://packages.cgr.dev/chainguard/security.json
Rastreador CVE de Debian Linux: https://security-tracker.debian.org/tracker/data/json
Avisos de seguridad de GitHub (GHSA): https://github.com/advisories
Base de datos nacional de vulnerabilidad (NVD): https://nvd.nist.gov/vuln/data-feeds
Oracle Linux OVAL: https://linux.oracle.com/security/oval/
Datos de seguridad de RedHat Linux: https://access.redhat.com/hydra/rest/securitydata/
De forma predeterminada, Grype administra automáticamente esta base de datos por usted. Grype busca nuevas actualizaciones en la base de datos de vulnerabilidades para asegurarse de que cada escaneo utilice información de vulnerabilidad actualizada. Este comportamiento es configurable. Para obtener más información, consulte la sección Gestión de la base de datos de Grype.
Cómo funcionan las actualizaciones de la base de datos
La base de datos de vulnerabilidades de Grype es un archivo SQLite, llamado vulnerability.db . Las actualizaciones de la base de datos son atómicas: toda la base de datos se reemplaza y luego Grype la trata como de "solo lectura".
El primer paso de Grype en una actualización de una base de datos es descubrir bases de datos que estén disponibles para su recuperación. Grype hace esto solicitando un "archivo de listado" desde un punto final público:
Con esta información, Grype puede seleccionar la base de datos correcta (la base de datos creada más recientemente con la versión del esquema actual), descargar la base de datos y verificar la integridad de la base de datos utilizando el valor checksum enumerado.
Administrar la base de datos de Grype
Nota: ¡Durante el uso normal, no es necesario que los usuarios administren la base de datos de Grype! Grype gestiona su base de datos entre bastidores. Sin embargo, para los usuarios que necesitan más control, Grype ofrece opciones para administrar la base de datos de manera más explícita.
Directorio de caché de base de datos local
De forma predeterminada, la base de datos se almacena en caché en el sistema de archivos local en el directorio $XDG_CACHE_HOME/grype/db// . Por ejemplo, en macOS, la base de datos se almacenaría en ~/Library/Caches/grype/db/3/ . (Para obtener más información sobre las rutas XDG, consulte la Especificación del directorio base XDG).
Puede configurar la ruta del directorio de caché utilizando la variable de entorno GRYPE_DB_CACHE_DIR . Si configurar esa variable por sí sola no funciona, es posible que también sea necesario configurar la variable de entorno TMPDIR .
Estanqueidad de los datos
Grype necesita información actualizada sobre vulnerabilidades para proporcionar coincidencias precisas. De forma predeterminada, la ejecución fallará si la base de datos local no se creó en los últimos 5 días. La verificación de obsolescencia de los datos se puede configurar a través de la variable de entorno GRYPE_DB_MAX_ALLOWED_BUILT_AGE y GRYPE_DB_VALIDATE_AGE o el campo max-allowed-built-age y validate-age , en db . Utiliza la sintaxis de duración del tiempo de golang. Establezca GRYPE_DB_VALIDATE_AGE o validate-age en false para deshabilitar la verificación de obsolescencia.
Entornos sin conexión y aislados
De forma predeterminada, Grype busca una nueva base de datos en cada ejecución, realizando una llamada de red a través de Internet. Puede indicarle a Grype que no realice esta verificación configurando la variable de entorno GRYPE_DB_AUTO_UPDATE en false .
Siempre que coloque los vulnerability.db y metadata.json de Grype en el directorio de caché para la versión de esquema esperada, Grype no tendrá necesidad de acceder a la red. Además, puede obtener una lista de los archivos de bases de datos disponibles para descargar desde el comando grype db list en un entorno en línea, descargar el archivo de la base de datos, transferirlo a su entorno fuera de línea y usar grype db import para Utilice la base de datos proporcionada sin conexión.
Si desea distribuir sus propias bases de datos Grype internamente sin necesidad de utilizar db import manualmente, puede aprovechar el mecanismo de actualización de bases de datos de Grype. Para hacer esto, puede crear su propio archivo listing.json similar al que se encuentra públicamente (consulte grype db list -o raw para ver un ejemplo de nuestro archivo listing.json público) y cambiar la URL de descarga para que apunte a un punto final interno (p. ej. un depósito S3 privado, un servidor de archivos interno, etc.). Cualquier instalación interna de Grype puede recibir actualizaciones de la base de datos automáticamente configurando db.update-url (igual que la variable de entorno GRYPE_DB_UPDATE_URL ) para que apunte al archivo listing.json alojado que ha creado.
Comandos CLI para la gestión de bases de datos
Grype proporciona comandos CLI específicos de la base de datos para los usuarios que desean controlar la base de datos desde la línea de comandos. Éstos son algunos de los comandos útiles proporcionados:
grype db status : informa el estado actual de la base de datos de Grype (como su ubicación, fecha de compilación y suma de verificación)
grype db check : vea si hay actualizaciones disponibles para la base de datos
grype db update : asegúrese de que se haya descargado la última base de datos en el directorio de caché (Grype realiza esta operación al comienzo de cada análisis de forma predeterminada)
grype db list : descargue el archivo de listado configurado en db.update-url y muestre las bases de datos que están disponibles para descargar
grype db import : proporciona a grype un archivo de base de datos para usarlo explícitamente (útil para actualizaciones de bases de datos sin conexión)
grype db providers : proporciona una lista detallada de proveedores de bases de datos
Encuentre información completa sobre los comandos de la base de datos de Grype ejecutando grype db --help .
Finalización del caparazón
Grype proporciona finalización de shell a través de su implementación CLI (cobra). Genere el código de finalización para su shell ejecutando uno de los siguientes comandos:
grype completion
go run ./cmd/grype completion
Esto generará un script de shell en STDOUT, que luego se puede usar como script de finalización para Grype. Ejecutar uno de los comandos anteriores con los indicadores -h o --help proporcionará instrucciones sobre cómo hacerlo para el shell elegido.
Autenticación de registro privado
Credenciales locales de Docker
Cuando no hay un tiempo de ejecución de contenedor, grype aún puede utilizar credenciales configuradas en fuentes de credenciales comunes (como ~/.docker/config.json ). Extraerá imágenes de registros privados utilizando estas credenciales. El archivo de configuración es donde se almacenan sus credenciales cuando se autentica con registros privados mediante algún comando como docker login . Para obtener más información, consulte la documentación go-containerregistry .
Puede ejecutar el siguiente comando como ejemplo. Detalla la configuración de montaje/entorno que un contenedor necesita para acceder a un registro privado:
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Credenciales Docker en Kubernetes
La siguiente sección muestra un flujo de trabajo simple sobre cómo montar este archivo de configuración como secreto en un contenedor en Kubernetes.
Crea un secreto. El valor de config.json es importante. Se refiere a la especificación detallada aquí. Debajo de esta sección se encuentra el archivo secret.yaml que la configuración del pod consumirá como volumen. La clave config.json es importante. Terminará siendo el nombre del archivo cuando se monte en el pod.
Crea tu pod ejecutando grype. El entorno DOCKER_CONFIG es importante porque anuncia dónde buscar el archivo de credenciales. En el siguiente ejemplo, configurar DOCKER_CONFIG=/config le informa a grype que las credenciales se pueden encontrar en /config/config.json . Es por eso que usamos config.json como clave para nuestro secreto. Cuando se monta en contenedores, la clave secreta se utiliza como nombre de archivo. La sección volumeMounts monta nuestro secreto en /config . La sección volumes nombra nuestro volumen y aprovecha el secreto que creamos en el paso uno.
El usuario ahora puede ejecutar kubectl logs grype-private-registry-demo . Los registros deben mostrar el análisis de grype para la proporcionada en la configuración del pod.
Con la información anterior, los usuarios deberían poder configurar el acceso privado al registro sin tener que hacerlo en los archivos de configuración grype o syft . Tampoco dependerán de un demonio acoplable (o de algún otro software de ejecución) para la configuración y el acceso al registro.
Configuración
Rutas de búsqueda de configuración predeterminadas (ver todas grype config locations ):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
Utilice grype config para imprimir un archivo de configuración de muestra en la salida estándar. Utilice grype config --load para imprimir la configuración actual después de cargar todos los valores en la salida estándar.
Puede especificar archivos directamente usando los indicadores --config / -c para proporcionar sus propios archivos/rutas de configuración:
grype -c /path/to/config.yaml
Opciones de configuración (los valores de ejemplo son los predeterminados):
# habilitar/deshabilitar la verificación de actualizaciones de la aplicación al inicio# igual que GRYPE_CHECK_FOR_APP_UPDATE env varcheck-for-app-update: true# permite a los usuarios especificar qué fuente de imagen debe usarse para generar el sbom# los valores válidos son: registro, ventana acoplable, podman# igual que GRYPE_DEFAULT_IMAGE_PULL_SOURCE env vardefault-image-pull-source: ""# igual que --name; establezca el nombre del objetivo que se analiza nombre: ""# al escanear, si se encuentra una gravedad igual o superior a la gravedad dada, el código de retorno será 1# el valor predeterminado no está configurado, lo que omitirá esta validación (opciones: insignificante, bajo, medio , alto, crítico)# igual que --fail-on ; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""# el formato de salida del informe de vulnerabilidad (opciones: tabla, plantilla, json, cyclonedx)# cuando utilice plantilla como tipo de salida, también debe proporcionar un valor para 'output-template- archivo'# igual que -o; GRYPE_OUTPUT env varoutput: "table"# si usa la salida de la plantilla, debe proporcionar una ruta a un archivo de plantilla de Go# consulte https://github.com/anchore/grype#using-templates para obtener más información sobre la salida de la plantilla# la ruta predeterminada al archivo de plantilla está el directorio de trabajo actual# archivo-plantilla-salida: .grype/html.tmpl# escribe el informe de salida en un archivo (el valor predeterminado es escribir en la salida estándar)# igual que --file; GRYPE_FILE env varfile: ""# una lista de globos que se excluirán del análisis, por ejemplo:# excluir:# - '/etc/**'# - './out/**/*.json'# igual que -- excluir; GRYPE_EXCLUDE env varexclude: []# incluye coincidencias en paquetes de encabezados del kernel que coinciden con el paquete del kernel ascendente# si es 'falso', dichas coincidencias se marcan como ignoradasmatch-upstream-kernel-headers: false# sistema operativo y/o arquitectura a usar cuando haciendo referencia a imágenes de contenedores (por ejemplo, "windows/armv6" o "arm64")# igual que --platform; GRYPE_PLATFORM env varplatform: ""# Si usa la entrada SBOM, genere automáticamente CPE cuando los paquetes no tengan ningunoadd-cpes-if-none: false# Especifique explícitamente una distribución de Linux para usar como : como alpine:3.10distro:external -sources: enable: false maven: search-upstream-by-sha1: true base-url: https://repo1.maven.org/maven2db: # comprobar si hay actualizaciones de la base de datos durante la ejecución # igual que GRYPE_DB_AUTO_UPDATE env var auto-update: true # ubicación para escribir el caché de la base de datos de vulnerabilidades; El valor predeterminado es $XDG_CACHE_HOME/grype/db # Igual que GRYPE_DB_CACHE_DIR env var cache-dir: "" # URL de la base de datos de vulnerabilidades # Igual que GRYPE_DB_UPDATE_URL env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # garantiza que la compilación de la base de datos no sea anterior a la edad máxima permitida de construcción # se establece en falso para deshabilitar la verificación de validación-edad: verdadero # Edad máxima permitida para la base de datos de vulnerabilidad, siendo # la edad el tiempo transcurrido desde se creó # La edad máxima predeterminada es 120 h (o cinco días) max-allowed-built-age: "120 h" # Tiempo de espera para descargar GRYPE_DB_UPDATE_URL para ver si es necesario descargar la base de datos # Este archivo pesa ~156 KB a partir de 2024-04 -17 por lo que la descarga debería ser rápida; ajuste según sea necesario update-available-timeout: "30s" # Tiempo de espera para descargar la base de datos de vulnerabilidad real # La base de datos es ~156 MB a partir del 17 de abril de 2024, por lo que las conexiones más lentas pueden exceder el tiempo de espera predeterminado; ajuste según sea necesario update-download-timeout: "120s"search: # el espacio de búsqueda para buscar paquetes (opciones: todas las capas, aplastado) # igual que -s; GRYPE_SEARCH_SCOPE env var alcance: "aplastado" # búsqueda dentro de archivos que contienen un índice de archivo para buscar (zip) # nota: por ahora esto solo se aplica al catalogador de paquetes java # igual que GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var indexed-archives: true # búsqueda dentro de archivos que no contienen un índice de archivo para buscar (tar, tar.gz, tar.bz2, etc.) # nota: habilitar esto puede tener como resultado un impacto en el rendimiento ya que todos los archivos tar comprimidos descubiertos se descomprimirán # nota: por ahora esto solo se aplica al catalogador de paquetes java # igual que GRYPE_PACKAGE_SEARCH_UNINDEXED_ARCHIVES env var unindexed-archives: false# opciones al extraer directamente de un registro a través del "registro:" esquemaregistry: # omitir la verificación TLS cuando se comunica con el registro # igual que GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var insecure -skip-tls-verify: false # use http en lugar de https al conectarse al registro # igual que GRYPE_REGISTRY_INSECURE_USE_HTTP env var insecure-use-http: false # ruta de archivo a un certificado de CA (o directorio que contiene *.crt, *.cert, *.pem) utilizado para generar el certificado de cliente # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # credenciales para registros específicos auth: # la URL del registro (por ejemplo, "docker.io", "localhost:5000", etc.) # GRYPE_REGISTRY_AUTH_AUTHORITY var env
- autoridad: "" # GRYPE_REGISTRY_AUTH_USERNAME env var nombre de usuario: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var contraseña: "" # nota: el token y el nombre de usuario/contraseña son mutuamente excluyentes # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # ruta de archivo al certificado de cliente utilizado para la autenticación TLS al registro # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # ruta de archivo a la clave del cliente utilizada para la autenticación TLS en el registro # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # nota, se pueden proporcionar más credenciales a través de solo archivo de configuración (no env vars) log: # suprimir todos los resultados (excepto la lista de vulnerabilidades) # igual que -q; GRYPE_LOG_QUIET env var quiet: false # aumentar la verbosidad # igual que GRYPE_LOG_VERBOSITY env var verbosity: 0 # el nivel de registro; nota: el registro detallado suprime el ETUI # igual que GRYPE_LOG_LEVEL env var # Utiliza niveles de registro de logrus: https://github.com/sirupsen/logrus#level-logging nivel: "error" # ubicación para escribir el archivo de registro (el valor predeterminado no es tener un archivo de registro) # igual que el archivo env var GRYPE_LOG_FILE: ""match: # configura los comparadores siguientes para usar cpes al intentar encontrar # coincidencias de vulnerabilidad. El comparador de acciones es el número predeterminado cuando no se puede identificar ningún comparador principal. java: usando-cpes: falso python: usando-cpes: falso javascript: usando-cpes: falso ruby: usando-cpes: falso dotnet: usando-cpes: falso golang: usando-cpes: falso # incluso si la coincidencia de CPE está deshabilitada, haga una excepción al buscar "stdlib". Always-use-cpe-for-stdlib: true # permite que las pseudoversiones del módulo principal, que quizás sólo hayan sido "adivinadas" por Syft, se utilicen en la comparación de vulnerabilidades enable-main-module-pseudo-version-comparison: false stock : usando-cpes: verdadero
Planes futuros
Actualmente se están investigando las siguientes áreas de potencial desarrollo:
Soporte para listas permitidas y mapeo de paquetes.
