As vulnerabilidades em contêineres não esperam o próximo deploy. Elas podem surgir a qualquer momento: na criação de uma imagem ou com os contêineres já em execução em produção. Para lidar com essa realidade, o GitLab oferece diferentes abordagens de varredura de contêineres, cada uma pensada para uma etapa do ciclo de vida do contêiner.
Neste guia, você vai conhecer os tipos de varredura de contêineres disponíveis no GitLab, como ativar cada um e as configurações mais comuns para começar.
Por que a varredura de contêineres é importante
Vulnerabilidades em imagens de contêiner geram riscos ao longo de todo o ciclo de vida da aplicação. Imagens base, pacotes do sistema operacional e dependências da aplicação podem conter vulnerabilidades que atacantes exploram ativamente. A varredura de contêineres detecta esses riscos cedo, antes que cheguem à produção, e indica caminhos de correção quando eles existem.
Explicando melhor: a varredura de contêineres é um componente essencial da Análise de Composição de Software (SCA, na sigla em inglês) e ajuda a entender e proteger as dependências externas que sustentam as aplicações em contêineres.
Os cinco tipos de GitLab Container Scanning
O GitLab oferece cinco abordagens distintas de varredura de contêineres, cada uma com um papel específico na estratégia de segurança.
1. Pipeline-based Container Scanning
- O que faz: faz a varredura de imagens de contêiner durante a execução da pipeline de CI/CD e detecta vulnerabilidades antes do deploy
- Indicado para: segurança shift-left (levar a segurança para as etapas iniciais do desenvolvimento) e bloqueio de imagens vulneráveis antes que cheguem à produção
- Disponibilidade por plano: Free, Premium e Ultimate (com recursos adicionais no Ultimate)
- Documentação
O GitLab usa o scanner de segurança Trivy para analisar imagens de contêiner em busca de vulnerabilidades conhecidas. A cada execução da pipeline, o scanner examina as imagens e gera um relatório detalhado.
Como ativar o Pipeline-based Container Scanning
Opção A: merge request pré-configurada
- Acesse Secure > Security configuration no projeto.
- Localize a linha "Container Scanning".
- Selecione Configure with a merge request.
- Isso cria automaticamente uma merge request com a configuração necessária.
Opção B: configuração manual
- Adicione o seguinte ao arquivo
.gitlab-ci.yml:
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
Configurações comuns
Varredura de uma imagem específica:
Para fazer a varredura de uma imagem específica, sobrescreva a variável CS_IMAGE no job container_scanning.
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_IMAGE: myregistry.com/myapp:latest
Filtrar por nível de severidade:
Para encontrar apenas vulnerabilidades a partir de um determinado nível de severidade, sobrescreva a variável CS_SEVERITY_THRESHOLD no job container_scanning. No exemplo abaixo, só aparecem vulnerabilidades de severidade High ou superior.
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_SEVERITY_THRESHOLD: "HIGH"
Vulnerabilidades na merge request
Ver as vulnerabilidades do Container Scanning diretamente nas merge requests torna a revisão de segurança fluida e eficiente. Depois que o Container Scanning é configurado na pipeline de CI/CD, o GitLab exibe automaticamente as vulnerabilidades detectadas no Security widget da merge request.
Vulnerabilidades do Container Scanning exibidas na MR
- Abra qualquer merge request e role até a seção "Security Scanning" para ver um resumo das vulnerabilidades novas e já existentes encontradas nas imagens de contêiner.
- Clique em uma vulnerabilidade para ver os detalhes do achado, incluindo o nível de severidade, os pacotes afetados e as orientações de correção disponíveis.
Detalhes de uma vulnerabilidade do Container Scanning na MR
Com essa visibilidade, desenvolvedores e equipes de segurança conseguem detectar e corrigir vulnerabilidades em contêineres antes que elas cheguem à produção. A segurança passa a fazer parte da revisão de código, em vez de funcionar como uma etapa separada.
Vulnerabilidades no Vulnerability Report
Além da revisão nas merge requests, o GitLab oferece um Vulnerability Report centralizado, que dá às equipes de segurança uma visão abrangente de todos os achados do Container Scanning no projeto.
Vulnerability Report filtrado por Container Scanning
- Para acessar o relatório, selecione Secure > Vulnerability report na barra lateral do projeto.
- Ali fica reunida uma visão consolidada de todas as vulnerabilidades de contêiner detectadas nas branches, com opções avançadas de filtro por severidade, status, tipo de scanner ou imagem de contêiner específica.
- Clique em uma vulnerabilidade para abrir a página dela.
Detalhes de uma vulnerabilidade do Container Scanning
A página Vulnerability Details mostra exatamente quais imagens e camadas de contêiner foram afetadas, o que facilita rastrear a vulnerabilidade até a origem. Nela, é possível atribuir vulnerabilidades a pessoas da equipe, alterar o status (detected, confirmed, resolved, dismissed), adicionar comentários para colaborar e vincular issues relacionadas para acompanhar o trabalho de correção.
Com esse fluxo de trabalho, a gestão de vulnerabilidades deixa de depender de planilhas e passa a fazer parte do processo de desenvolvimento: os achados de segurança em contêineres são acompanhados, priorizados e resolvidos de forma sistemática.
Dependency List
A Dependency List do GitLab oferece uma lista completa de materiais de software (SBOM), que cataloga cada componente das imagens de contêiner e dá total transparência sobre a cadeia de suprimentos de software.
- Acesse Secure > Dependency list para ver o inventário de todos os pacotes, bibliotecas e dependências que o Container Scanning detectou no projeto.
- Essa visão é fundamental para entender o que de fato está em execução dentro dos contêineres, dos pacotes do sistema operacional base às dependências da aplicação.
Dependency List do GitLab (SBOM)
Você pode filtrar a lista por gerenciador de pacotes, tipo de licença ou status de vulnerabilidade para identificar rapidamente quais componentes representam riscos de segurança ou problemas de conformidade. Cada dependência mostra as vulnerabilidades associadas, o que permite entender os problemas de segurança no contexto dos componentes reais do software, em vez de tratá-los como achados isolados.
2. Container Scanning for Registry
- O que faz: faz automaticamente a varredura das imagens com a tag
latestenviadas por push ao GitLab Container Registry - Indicado para: monitoramento contínuo das imagens do registry, sem precisar disparar pipelines manualmente
- Disponibilidade por plano: somente Ultimate
- Documentação
Quando você faz push de uma imagem de contêiner com a tag latest, o bot de políticas de segurança do GitLab dispara automaticamente uma varredura na branch padrão. Diferentemente da varredura baseada em pipeline, essa abordagem trabalha em conjunto com o Continuous Vulnerability Scanning para monitorar novos boletins de segurança publicados.
Como ativar o Container Scanning for Registry
- Acesse Secure > Security configuration.
- Role até a seção Container Scanning For Registry.
- Ative o recurso.
Opção para ativar o Container Scanning for Registry
Pré-requisitos
- Papel de Maintainer ou superior no projeto
- O projeto não pode estar vazio (é preciso ao menos um commit na branch padrão)
- As notificações do Container Registry precisam estar configuradas
- O Package Metadata Database precisa estar configurado (ativado por padrão no GitLab.com)
As vulnerabilidades aparecem na aba Container Registry vulnerabilities do Vulnerability Report.
3. Multi-Container Scanning
- O que faz: faz a varredura de várias imagens de contêiner em paralelo, em uma única pipeline
- Indicado para: arquiteturas de microsserviços e projetos com várias imagens de contêiner
- Disponibilidade por plano: Free, Premium e Ultimate (atualmente em Beta)
- Documentação
O Multi-Container Scanning usa pipelines filhas dinâmicas para executar as varreduras simultaneamente, o que reduz de forma significativa o tempo total de execução da pipeline quando é preciso fazer a varredura de várias imagens.
Como ativar o Multi-Container Scanning
- Crie um arquivo
.gitlab-multi-image.ymlna raiz do repositório:
scanTargets:
- name: alpine
tag: "3.19"
- name: python
tag: "3.9-slim"
- name: nginx
tag: "1.25"
- Inclua o template no
.gitlab-ci.yml:
include:
- template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml
Configuração avançada
Varredura de imagens de registries privados:
auths:
registry.gitlab.com:
username: ${CI_REGISTRY_USER}
password: ${CI_REGISTRY_PASSWORD}
scanTargets:
- name: registry.gitlab.com/private/image
tag: latest
Incluir informações de licença:
includeLicenses: true
scanTargets:
- name: postgres
tag: "15-alpine"
4. Continuous Vulnerability Scanning
- O que faz: cria vulnerabilidades automaticamente quando novos boletins de segurança são publicados, sem precisar de pipeline
- Indicado para: monitoramento proativo de segurança entre um deploy e outro
- Disponibilidade por plano: somente Ultimate
- Documentação
A varredura tradicional só detecta vulnerabilidades no momento em que é executada. E é justamente aí que surge a dúvida: o que acontece quando um novo CVE é publicado amanhã para um pacote que passou pela varredura ontem? O Continuous Vulnerability Scanning resolve essa questão monitorando o GitLab Advisory Database e criando automaticamente registros de vulnerabilidade quando novos boletins afetam os componentes do projeto.
Como funciona
- O job de Container Scanning ou de Dependency Scanning gera um SBOM no formato CycloneDX.
- O GitLab registra os componentes do projeto a partir desse SBOM.
- Quando novos boletins de segurança são publicados, o GitLab confere se algum desses componentes foi afetado.
- As vulnerabilidades são criadas automaticamente no relatório de vulnerabilidades.
Considerações importantes
- As varreduras rodam em jobs em segundo plano (Sidekiq), não em pipelines de CI.
- Somente boletins publicados nos últimos 14 dias são considerados na detecção de novos componentes.
- O nome de scanner exibido nessas vulnerabilidades é "GitLab SBoM Vulnerability Scanner".
- Para marcar vulnerabilidades como resolvidas, ainda é preciso executar uma varredura baseada em pipeline.
5. Operational Container Scanning
- O que faz: faz, em uma cadência programada, a varredura dos contêineres em execução no cluster Kubernetes
- Indicado para: monitoramento de segurança após o deploy e detecção de vulnerabilidades em tempo de execução
- Disponibilidade por plano: somente Ultimate
- Documentação
O Operational Container Scanning preenche a lacuna entre a segurança no momento do build e a segurança em tempo de execução. Com o GitLab agent for Kubernetes, ele faz a varredura dos contêineres que de fato estão em execução nos clusters e detecta vulnerabilidades que surgem depois do deploy.
Como ativar o Operational Container Scanning
Se você usa o agente do GitLab para Kubernetes, basta adicionar o seguinte ao arquivo de configuração do agente:
container_scanning:
cadence: '0 0 * * *' # Daily at midnight
vulnerability_report:
namespaces:
include:
- production
- staging
Também é possível criar uma política de execução de varredura que faz o agente do GitLab para Kubernetes executar a varredura em uma programação definida.
Condições da política de execução de varredura para o Operational Container Scanning
Resultados
- Acesse Operate > Kubernetes clusters.
- Selecione a aba Agent e escolha o agente.
- Em seguida, selecione a aba Security para ver as vulnerabilidades do cluster.
- Os resultados também aparecem na aba Operational Vulnerabilities do Vulnerability Report.
Como reforçar a postura de segurança com as GitLab Security Policies
As GitLab Security Policies permitem aplicar padrões de segurança consistentes em todos os fluxos de trabalho com contêineres, por meio de controles automatizados baseados em políticas. Essas políticas levam a segurança para as etapas iniciais (shift-left) ao incorporar requisitos diretamente na pipeline de desenvolvimento, para que as vulnerabilidades sejam detectadas e corrigidas antes que o código chegue à produção.
Políticas de execução de varredura e políticas de execução de pipelines
As políticas de execução de varredura automatizam quando e como o Container Scanning é executado nos projetos. É possível definir políticas que disparam a varredura de contêineres em cada merge request, programar varreduras recorrentes da branch principal e muito mais. Assim, a cobertura fica ampla sem depender de cada desenvolvedor configurar a varredura manualmente na pipeline de CI/CD de cada projeto.
Também dá para especificar as versões do scanner e configurar os parâmetros de varredura de forma centralizada, mantendo a consistência em toda a organização e acompanhando as novas ameaças à segurança de contêineres.
Configuração de scan execution policy
As políticas de execução de pipelines oferecem controles flexíveis para inserir (ou sobrescrever) jobs personalizados em uma pipeline, de acordo com as necessidades de compliance.
Com elas, você pode inserir automaticamente jobs de varredura de contêineres na pipeline, fazer o build falhar quando as vulnerabilidades de contêiner ultrapassam o nível de risco aceitável, disparar validações de segurança adicionais em branches ou tags específicas e aplicar requisitos de compliance às imagens de contêiner destinadas a ambientes de produção. As políticas de execução de pipelines funcionam como proteções automáticas: garantem que os padrões de segurança sejam aplicados de forma consistente em todos os deploys de contêineres, sem intervenção manual.
Ações da política de execução de pipelines
Políticas para aprovação de Merge Requests
As políticas para aprovação de Merge Requests funcionam como barreiras de segurança: exigem que aprovadores designados revisem e aprovem as merge requests que contenham vulnerabilidades em contêineres.
É possível configurar políticas que bloqueiam o merge quando vulnerabilidades de severidade crítica ou alta são detectadas, ou que exigem a aprovação da equipe de segurança para qualquer merge request que introduza novos achados em contêineres. Dessa forma, imagens de contêiner vulneráveis não avançam na pipeline, e o desenvolvimento segue no mesmo ritmo nas mudanças de baixo risco.
Política para aprovação de Merge Requests bloqueando a MR
Como escolher a abordagem certa
| Tipo de varredura | Quando usar | Principal benefício |
|---|---|---|
| Pipeline-based | A cada build | Segurança shift-left; bloqueia builds vulneráveis |
| Registry scanning | Monitoramento contínuo | Detecta novos CVEs em imagens armazenadas |
| Multi-container | Microsserviços | Varredura em paralelo, pipelines mais rápidas |
| Continuous vulnerability | Entre deploys | Monitoramento proativo de boletins de segurança |
| Operational | Monitoramento em produção | Detecção de vulnerabilidades em tempo de execução |
Para uma segurança abrangente, vale combinar várias abordagens: a varredura de contêineres baseada em pipelines para detectar problemas durante o desenvolvimento, o Container Scanning for Registry para o monitoramento contínuo e o Operational Container Scanning para ter visibilidade em produção.
Por onde começar
O caminho mais rápido para a segurança de contêineres é ativar a varredura baseada em pipeline:
- Acesse Secure > Security configuration no projeto.
- Clique em Configure with a merge request na linha do Container Scanning.
- Faça o merge da MR gerada.
- A próxima pipeline já vai incluir a varredura de vulnerabilidades.
A partir daí, você pode adicionar outros tipos de varredura conforme os requisitos de segurança e o plano do GitLab.
Segurança de contêineres não é uma tarefa pontual, e sim um processo contínuo. Com o conjunto completo de recursos de varredura de contêineres do GitLab, é possível detectar vulnerabilidades em todas as etapas do ciclo de vida do contêiner, do build à execução.
Para saber mais sobre como o GitLab pode ajudar a fortalecer a postura de segurança da sua empresa, acesse a página de soluções de segurança e governança do GitLab.
