Segurança no pipeline

Segurança que só aparece na véspera do lançamento vira negociação: o prazo já foi prometido e alguém aceita o risco por escrito. Colocar as verificações no pipeline muda o momento da conversa — o problema aparece no pull request, quando corrigir custa minutos.

O risco oposto é igualmente real: um pipeline que bloqueia tudo, com centenas de achados sem contexto, é desligado em três semanas. O objetivo aqui é poucos achados, confiáveis, no lugar certo.

Onde cada análise entra

Etapa	Verificação	Por quê aqui
Pré-commit / PR	Segredo, lint, SAST rápido	Feedback em segundos, antes da revisão
Build	SCA (dependências), SBOM	Você acabou de resolver as versões
Imagem	Scan de imagem, assinatura	O artefato final é o que vai para produção
Deploy	Política de admissão	Última barreira, no cluster
Pós-deploy	DAST, scan contínuo	Vulnerabilidade nova sai depois do build

Note que a mesma dependência é verificada mais de uma vez, em momentos diferentes. Isso é proposital: CVE publicada hoje afeta a imagem que você construiu no mês passado.

SAST: análise estática

Lê o código à procura de padrão inseguro — SQL concatenada, deserialização insegura, criptografia fraca, caminho de arquivo vindo do usuário.

.github/workflows/seguranca.yml

- name: SAST
  uses: github/codeql-action/analyze@v3
  # ou, para regras próprias e execução rápida:
  # run: semgrep ci --config auto --config ./regras-internas/

Rode o SAST só no diff do pull request para dar resposta rápida, e a varredura completa uma vez por semana. Analisar o repositório inteiro a cada commit é o caminho mais curto para um pipeline de 40 minutos que ninguém espera.

SCA: dependências e vulnerabilidades conhecidas

A maior parte do código que você entrega não foi escrita pelo seu time. SCA compara suas dependências com bases de vulnerabilidade.

# dependências da aplicação
trivy fs --scanners vuln,license --severity HIGH,CRITICAL .
# imagem final, com o que o sistema base carrega
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.exemplo.com/loja:1.8.3

--ignore-unfixed é a diferença entre uma lista acionável e uma parede de ruído: sem correção publicada, o achado não muda o que o time faz hoje — mas continue registrando para reavaliar. Priorize por exploitabilidade e alcance, não só por CVSS: uma vulnerabilidade crítica em biblioteca que seu código nunca chama é menos urgente que uma média no parser exposto à internet.

DAST e testes dinâmicos

O DAST exercita a aplicação rodando: cabeçalhos ausentes, autenticação frágil, injeção observável pela resposta. Rode em homologação, com dados sintéticos, fora do caminho do merge — é lento e barulhento demais para bloquear pull request.

docker run --rm -t ghcr.io/zaproxy/zaproxy zap-baseline.py \
  -t https://homologacao.exemplo.com -m 5 -I     # -I: não falha no build

Antes de investir em DAST, garanta o básico que ele vai apontar: TLS correto, cabeçalhos de segurança, e nenhuma rota administrativa exposta.

Falso positivo é o que mata a adoção

A regra prática: um achado que o time descarta duas vezes precisa virar exceção registrada, não ser ignorado em silêncio.

# .trivyignore.yaml — exceção com dono, motivo e prazo
vulnerabilities:
  - id: CVE-2026-1234
    paths: ["usr/lib/libexemplo.so"]
    statement: "Não alcançável: a função vulnerável não é chamada. Dono @ana."
    expired_at: 2026-11-30

Exceção sem prazo vira permanente. Com prazo, ela volta para a fila e alguém decide de novo — que é exatamente o comportamento desejado.

Bloquear ou avisar

Adote em duas fases, sempre. Primeiro avisa: coleta achados, mede o volume e limpa o acervo existente. Depois bloqueia, e só o que satisfaz três condições:

1. O achado é confiável (pouquíssimo falso positivo na prática medida).
2. Existe caminho de correção claro e documentado.
3. Existe caminho de exceção rápido, com dono e prazo.

Comece bloqueando o que é objetivo e indiscutível: segredo commitado, imagem sem assinatura, dependência com CVE crítica e correção disponível. O resto entra como comentário no pull request.

E lembre da ordem de valor: eliminar a classe do problema vale mais que detectá-lo. Imagem base mínima reduz mais CVEs que qualquer scanner reporta, e um template de projeto seguro evita mais achados que qualquer gate.

Próximo passo: garanta que o artefato entregue é mesmo o que você construiu em Cadeia de suprimentos de software.