Análise de vulnerabilidades
Toda imagem publicada pelo Zero é analisada em busca de vulnerabilidades conhecidas. A análise acontece por digest — o identificador exato dos bytes que estão executando — e é repetida todo dia, porque o que se sabe sobre uma imagem muda mesmo quando a imagem não muda.
Três respostas diferentes, que a plataforma nunca mistura
A pergunta "esta publicação tem vulnerabilidade?" tem três respostas, e duas delas se parecem quando mal escritas:
| Resposta | O que significa | Como aparece |
|---|---|---|
| Nada encontrado | A análise concluiu e não encontrou vulnerabilidade conhecida | "Nenhuma vulnerabilidade encontrada nesta análise" |
| Encontrou | A análise concluiu e encontrou | As contagens por severidade, com quantas têm correção |
| Não foi possível analisar | O analisador não concluiu — registro de imagens fora do ar, tempo esgotado, relatório ilegível | "A análise não concluiu", sem contagem nenhuma |
A terceira é a que importa distinguir. Contagem zero com análise que não concluiu não é imagem sem vulnerabilidade: é ausência de informação. Por isso, quando a análise falha, a plataforma não mostra zeros — ela diz que não sabe.
"Nenhuma vulnerabilidade encontrada nesta análise" é uma afirmação sobre aquela análise, naquele dia, com aquela base de vulnerabilidades. A plataforma nunca escreve "imagem segura": nenhum analisador consegue afirmar isso, e prometê-lo é o começo do ciclo em que ninguém mais olha.
Quando a análise acontece
Ao publicar. Depois que a imagem é construída e sua integridade é confirmada, e antes de a publicação ser declarada ativa. É o único momento em que o digest final já existe, é imutável, e a publicação ainda não foi ao ar.
Todo dia. A imagem não muda; o que se sabe sobre ela muda. Uma vulnerabilidade publicada hoje descreve um pacote que já estava lá na semana passada, e a análise da semana passada não podia tê-la encontrado. A revisão diária cobre o que está no ar e as versões recentes, para as quais um retorno (rollback) é possível.
Por isso a mesma imagem aparece com resultados diferentes em dias diferentes, e a tela mostra com que analisador e com que base cada resultado foi produzido. É o que responde "por que ontem não aparecia nada?".
Encontrar vulnerabilidade não impede publicar
A política atual do Zero é observar: a análise é obrigatória, o resultado é visível, e nada é barrado por causa dele.
A razão é prática. Uma plataforma que barra publicação por achado de analisador ensina a desligar o analisador — e o primeiro achado crítico sem correção publicada barraria um serviço que já estava no ar, funcionando, por causa de uma informação que ninguém pode agir sobre naquele momento.
O que a plataforma faz é mostrar, e avisar:
- na tela Segurança do projeto, por serviço, com as contagens e a lista;
- em Alertas, quando há vulnerabilidade crítica na imagem que está executando;
- em Alertas, com severidade de aviso, quando a análise não concluiu — porque o que está errado aí não é a imagem, é a informação sobre ela.
Correção disponível, indisponível, desconhecida
Cada vulnerabilidade encontrada carrega o estado da correção, e são três:
| Estado | O que fazer |
|---|---|
Corrigida em x.y.z | Atualizar o pacote resolve |
| Sem correção publicada | O mantenedor declarou que não vai corrigir, ou a versão chegou ao fim da vida |
| Correção desconhecida | O analisador não afirmou nada — pode existir correção |
O terceiro estado existe de propósito. Traduzir "não sei" para "não tem conserto" faz quem opera desistir de procurar uma correção que talvez exista.
De onde sai esse estado
Do campo que o analisador usa para declarar o que sabe, e não da presença
de um número de versão. fixed vira "corrigida"; will_not_fix, end_of_life,
fix_deferred e affected viram "sem correção publicada"; o resto vira
"desconhecida".
Quando o mesmo problema é corrigido em vários ramos
Acontece bastante em pacotes de linguagem. O analisador entrega assim:
instalada: 6.2.1
corrigida: 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, 3.1.4
São oito ramos, e o que serve a quem está em 6.2.1 é 6.2.2 — não o
primeiro da lista. O Zero mostra todos e não escolhe por você: decidir
exigiria comparar versões dentro das regras de cada ecossistema (apk, dpkg,
rpm, semver), e uma escolha errada mandaria você pular dois majors por causa de
um patch.
Quando o analisador lista vários ramos sem declarar o estado da correção, o
Zero responde unknown em vez de available: há correções publicadas, e qual
delas é a sua não está dito.
Pela linha de comando
zero security <serviço> # o resumo da análise do que está no ar
zero security <serviço> --findings # a lista de vulnerabilidades
O código de saída acompanha a resposta, e é isso que um script deve ler:
| Código | Significado |
|---|---|
0 | A análise concluiu — com ou sem achados |
3 | A análise não concluiu: não há o que afirmar sobre a imagem |
1 | O comando falhou (rede, credencial, serviço inexistente) |
Um script que trate 3 como 0 transforma um registro de imagens fora do ar
num relatório de imagem limpa. O código separado existe exatamente para impedir
isso.
Pela API
GET /services/{serviceId}/security/scan o resumo
GET /services/{serviceId}/security/findings a lista, paginada por cursor
No resumo, três campos respondem perguntas diferentes e não se substituem:
status— o que aconteceu com a análise. Sósucceededconcluiu.- as contagens — o que ela encontrou. Só têm sentido quando
statusésucceeded. decision— o que a política concluiu.scan_failedé deliberadamente diferente deallow.
scanned: false significa que ninguém analisou aquele digest — nunca que ele
está limpo.
A lista de achados vem ordenada por gravidade e paginada por cursor. Lista
vazia também é a resposta quando nenhuma análise concluiu: quem precisa
distinguir lê status no resumo.
Esta página ajudou?
Reportar um problema nesta páginaNão envie senhas, chaves, tokens ou dados de clientes.