GitLab 19.1 traz gestão unificada de vulnerabilidades e governança robusta para agentes de IA

O GitLab 19.1 não é só mais uma versão com 'IA adicionada', é a primeira release em que a plataforma passa de suporte a agentes para governança *operacional* deles. Isso significa que, pela primeira vez, você pode bloquear um agente de escrever em production até que um humano aprove, registrar cada chamada de ferramenta no seu SIEM como evento de auditoria e fazer isso sem depender de hooks personalizados ou integrações frágeis. O ponto-chave técnico: o streaming de eventos de IA usa o mesmo pipeline de auditoria já usado por ações de usuários e APIs, mas agora com campos estruturados específicos (como agent_id, tool_name, action_intent) que permitem filtragem nativa em ferramentas como Datadog ou Splunk.

A integração de scanners de terceiros via SARIF 2.1.0 também muda o jogo operacional: agora qualquer scanner que exporte SARIF, desde Checkmarx até Snyk Code, alimenta diretamente o widget de segurança do merge request, as políticas de auto-resolução e os dashboards de risco do Security Dashboard. Não há mais necessidade de exportar relatórios manualmente ou construir pipelines paralelos para correlacionar achados. A remediação agentic, que já estava em GA desde o 18.11, agora opera com dois níveis de confiança: um para correções geradas (com pontuação baseada em validação estática + teste unitário simulado) e outro para falsos positivos (com explicação em linguagem natural gerada por modelo de raciocínio iterativo).

Na versão 18.11 (abril/2026), a remediação agentic de vulnerabilidades era funcional, mas limitada a scanners nativos do GitLab e exigia configuração por projeto. Com o 19.1, essa mesma lógica agora se aplica a *qualquer* scanner de terceiro compatível com SARIF, e com cobertura obrigatória em todos os projetos, não apenas nos que tiveram setup manual. Também houve uma mudança de status crítico: a Detecção de Falsos Positivos de Segredos saiu de beta e está em GA, enquanto o streaming de eventos de IA e os guardrails de aprovação de ferramentas seguem em beta, ou seja, são funcionalidades prontas para testes em produção, mas ainda não recomendadas para ambientes regulados sem validação interna.

Para equipes de DevSecOps, isso reduz três pontos de fricção crônicos: (1) a lacuna entre 'scanner instalado' e 'scanner realmente executado em todos os branches', agora resolvida com varredura de todos os commits desde a divergência da branch padrão; (2) o custo oculto de triagem de vulnerabilidades, que caiu com pontuações de confiança e explicações automáticas, não é mais preciso abrir o código-fonte pra entender por que um achado de SAST foi marcado como falso positivo; (3) o risco legal de IA não supervisionada, agora mitigado com guardrails que funcionam como 'pull requests para ações de agentes': se um agente tenta deletar um bucket S3, o pipeline pausa e exige aprovação explícita de um membro do time de infraestrutura.