Um scanner de vulnerabilidade para imagens de contêiner e sistemas de arquivos. Instale facilmente o binário para testá-lo. Funciona com Syft, a poderosa ferramenta SBOM (lista de materiais de software) para imagens de contêiner e sistemas de arquivos.
Agenda: https://docs.google.com/document/d/1ZtSAa6fj2a6KRWviTn3WoJm09edvrNUp4Iz_dOjjyY8/edit?usp=sharing (junte-se a este grupo para acesso de gravação)
Todos são bem-vindos!
Para opções de suporte comercial com Syft ou Grype, entre em contato com Anchore
Características
Analise o conteúdo de uma imagem de contêiner ou sistema de arquivos para encontrar vulnerabilidades conhecidas.
Encontre vulnerabilidades para os principais pacotes do sistema operacional:
Alpino
Amazon Linux
OcupadoBox
CentOS
CBL-Mariner
Debian
Sem distração
OracleLinux
Chapéu Vermelho (RHEL)
Ubuntu
Lobo
Encontre vulnerabilidades para pacotes específicos de idiomas:
Suporta formatos de imagem Docker, OCI e Singularity.
Suporte OpenVEX para filtrar e aumentar os resultados da verificação.
Se você encontrar um problema, informe-nos usando o rastreador de problemas.
Instalação
Recomendado
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Instalar opções de script:
-b : Especifique um diretório de instalação personalizado (o padrão é ./bin )
-d : níveis de registro mais detalhados ( -d para depuração, -dd para rastreamento)
-v : Verifique a assinatura do artefato baixado antes da instalação (requer que cosign seja instalado)
Chocolate
A distribuição achocolatada do grype é mantida pela comunidade e não distribuída pela equipe âncora.
choco instalar grype -y
Cerveja caseira
torneira de cerveja âncora/grype
preparar instalar grype
MacPorts
No macOS, o Grype também pode ser instalado a partir da porta mantida pela comunidade via MacPorts:
porta sudo instalar grype
Nota : Atualmente, o Grype é desenvolvido apenas para macOS e Linux.
Da fonte
Consulte DEVELOPING.md para obter instruções sobre como construir e executar a partir do código-fonte.
Ações do GitHub
Se estiver usando GitHub Actions, você pode usar nossa ação baseada em Grype para executar verificações de vulnerabilidade em seu código ou imagens de contêiner durante seus fluxos de trabalho de CI.
Verificando os artefatos
As somas de verificação são aplicadas a todos os artefatos e o arquivo de soma de verificação resultante é assinado usando cosign.
Você precisa da seguinte ferramenta para verificar a assinatura:
Fiador
As etapas de verificação são as seguintes:
Baixe os arquivos desejados e os arquivos checksums.txt, checksums.txt.pem e checksums.txt.sig na página de lançamentos:
Depois que a assinatura for confirmada como válida, você poderá validar se as somas SHA256 estão alinhadas com o artefato baixado:
sha256sum --ignore-missing -c somas de verificação.txt
Começando
Instale o binário e certifique-se de que grype esteja disponível em seu caminho. Para verificar vulnerabilidades em uma imagem:
grype
O comando acima verifica vulnerabilidades visíveis no contêiner (ou seja, a representação comprimida da imagem). Para incluir software de todas as camadas da imagem na verificação de vulnerabilidades, independentemente de sua presença na imagem final, forneça --scope all-layers :
grype --scope all-layers
Para executar o grype a partir de um contêiner Docker para que ele possa verificar um contêiner em execução, use o seguinte comando:
docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock --name Arquivo âncora/grype:latest $(ImageName):$(ImageTag)
Fontes suportadas
O Grype pode verificar uma variedade de fontes além daquelas encontradas no 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
As fontes podem ser fornecidas explicitamente com um 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)
Se uma fonte de imagem não for fornecida e não puder ser detectada a partir da referência fornecida, presume-se que a imagem deve ser extraída do daemon Docker. Se o docker não estiver presente, o daemon Podman será tentado em seguida, seguido de acesso direto ao registro de imagem por último.
Este comportamento padrão pode ser substituído pela opção de configuração default-image-pull-source (consulte Configuração para obter mais detalhes).
Use SBOMs para uma verificação de vulnerabilidades ainda mais rápida no 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 suporta entrada dos formatos Syft, SPDX e CycloneDX SBOM. Se o Syft gerou algum desses tipos de arquivo, ele deverá ter as informações apropriadas para funcionar corretamente com o Grype. Também é possível utilizar SBOMs gerados por outras ferramentas com graus variados de sucesso. Duas coisas que tornam a correspondência do Grype mais bem-sucedida são a inclusão de informações de distribuição do CPE e do Linux. Se um SBOM não incluir nenhuma informação de CPE, é possível gerá-las com base nas informações do pacote usando o sinalizador --add-cpes-if-none . Para especificar uma distribuição, use o sinalizador --distro : . Um exemplo completo é:
Qualquer versão do Grype anterior à v0.40.1 não é suportada. As versões não suportadas não receberão nenhuma atualização de software ou de banco de dados de vulnerabilidades. Você ainda pode construir bancos de dados de vulnerabilidade para versões não suportadas do Grype usando versões anteriores do vunnel para coletar os dados upstream e grype-db para construir bancos de dados para esquemas não suportados.
Trabalhando com atestados
Grype suporta digitalização de SBOMs como entrada via stdin. Os usuários podem usar cosign para verificar atestados com um SBOM como seu conteúdo para verificar vulnerabilidades em uma imagem:
Vulnerabilidade : todas as informações sobre a vulnerabilidade específica que foi diretamente correspondida (por exemplo, ID, gravidade, pontuação CVSS, informações de correção, links para mais informações)
Vulnerabilidades Relacionadas : Informações relativas às vulnerabilidades consideradas relacionadas à principal vulnerabilidade relatada. Talvez a vulnerabilidade que encontramos tenha sido um comunicado de segurança do GitHub, que possui um CVE upstream (no banco de dados de vulnerabilidades nacional confiável). Nestes casos listamos as vulnerabilidades upstream aqui.
MatchDetails : Esta seção tenta explicar o que procuramos enquanto procurávamos uma correspondência e exatamente quais detalhes do pacote e da vulnerabilidade que levam a uma correspondência.
Artefato : Este é um subconjunto das informações que conhecemos sobre o pacote (quando comparado com a saída JSON do Syft, resumimos a seção de metadados). Contém informações sobre onde encontramos o pacote na imagem ou diretório do contêiner, que tipo de pacote é, informações de licenciamento, pURLs, CPEs, etc.
Excluindo caminhos de arquivo
O Grype pode excluir arquivos e caminhos da verificação em uma fonte usando expressões glob com um ou mais parâmetros --exclude :
grype --exclude './out/**/*.json' --exclude /etc
Nota: no caso de varredura de imagens , como todo o sistema de arquivos é varrido, é possível usar caminhos absolutos como /etc ou /usr/**/*.txt , enquanto as varreduras de diretório excluem arquivos relativos ao diretório especificado . Por exemplo: verificar /usr/foo com --exclude ./package.json excluiria /usr/foo/package.json e --exclude '**/package.json' excluiria todos os arquivos package.json em /usr/foo . Para varreduras de diretório , é necessário iniciar as expressões de caminho com ./ , */ ou **/ , e todas serão resolvidas em relação ao diretório de varredura especificado . Tenha em mente que seu shell pode tentar expandir curingas, então coloque esses parâmetros entre aspas simples, como: '**/*.json' .
Fontes Externas
O Grype pode ser configurado para incorporar fontes de dados externas para maior fidelidade na correspondência de vulnerabilidades. Este recurso está desabilitado por padrão. Para ativar esse recurso, adicione o seguinte à configuração do grype:
Você também pode configurar o URL base se estiver usando outro registro como endpoint maven.
Formatos de saída
O formato de saída do Grype também é configurável:
grype -o
Onde os formatos disponíveis são:
table : um resumo colunar (padrão).
cyclonedx : Um relatório XML em conformidade com a especificação CycloneDX 1.6.
cyclonedx-json : Um relatório JSON em conformidade com a especificação CycloneDX 1.6.
json : Use isso para obter o máximo de informações possível do Grype!
sarif : Use esta opção para obter um relatório SARIF (Static Analysis Results Interchange Format)
template : permite que o usuário especifique o formato de saída. Consulte "Usando modelos" abaixo.
Usando modelos
Grype permite definir formatos de saída personalizados, usando modelos Go. Veja como funciona:
Defina seu formato como um modelo Go e salve esse modelo como um arquivo.
Defina o formato de saída como "template" ( -o template ).
Especifique o caminho para o arquivo de modelo ( -t ./path/to/custom.template ).
O processamento de modelo do Grype usa os mesmos modelos de dados que o formato de saída json — portanto, se você está se perguntando quais dados estão disponíveis ao criar um modelo, você pode usar a saída de grype -o json como referência.
Observação: os modelos podem acessar informações sobre o sistema em que estão sendo executados, como variáveis de ambiente. Você nunca deve executar modelos não confiáveis.
Existem vários modelos de exemplo no diretório de modelos da fonte do Grype que podem servir como ponto de partida para um formato de saída personalizado. Por exemplo, csv.tmpl produz um relatório de vulnerabilidade no formato CSV (valor separado por vírgula):
Você também pode encontrar o modelo para o formato de saída de “tabela” padrão no mesmo lugar.
O Grype também inclui uma vasta gama de funções de modelagem utilitária do sprig, além do texto/modelo padrão do golang, para permitir que os usuários personalizem a saída do Grype.
Controle da gravidade das vulnerabilidades
Você pode fazer com que o Grype saia com um erro se alguma vulnerabilidade for relatada no nível de gravidade especificado ou acima dele. Isso é útil ao usar o Grype em um script ou pipeline de CI. Para fazer isso, use o sinalizador CLI --fail-on .
Por exemplo, veja como você pode acionar uma falha no pipeline de CI se alguma vulnerabilidade for encontrada na imagem ubuntu:latest com gravidade "média" ou superior:
grype ubuntu:latest --fail-on medium
Especificando correspondências para ignorar
Se você estiver vendo o Grype relatar falsos positivos ou qualquer outra correspondência de vulnerabilidade que você simplesmente não deseja ver, você pode dizer ao Grype para ignorar as correspondências especificando uma ou mais "regras de ignorar" em seu arquivo de configuração do Grype (por exemplo, ~/.grype.yaml ). Isso faz com que o Grype não relate nenhuma correspondência de vulnerabilidade que atenda aos critérios especificados por qualquer uma de suas regras de ignorar.
Cada regra pode especificar qualquer combinação dos seguintes critérios:
ID de vulnerabilidade (por exemplo "CVE-2008-4318" )
espaço para nome (por exemplo, "nvd" )
estado de correção (valores permitidos: "fixed" , "not-fixed" , "wont-fix" ou "unknown" )
nome do pacote (por exemplo, "libcurl" )
versão do pacote (por exemplo, "1.5.1" )
linguagem do pacote (por exemplo, "python" ; esses valores são definidos aqui)
tipo de pacote (por exemplo, "npm" ; esses valores são definidos aqui)
localização do pacote (por exemplo, "/usr/local/lib/node_modules/**" ; suporta padrões glob)
Aqui está um exemplo ~/.grype.yaml que demonstra o formato esperado para ignorar regras:
ignore: # Este é o conjunto completo de campos de regras suportados:
- vulnerabilidade: CVE-2008-4318 fix-state: desconhecido # Campos VEX se aplicam quando Grype lê dados vex: vex-status: not_affected vex-justification: vulnerável_code_not_present pacote: nome: libcurl versão: 1.5.1 tipo: npm local: "/ usr/local/lib/node_modules/**" # Podemos criar regras para corresponder apenas pelo ID da vulnerabilidade:
- vulnerabilidade: CVE-2014-54321 # ...ou apenas por um único campo de pacote:
- pacote: tipo: gema
As correspondências de vulnerabilidade serão ignoradas se alguma regra se aplicar à correspondência. Considera-se que uma regra se aplica a uma determinada correspondência de vulnerabilidade somente se todos os campos especificados na regra se aplicarem à correspondência de vulnerabilidade.
Quando você executa o Grype enquanto especifica regras para ignorar, acontece o seguinte com as correspondências de vulnerabilidade que são "ignoradas":
As correspondências ignoradas ficam completamente ocultas da saída do Grype, exceto ao usar os formatos de saída json ou template ; entretanto, nesses dois formatos, as correspondências ignoradas são removidas do campo de matriz matches existente e são colocadas em um novo campo de matriz ignoredMatches . Cada correspondência ignorada listada também possui um campo adicional, appliedIgnoreRules , que é uma matriz de quaisquer regras que fizeram com que o Grype ignorasse essa correspondência de vulnerabilidade.
As correspondências ignoradas não influenciam a decisão do status de saída do Grype ao usar --fail-on . Por exemplo, se um usuário especificar --fail-on critical e todas as correspondências de vulnerabilidade encontradas com uma gravidade "crítica" tiverem sido ignoradas , o Grype sairá do zero.
Observação: continue relatando quaisquer falsos positivos que você encontrar! Mesmo que você possa filtrar falsos positivos de maneira confiável usando regras de ignorar, será muito útil para a comunidade Grype se tivermos o máximo de conhecimento possível sobre os falsos positivos do Grype. Isso nos ajuda a melhorar continuamente o Grype!
Mostrando apenas vulnerabilidades "corrigidas"
Se você deseja que o Grype relate apenas vulnerabilidades que tenham uma correção confirmada , você pode usar o sinalizador --only-fixed . (Isso adiciona automaticamente regras de ignorar à configuração do Grype, de modo que as vulnerabilidades que não forem corrigidas serão ignoradas.)
Por exemplo, aqui está uma varredura do 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
...e aqui está a mesma varredura, mas adicionando o sinalizador --only-fixed :
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
apk-tools 2.10.6-r0 2.10.7-r0 CVE-2021-36159 Critical
Se quiser que o Grype relate apenas vulnerabilidades que não tenham uma correção confirmada , você pode usar o sinalizador --only-notfixed . Como alternativa, você pode usar o sinalizador --ignore-states para filtrar resultados de vulnerabilidades com estados específicos, como wont-fix (consulte --help para obter uma lista de estados de correção válidos). Esses sinalizadores adicionam automaticamente regras de ignorar na configuração do Grype, de modo que as vulnerabilidades que foram corrigidas ou não serão corrigidas serão ignoradas.
Suporte VEX
Grype pode usar dados VEX (Vulnerability Exploitability Exchange) para filtrar falsos positivos ou fornecer contexto adicional, aumentando as correspondências. Ao digitalizar uma imagem de contêiner, você pode usar o sinalizador --vex para apontar para um ou mais documentos OpenVEX.
As declarações VEX relacionam um produto (uma imagem de contêiner), uma vulnerabilidade e um status VEX para expressar uma afirmação do impacto da vulnerabilidade. Existem quatro status VEX: not_affected , affected , fixed e under_investigation .
Aqui está um exemplo de um documento OpenVEX simples. (dica: use vexctl para gerar seus próprios documentos).
Por padrão, o Grype usará quaisquer instruções em documentos VEX especificados com status not_affected ou fixed para mover correspondências para o conjunto de ignorados.
Quaisquer correspondências ignoradas como resultado de instruções VEX são sinalizadas ao usar --show-suppressed :
libcrypto3 3.0.8-r3 3.0.8-r4 apk CVE-2023-1255 Medium (suppressed by VEX)
Instruções com status affected ou under_investigation só serão consideradas para aumentar o conjunto de resultados quando solicitadas especificamente usando a variável de ambiente GRYPE_VEX_ADD ou em um arquivo de configuração.
Regras para ignorar VEX
Regras de ignorar podem ser escritas para controlar como o Grype respeita as instruções VEX. Por exemplo, para configurar o Grype para agir apenas nas instruções VEX quando a justificativa for vulnerable_code_not_present , você pode escrever uma regra como esta:
---ignorar:
- status vex: not_affected vex-justificação: vulnerável_code_not_present
Veja a lista de justificativas para detalhes. Você pode misturar vex-status e vex-justification com outros parâmetros de regra para ignorar.
Banco de dados do Grype
Quando o Grype realiza uma verificação de vulnerabilidades, ele o faz usando um banco de dados de vulnerabilidades armazenado em seu sistema de arquivos local, que é construído extraindo dados de uma variedade de fontes de dados de vulnerabilidade disponíveis publicamente. Essas fontes incluem:
Alpine Linux SecDB: https://secdb.alpinelinux.org/
Amazon Linux ALAS: https://alas.aws.amazon.com/AL2/alas.rss
Por padrão, o Grype gerencia automaticamente esse banco de dados para você. O Grype verifica se há novas atualizações no banco de dados de vulnerabilidades para garantir que cada verificação use informações de vulnerabilidade atualizadas. Esse comportamento é configurável. Para obter mais informações, consulte a seção Gerenciando o banco de dados do Grype.
Como funcionam as atualizações do banco de dados
O banco de dados de vulnerabilidades do Grype é um arquivo SQLite, denominado vulnerability.db . As atualizações do banco de dados são atômicas: todo o banco de dados é substituído e então tratado como “somente leitura” pelo Grype.
O primeiro passo do Grype em uma atualização de banco de dados é descobrir os bancos de dados que estão disponíveis para recuperação. Grype faz isso solicitando um “arquivo de listagem” de um endpoint público:
Com essas informações, o Grype pode selecionar o banco de dados correto (o banco de dados construído mais recentemente com a versão do esquema atual), fazer download do banco de dados e verificar a integridade do banco de dados usando o valor da soma checksum listado.
Gerenciando o banco de dados do Grype
Nota: Durante o uso normal, os usuários não precisam gerenciar o banco de dados do Grype! Grype gerencia seu banco de dados nos bastidores. Porém, para usuários que precisam de mais controle, o Grype oferece opções para gerenciar o banco de dados de forma mais explícita.
Diretório de cache do banco de dados local
Por padrão, o banco de dados é armazenado em cache no sistema de arquivos local no diretório $XDG_CACHE_HOME/grype/db// . Por exemplo, no macOS, o banco de dados seria armazenado em ~/Library/Caches/grype/db/3/ . (Para obter mais informações sobre caminhos XDG, consulte a especificação do diretório base XDG.)
Você pode definir o caminho do diretório de cache usando a variável de ambiente GRYPE_DB_CACHE_DIR . Se definir essa variável sozinha não funcionar, então a variável de ambiente TMPDIR também poderá precisar ser definida.
Desatualização dos dados
Grype precisa de informações atualizadas sobre vulnerabilidades para fornecer correspondências precisas. Por padrão, a execução falhará se o banco de dados local não tiver sido construído nos últimos 5 dias. A verificação de inatividade dos dados é configurável por meio da variável de ambiente GRYPE_DB_MAX_ALLOWED_BUILT_AGE e GRYPE_DB_VALIDATE_AGE ou do campo max-allowed-built-age e validate-age , em db . Ele usa a sintaxe de duração do golang. Defina GRYPE_DB_VALIDATE_AGE ou validate-age como false para desabilitar a verificação de inatividade.
Ambientes offline e isolados
Por padrão, o Grype verifica um novo banco de dados a cada execução, fazendo uma chamada de rede pela Internet. Você pode dizer ao Grype para não realizar esta verificação definindo a variável de ambiente GRYPE_DB_AUTO_UPDATE como false .
Contanto que você coloque os arquivos vulnerability.db e metadata.json do Grype no diretório de cache da versão do esquema esperada, o Grype não precisará acessar a rede. Além disso, você pode obter uma lista dos arquivos de banco de dados disponíveis para download a partir do comando grype db list em um ambiente online, baixar o arquivo de banco de dados, transferi-lo para seu ambiente offline e usar grype db import para use o banco de dados fornecido em uma capacidade offline.
Se você deseja distribuir seus próprios bancos de dados Grype internamente sem precisar usar db import manualmente, você pode aproveitar o mecanismo de atualização de banco de dados do Grype. Para fazer isso, você pode criar seu próprio arquivo listing.json semelhante ao encontrado publicamente (consulte grype db list -o raw para obter um exemplo de nosso arquivo listing.json público) e alterar o URL de download para apontar para um terminal interno (por exemplo, um bucket S3 privado, um servidor de arquivos interno, etc.). Qualquer instalação interna do Grype pode receber atualizações de banco de dados automaticamente configurando o db.update-url (igual à variável de ambiente GRYPE_DB_UPDATE_URL ) para apontar para o arquivo listing.json hospedado que você criou.
Comandos CLI para gerenciamento de banco de dados
Grype fornece comandos CLI específicos do banco de dados para usuários que desejam controlar o banco de dados a partir da linha de comando. Aqui estão alguns dos comandos úteis fornecidos:
grype db status — informa o status atual do banco de dados do Grype (como localização, data de construção e soma de verificação)
grype db check — veja se há atualizações disponíveis para o banco de dados
grype db update — certifique-se de que o banco de dados mais recente foi baixado para o diretório de cache (o Grype executa esta operação no início de cada varredura por padrão)
grype db list — baixe o arquivo de listagem configurado em db.update-url e mostre os bancos de dados que estão disponíveis para download
grype db import — fornece ao grype um arquivo de banco de dados para uso explícito (útil para atualizações de banco de dados offline)
grype db providers - fornece uma lista detalhada de provedores de banco de dados
Encontre informações completas sobre os comandos do banco de dados do Grype executando grype db --help .
Conclusão do shell
Grype fornece preenchimento de shell por meio de sua implementação CLI (cobra). Gere o código de conclusão do seu shell executando um dos seguintes comandos:
grype completion
go run ./cmd/grype completion
Isso gerará um script de shell para STDOUT, que pode então ser usado como um script de conclusão para o Grype. A execução de um dos comandos acima com os sinalizadores -h ou --help fornecerá instruções sobre como fazer isso para o shell escolhido.
Autenticação de Registro Privado
Credenciais locais do Docker
Quando um tempo de execução de contêiner não está presente, o grype ainda pode utilizar credenciais configuradas em fontes de credenciais comuns (como ~/.docker/config.json ). Ele extrairá imagens de registros privados usando essas credenciais. O arquivo de configuração é onde suas credenciais são armazenadas durante a autenticação com registros privados por meio de algum comando como docker login . Para obter mais informações, consulte a documentação go-containerregistry .
Você pode executar o seguinte comando como exemplo. Ele detalha a configuração de montagem/ambiente que um contêiner precisa para acessar um registro privado:
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/grype:latest
Credenciais Docker no Kubernetes
A seção abaixo mostra um fluxo de trabalho simples sobre como montar este arquivo de configuração como um segredo em um contêiner no Kubernetes.
Crie um segredo. O valor de config.json é importante. Refere-se à especificação detalhada aqui. Abaixo desta seção está o arquivo secret.yaml que a configuração do pod consumirá como um volume. A chave config.json é importante. Acabará sendo o nome do arquivo quando montado no pod.
Crie seu pod executando o grype. O env DOCKER_CONFIG é importante porque anuncia onde procurar o arquivo de credencial. No exemplo abaixo, a configuração DOCKER_CONFIG=/config informa ao grype que as credenciais podem ser encontradas em /config/config.json . É por isso que usamos config.json como chave do nosso segredo. Quando montado em contêineres, a chave dos segredos é usada como nome do arquivo. A seção volumeMounts monta nosso segredo em /config . A seção volumes nomeia nosso volume e aproveita o segredo que criamos na primeira etapa.
O usuário agora pode executar kubectl logs grype-private-registry-demo . Os logs devem mostrar a análise do grype para fornecida na configuração do pod.
Usando as informações acima, os usuários deverão ser capazes de configurar o acesso ao registro privado sem precisar fazê-lo nos arquivos de configuração grype ou syft . Eles também não dependerão de um daemon docker (ou de algum outro software de tempo de execução) para configuração e acesso ao registro.
Configuração
Caminhos de pesquisa de configuração padrão (veja todos com grype config locations ):
.grype.yaml
.grype/config.yaml
~/.grype.yaml
/grype/config.yaml
Use grype config para imprimir um arquivo de configuração de amostra no stdout. Use grype config --load para imprimir a configuração atual após carregar todos os valores no stdout.
Você pode especificar arquivos diretamente usando os sinalizadores --config / -c para fornecer seus próprios arquivos/caminhos de configuração:
grype -c /path/to/config.yaml
Opções de configuração (valores de exemplo são o padrão):
# ativa/desativa a verificação de atualizações de aplicativos na inicialização# igual a GRYPE_CHECK_FOR_APP_UPDATE env varcheck-for-app-update: true# permite que os usuários especifiquem qual fonte de imagem deve ser usada para gerar o sbom# os valores válidos são: registro, docker, podman# igual a GRYPE_DEFAULT_IMAGE_PULL_SOURCE env vardefault-image-pull-source: ""# igual a --name; defina o nome do alvo que está sendo analisadonome: ""# na varredura, se uma gravidade for encontrada igual ou superior à gravidade especificada, o código de retorno será 1# o padrão é não definido, o que ignorará esta validação (opções: insignificante, baixo, médio , alto, crítico)# igual a --fail-on ; GRYPE_FAIL_ON_SEVERITY env varfail-on-severity: ""# o formato de saída do relatório de vulnerabilidade (opções: tabela, modelo, json, cyclonedx)# ao usar modelo como tipo de saída, você também deve fornecer um valor para 'output-template- arquivo'# igual a -o ; GRYPE_OUTPUT env varoutput: "table"# se estiver usando a saída do modelo, você deve fornecer um caminho para um arquivo de modelo Go# consulte https://github.com/anchore/grype#using-templates para obter mais informações sobre a saída do modelo# o caminho padrão para o arquivo de modelo está o diretório de trabalho atual# arquivo de modelo de saída: .grype/html.tmpl# escreve o relatório de saída em um arquivo (o padrão é gravar em stdout)# igual a --file; GRYPE_FILE env varfile: ""# uma lista de globs a serem excluídos da verificação, por exemplo:# exclude:# - '/etc/**'# - './out/**/*.json'# igual a -- excluir; GRYPE_EXCLUDE env varexclude: []# inclui correspondências em pacotes de cabeçalhos de kernel que são correspondidas com o pacote de kernel upstream# se 'false' qualquer uma dessas correspondências for marcada como ignorematch-upstream-kernel-headers: false# sistema operacional e/ou arquitetura a ser usada quando referenciando imagens de contêiner (por exemplo, "windows/armv6" ou "arm64")# igual a --platform; GRYPE_PLATFORM env varplatform: ""# Se estiver usando entrada SBOM, gere CPEs automaticamente quando os pacotes tiverem noneadd-cpes-if-none: false# Especifique explicitamente uma distribuição 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: # verifica atualizações do banco de dados na execução # igual a GRYPE_DB_AUTO_UPDATE env var auto-update: true # local para gravar o cache do banco de dados de vulnerabilidade; o padrão é $XDG_CACHE_HOME/grype/db # igual a GRYPE_DB_CACHE_DIR env var cache-dir: "" # URL do banco de dados de vulnerabilidade # igual a GRYPE_DB_UPDATE_URL env var update-url: "https://toolbox-data.anchore.io/grype /databases/listing.json" # garante que a compilação do banco de dados não seja mais antiga que o max-allowed-built-age # definido como false para desabilitar a verificação verify-age: true # Idade máxima permitida para o banco de dados de vulnerabilidade, # idade sendo o tempo desde que foi construído # A idade máxima padrão é 120h (ou cinco dias) max-allowed -built-age: "120h" # Tempo limite para download de GRYPE_DB_UPDATE_URL para ver se o banco de dados precisa ser baixado # Este arquivo tem aproximadamente 156 KB em 17/04/2024 então o download deve ser rápido; ajuste conforme necessário update-available-timeout: "30s" # Tempo limite para baixar o banco de dados de vulnerabilidade real # O banco de dados tem aproximadamente 156 MB em 17/04/2024, portanto, conexões mais lentas podem exceder o tempo limite padrão; ajuste conforme necessário update-download-timeout: "120s"search: # o espaço de pesquisa para procurar pacotes (opções: todas as camadas, compactadas) # igual a -s ; GRYPE_SEARCH_SCOPE env var scope: "squashed" # pesquisa em arquivos que contêm um índice de arquivo para pesquisar (zip) # nota: por enquanto isso se aplica apenas ao catalogador de pacotes java # igual a GRYPE_PACKAGE_SEARCH_INDEXED_ARCHIVES env var indexed-archives: true # search dentro de arquivos que não contêm um índice de arquivo para pesquisar (tar, tar.gz, tar.bz2, etc). de um registro através do esquema "registry:"registry: # pula a verificação TLS ao se comunicar com o registro # igual a GRYPE_REGISTRY_INSECURE_SKIP_TLS_VERIFY env var insecure-skip-tls-verify: false # use http em vez de https ao conectar ao registro # igual a GRYPE_REGISTRY_INSECURE_USE_HTTP env var insecure-use-http: false # caminho do arquivo para um certificado CA (ou diretório contendo *.crt, *.cert, *.pem) usado para gerar o certificado do cliente # GRYPE_REGISTRY_CA_CERT env var ca-cert: "" # credenciais para registros específicos auth: # a URL para o registro (por exemplo, "docker.io", "localhost:5000", etc.) # GRYPE_REGISTRY_AUTH_AUTHORITY env var
- autoridade: "" # GRYPE_REGISTRY_AUTH_USERNAME env var nome de usuário: "" # GRYPE_REGISTRY_AUTH_PASSWORD env var senha: "" # nota: token e nome de usuário/senha são mutuamente exclusivos # GRYPE_REGISTRY_AUTH_TOKEN env var token: "" # caminho do arquivo para o certificado do cliente usado para autenticação TLS para o registro # GRYPE_REGISTRY_AUTH_TLS_CERT env var tls-cert: "" # caminho do arquivo para a chave do cliente usada para autenticação TLS no registro # GRYPE_REGISTRY_AUTH_TLS_KEY env var tls-key: "" # - ... # note, mais credenciais podem ser fornecidas apenas por meio do arquivo de configuração (não env vars)log: # suprime todas as saídas (exceto a lista de vulnerabilidades) # igual a -q ; GRYPE_LOG_QUIET env var quiet: false # aumenta a verbosidade # igual a GRYPE_LOG_VERBOSITY env var verbosidade: 0 # o nível do log; nota: o registro detalhado suprime o ETUI # igual a GRYPE_LOG_LEVEL env var # Usa níveis de registro logrus: https://github.com/sirupsen/logrus#level-logging level: "error" # local para gravar o arquivo de log (o padrão não é para ter um arquivo de log) # igual ao arquivo env var GRYPE_LOG_FILE: ""match: # define os matchers abaixo para usar cpes ao tentar encontrar # correspondências de vulnerabilidade. A correspondência de estoque é o número padrão quando nenhuma correspondência primária pode ser identificada. java: using-cpes: false python: using-cpes: false javascript: using-cpes: false ruby: using-cpes: false dotnet: using-cpes: false golang: using-cpes: false # mesmo se a correspondência de CPE estiver desabilitada, abra uma exceção ao procurar por "stdlib". Always-use-cpe-for-stdlib: true # permite que pseudo versões do módulo principal, que podem ter sido apenas "adivinhadas" pelo Syft, sejam usadas na correspondência de vulnerabilidadesallow-main-module-pseudo-version-comparison: false stock : usando-cpes: verdadeiro
Planos futuros
As seguintes áreas de desenvolvimento potencial estão atualmente sendo investigadas:
Suporte para lista de permissões e mapeamento de pacotes
