A propriedade de corrigir uma vulnerabilidade em uma imagem de contêiner pode variar de organização para organização. Essas informações podem ser capturadas em locais diferentes. Algumas organizações usam rótulos de imagem do Docker como uma forma de identificar as equipes de aplicações que possuem uma determinada imagem de contêiner, enquanto outras organizações podem usar o namespace do Kubernetes ou a conta de nuvem em que uma imagem de contêiner é implantada para identificar o proprietário certo.

Vulnerability Response contêiner fornece os elementos de modelo de dados necessários para capturar e usar os rótulos de imagem do Docker, os metadados de cluster/serviço/namespace do Kubernetes ou os metadados da conta de nuvem (ID da conta de nuvem, região, provedor e assim por diante) nas "Regras de atribuição" e atribua vulnerabilidades automaticamente à equipe de aplicações certa com base nos metadados da imagem ou no ambiente de tempo de execução.

Por padrão, um item vulnerável é criado para cada combinação exclusiva de CVE e a versão da imagem do Docker (referência + marcador). No entanto, algumas imagens do Docker podem ser implantadas em mais de um namespace do Kubernetes e cada namespace pode pertencer a diferentes unidades de negócios ou equipes. Cada equipe pode seguir sua própria cadência para implantar novas versões de imagens de contêiner para corrigir vulnerabilidades. Para acomodar este cenário, Vulnerability Response contêiner permite que você defina a granularidade para itens vulneráveis: se um item vulnerável deve ser criado para cada namespace/cluster/serviço do Kubernetes, mesmo para cada combinação exclusiva de versão e vulnerabilidade da imagem do Docker.

No exemplo, você pode ver dois itens vulneráveis criados para a mesma combinação de imagem do Docker e CVE. Um para o namespace do Kubernetes "k8s-finservco-loans" e o outro para "k8s-finservco-wealthandinsurance".

O cálculo de risco para itens vulneráveis pode ser feito observando o IC (imagem do Docker) e a criticidade dos serviços associados em CMDB. No entanto, para facilitar a identificação dos serviços afetados, Vulnerability Response contêiner oferece identificação de serviço baseada em marcador.

Quando os pods ou entidades do Kubernetes são publicados com valores-chave ou rótulos correspondentes aos valores-chave definidos em qualquer "Serviço baseado em marcador" em ServiceNow, Vulnerability Response contêiner estabelece automaticamente o relacionamento entre uma imagem do Docker e o serviço de aplicações afetado e usa o criticidade desse serviço de aplicativos no cálculo de risco.

Ao contrário das vulnerabilidades de host que podem ser corrigidas aplicando um patch em um host, as vulnerabilidades de contêiner não podem ser corrigidas. Novas versões de imagens de contêiner devem ser criadas e implantadas para substituir as versões mais antigas. As novas versões têm um identificador diferente (ID de imagem) em comparação com as versões anteriores, o que dificulta o acompanhamento de quais vulnerabilidades já foram corrigidas.

ServiceNow identifica vulnerabilidades que foram relatadas nas versões anteriores das imagens do contêiner, mas resolvidas na versão mais recente da imagem e move automaticamente essas vulnerabilidades para o estado "Encerrado/Corrigido" para que as equipes de segurança sempre tenham visibilidade precisa da postura de risco mais recente.