Colocar segurança no pipeline é uma daquelas iniciativas que falham por excesso de sucesso. A equipe instala quatro ferramentas, elas encontram três mil e duzentos achados no primeiro dia, o build passa a demorar vinte minutos e a falhar por vulnerabilidade sem correção disponível. Em duas semanas, alguém desliga o bloqueio "temporariamente" e ninguém liga de volta. O resultado é pior do que não ter começado: existe agora a impressão de que há segurança no processo.

O que cada tipo de verificação faz

Antes de decidir onde colocar, vale separar o que cada categoria enxerga — elas não se substituem:

• SAST analisa o seu código-fonte procurando padrões perigosos: injeção de SQL, uso de função insegura, dado do usuário chegando sem validação onde não deveria.
• SCA analisa as suas dependências, comparando as versões que você usa com bases de vulnerabilidades conhecidas. É a categoria que gera mais volume, porque quase todo projeto tem dezenas de dependências indiretas.
• Varredura de segredo procura credencial em código e no histórico.
• Varredura de IaC analisa Terraform, manifestos de Kubernetes e configuração, procurando bucket público, porta aberta, container privilegiado.
• Varredura de imagem analisa o container construído, incluindo os pacotes do sistema operacional da imagem-base.
• DAST testa a aplicação rodando, de fora, encontrando o que só aparece em execução.

Onde cada uma entra, e quanto tempo pode custar

Duas leituras importantes dessa tabela. A verificação de segredo é a única que barra sempre, porque o custo de um vazamento é alto, a taxa de falso positivo é baixa e a correção é imediata. E o DAST fica fora do caminho crítico — é lento por natureza, e colocá-lo bloqueando entrega é a receita mais rápida para ele ser desligado.

O verdadeiro inimigo é o ruído

Um projeto de tamanho médio, com uma imagem-base comum, apresenta facilmente centenas de vulnerabilidades no primeiro exame. A maioria delas está em pacote do sistema operacional que o seu código nunca chama, sem correção publicada, sem exploração conhecida.

Se você barrar o build por qualquer achado, o pipeline nunca passa. Se você mostrar tudo sem priorizar, ninguém lê. As três disciplinas que resolvem:

1. Estabeleça uma linha de base. Registre o que existe hoje como conhecido e barre apenas o que é novo. Isso muda tudo: a partir de agora, cada mudança é responsável pelo que ela introduz, e o passivo é tratado em ritmo próprio.
2. Filtre por acionabilidade. Vulnerabilidade sem correção disponível não deve barrar entrega, porque não há o que fazer — ela deve gerar tarefa de acompanhamento e, se for grave, decisão de mitigação.
3. Considere alcançabilidade. Ferramentas melhores distinguem dependência que o seu código realmente chama daquela que só está presente. Um achado crítico em código alcançável vale mais que cinquenta em código morto.

A imagem-base decide o seu volume de achados

Esse é o ganho mais desproporcional disponível nessa área, e é uma decisão de arquitetura, não de ferramenta.

Uma imagem-base de distribuição completa traz centenas de pacotes — compilador, gerenciador de pacotes, utilitários de shell — que a sua aplicação não usa e que aparecem como achados eternamente. Trocar para uma imagem enxuta, ou para uma imagem mínima sem gerenciador de pacotes e sem shell, elimina a maior parte dos achados de uma vez, sem corrigir nada linha por linha.

O benefício é duplo: menos ruído no relatório e menos ferramenta disponível para quem eventualmente consiga executar código no container. Construção em múltiplos estágios resolve o desconforto — você compila num estágio com todas as ferramentas e copia apenas o artefato para a imagem final enxuta.

Regra de bloqueio que sobrevive ao contato com a realidade

O critério que funciona na prática, e que as equipes aceitam:

• Barra: segredo detectado; vulnerabilidade crítica ou alta, nova naquela mudança, com correção disponível; configuração de IaC que expõe recurso publicamente.
• Não barra, gera tarefa com prazo: vulnerabilidade sem correção; achado de severidade média; passivo da linha de base; resultado de DAST.
• Exceção documentada: com dono, justificativa e prazo de validade. Exceção sem prazo é revogação silenciosa da regra.

Esse último ponto merece atenção. Toda equipe vai precisar liberar uma exceção em algum momento, sob pressão de prazo. Se o processo de exceção não existir, a saída vai ser desligar a verificação — e ninguém religa. Exceção explícita, com prazo e revisão, mantém o controle vivo.

O pipeline é alvo, não só ferramenta

Um ponto que a maioria dos programas de segurança demora a considerar: o pipeline costuma ter as credenciais mais poderosas da empresa. Ele publica em produção, tem acesso ao registro de imagens e frequentemente guarda chave de nuvem com permissão ampla.

O que reduz esse risco de forma concreta:

• Nenhuma credencial de longa duração. Use identidade federada entre o CI e o provedor de nuvem, com token de vida curta.
• Permissão mínima por fluxo, com o que publica em produção separado do que roda teste em pedido de alteração.
• Código de terceiro fixado por versão exata, não por referência móvel. Ação de pipeline referenciada por branch pode mudar de conteúdo sem você saber.
• Contribuição externa sem acesso a segredo. Pedido de alteração vindo de fora não deve executar com credencial nenhuma.
• Log de auditoria de quem alterou a configuração do pipeline.

Assinatura e procedência, quando faz sentido

Assinar artefatos e gerar inventário de componentes — o SBOM — resolve uma pergunta específica: este container que está em produção foi construído pelo nosso pipeline, a partir do commit que dizemos?

Vale implantar quando você tem exigência de conformidade, quando distribui software para terceiros, ou quando o ambiente é grande o bastante para haver dúvida de procedência. Para uma equipe pequena com um pipeline só, é um passo posterior — colocar identidade federada e imagem-base enxuta primeiro entrega mais redução de risco pelo mesmo esforço.

O SBOM tem um valor prático que aparece antes: quando surge uma vulnerabilidade grave numa biblioteca muito usada, a pergunta "onde usamos isso?" precisa ter resposta em minutos, não em uma semana de garimpo.

Um plano de adoção de quatro semanas

Ordem que produz resultado sem gerar rejeição:

1. Semana 1 — segredo. Verificação antes do commit e varredura do histórico. Rotacione o que aparecer. É o item de maior retorno.
2. Semana 2 — linha de base. Rode SCA e varredura de imagem em modo apenas informativo. Registre o passivo. Não barre nada ainda.
3. Semana 3 — imagem-base. Migre para imagem enxuta com construção em múltiplos estágios. Observe o passivo cair sozinho.
4. Semana 4 — bloqueio seletivo. Ative o bloqueio só para achado novo, grave e com correção. Combine o processo de exceção antes de ligar.

Depois disso, acrescente IaC, DAST fora do caminho crítico e o monitoramento contínuo do registro.

Erros comuns

• Ligar todas as ferramentas em modo bloqueante no primeiro dia.
• Barrar entrega por vulnerabilidade sem correção disponível.
• Não estabelecer linha de base, tratando passivo antigo como impedimento novo.
• Manter imagem-base completa e combater achados um por um.
• Colocar DAST no caminho crítico da entrega.
• Nenhum processo de exceção, levando ao desligamento da verificação.
• Chave de nuvem de longa duração no pipeline.
• Ação de terceiro referenciada por branch em vez de versão fixa.
• Relatório sem dono, que ninguém lê.

Onde a Solvefy/Cloud entra

Implantamos essa camada na ordem que a equipe consegue absorver: começamos por segredo e imagem-base, que derrubam a maior parte do risco e do ruído, e só depois ligamos bloqueio — sempre com linha de base e processo de exceção acordados antes. Também tratamos o pipeline como ativo a proteger, eliminando credenciais de longa duração e ajustando permissão por fluxo. O objetivo é um controle que continue ligado em seis meses, não um relatório impressionante na primeira semana.

Quer segurança no pipeline sem travar a entrega? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.