GitLab Meetup Brasil no Google SP: IA, DevSecOps e o que deu para levar para casa
O que rolou no GitLab Meetup Brasil no Google SP: novidades do GitLab 19, o paradoxo da produtividade com IA e o case da Contabilizei em produção.
No dia 23 de julho de 2026, o GitLab Meetup Brasil voltou a São Paulo — desta vez no escritório do Google, na Juscelino Kubitschek, com organização e conteúdo da Excelium. Quatro horas, cinco sessões e um tema único: a IA já entrou no ciclo de desenvolvimento de software, e a pergunta que sobrou não é mais "vamos usar?", e sim "como usar sem transformar velocidade em incidente de segurança?".
O combinado foi anunciado no primeiro slide e cumprido até o último: conhecimento primeiro, sem pitch. Este post é o registro do que foi apresentado — incluindo os números, as fontes e as práticas que dá para aplicar na segunda-feira de manhã. Os materiais estão públicos no fim do artigo.
O encontro
| Data | 23 de julho de 2026, das 14h às 18h |
| Local | Google São Paulo — Av. Pres. Juscelino Kubitschek, 1909, Vila Nova Conceição |
| Realização | GitLab Meetup Brasil × Excelium × Google |
| Formato | Comunidade, entrada gratuita, vagas limitadas |
A agenda foi desenhada como uma escada: primeiro o que mudou na plataforma, depois por que isso é um problema de segurança, em seguida um case real de produção, e só então a demo ao vivo. Painel e Q&A fecharam o dia.
GitLab 19: uma plataforma, do plan ao monitor
A primeira sessão cobriu os destaques das releases 19.0 a 19.2. A tese: o GitLab 19 sobe a régua em dois eixos ao mesmo tempo — IA agêntica em todo o SDLC e segurança que roda por padrão — sem depender de ferramenta solta colada entre as etapas.
Os destaques apresentados:
| Recurso | Estágio | O que muda na prática |
|---|---|---|
| Duo Agent Platform (Duo CLI + Custom Flows) | 19.2 · GA | A IA agêntica sai do editor e vai para o terminal e o CI/CD |
| SBOM com dependências transitivas | 19.0 · GA · Ultimate | Enxerga a árvore inteira e prioriza pelo que é realmente alcançável |
| Auto-remediação de dependências | 19.0→19.2 · Beta | O GitLab abre o MR subindo a dependência para a versão segura |
| Aba de Reports no merge request | 19.0 · Ultimate | SAST, licenças e qualidade consolidados dentro do MR |
| Governança de IA | 19.1 | Always-on, allowlist de modelos, aprovação de ferramentas e auditoria de sessões |
| Novos modelos no Duo | 19.0 · 19.1 | Claude Opus 4.7 e GPT-5.x Codex disponíveis nos fluxos |
Duas coisas merecem destaque para quem opera GitLab em ambiente corporativo. A primeira é o Custom Flows: workflows de IA definidos em YAML e disparados por eventos nativos do GitLab — ou seja, automação agêntica versionada no repositório, sujeita a review, e não configurada num painel que ninguém audita. A segunda é a chegada de perfis de dependency scanning e dos compliance frameworks prontos (ISO 27001, SOC 2, FedRAMP), que atacam o problema chato de padronizar cobertura em milhares de projetos sem tocar no .gitlab-ci.yml de cada um.
Fechando a sessão, o one more thing: o GitLab Orbit (beta), um grafo de conhecimento 3D da organização — projetos, grupos, work items e pessoas, e as conexões entre eles. A proposta é trocar busca por exploração. É cedo para tirar conclusões operacionais, mas o sinal é claro sobre onde a plataforma quer chegar.
Vale a ressalva honesta feita no palco: boa parte da segurança avançada é Ultimate. Se o seu plano de adoção depende desses recursos, o licenciamento entra na conta desde o dia zero.
IA acelera. E a segurança?
Este foi o keynote da Excelium, e o mais desconfortável do dia — de propósito.
O paradoxo da produtividade
O ponto de partida foi um dado que todo mundo já viu: +55% mais rápido para completar tarefas de código com assistência de IA. Esse número é real, mas vem de um estudo de laboratório com uma tarefa isolada (implementar um servidor HTTP).
O contraponto veio do estudo do METR (2025), com desenvolvedores experientes trabalhando em repositórios que já conheciam: os participantes ficaram 19% mais lentos — enquanto percebiam estar 20% mais rápidos. São aproximadamente 39 pontos de gap entre a percepção e a realidade.
A leitura da McKinsey completa o quadro: simplesmente dar ferramentas de IA aos desenvolvedores "não move o ponteiro". Quem captura valor rearquiteta como constrói software — e o diferencial é processo, medição e governança, não a ferramenta.
São estudos contextuais. Indicam direção, não lei geral. Mas a direção importa: é exatamente no gap entre sentir-se rápido e entregar valor que o risco se esconde.
A conta escondida
Velocidade tem preço, e ele aparece em quatro frentes:
- Código inseguro. Pearce et al. (IEEE S&P 2022) encontraram que ~40% do código gerado pelo Copilot em cenários de segurança continha vulnerabilidades — SQLi, XSS, cripto fraca. A IA aprendeu com código real, inclusive o ruim.
- Dependência alucinada. Spracklen et al. (USENIX Security 2025) mostraram que ~1 em 5 pacotes sugeridos por LLMs simplesmente não existe. Isso abre a porta para slopsquatting: alguém registra o pacote alucinado e envenena a supply chain.
- Segredos vazados. Chaves e tokens são commitados mais rápido do que o time consegue revogar.
- Falsa confiança. Compila, passa no teste feliz, "parece pronto". O caminho infeliz ninguém olhou.
O ponto central da sessão não foi "IA é perigosa". Foi mais incômodo que isso: a IA não cria riscos novos — ela acelera os que você já tinha. Se a sua segurança já dependia de revisão manual no fim do processo, ela agora simplesmente não acompanha o ritmo.
Três alavancas
A resposta apresentada não foi uma ferramenta, e sim um jeito de trabalhar — DevSecOps de verdade, com a segurança entrando no fluxo desde o primeiro commit:
- Guardrails no pipeline. A segurança vira código e roda em todo merge request: SAST, Secret Detection, Dependency Scanning, Container Scanning e DAST no mesmo pipeline onde a IA escreveu o código. Automática, não opcional. É o shift-left de segurança aplicado ao ritmo da IA.
- Governança da IA. Se não tem regra, a regra vira "cada um faz o que quer". Política de uso aceitável, classificação de dados (o que nunca vai para um prompt), escolha explícita de modelos e onde rodam, e registro auditável de quem pediu o quê. Aprofundamos esse tema no post sobre governança de riscos de IA.
- Humano no loop certo. Revisar julgamento e arquitetura — não cada caractere. Threat modeling nas mudanças grandes, exigir que a IA explique e não só gere, e um dono humano assinando embaixo de cada merge.
A conclusão amarrou as três: na velocidade da IA, segurança manual não escala. Se a máquina escreve em segundos, o humano não revisa tudo linha a linha. A segurança precisa virar código e rodar sozinha, a cada mudança.
Case Contabilizei: de milhares de alertas para uma fila que faz sentido
Depois do café, Lucas Veríssimo, Coordenador de AppSec e Resposta a Incidente da Contabilizei, trouxe a parte que ninguém consegue improvisar: números de produção.
A Contabilizei é a maior contabilidade online do Brasil — mais de 100 mil clientes, fundada em 2013 em Curitiba, com mais de 1.200 especialistas e um time de engenharia entregando o tempo todo.
O ponto de partida era familiar para qualquer time de AppSec: os scanners achavam vulnerabilidade em tudo. Um relatório consolidado com Container Scanning, SAST e SBOM apontava 285 críticas e mais de 1.000 altas. Em um único merge request, o pipeline reportou 117 novas potenciais vulnerabilidades — 43 críticas e 42 altas. Só o SAST trouxe 45 achados, 21 deles críticos. O time gastava energia perseguindo ruído enquanto o risco real se escondia no meio.
O que mudou foi o contexto, não o volume de scanners:
- SBOM como base. Saber o que existe antes de decidir o que corrigir — cada componente, com CVE, severidade e local.
- Priorização com contexto real. CVSS, EPSS (probabilidade de exploração), CISA KEV, imagem afetada e referências no mesmo lugar. Priorizar deixa de ser achismo.
- Duo Code Review no MR. O Duo comenta e abre thread no diff — em um exemplo mostrado, sugerindo restringir a versão do Pillow (
>=10.0.0,<11.0.0) para evitar breaking change. O revisor humano fica com o julgamento. - Política que bloqueia o merge. Violou a policy? O Security Bot bloqueia o MR até a violação ser resolvida ou um aprovador elegível liberar. Guardrail automático.
O caso mais didático foi o do CVE-2024-50379 (Apache Tomcat), que entrou como severidade alta pelo Dependency Scanning. Só que a aplicação é uma REST API pura em Kotlin, sem JSPs — as condições de exploração simplesmente não existem ali. O scanner acertou a versão; o contexto acertou o que importa. Achado descartado como falso positivo, com justificativa registrada.
E isso não é exceção. A sessão trouxe três referências independentes na mesma direção:
| Fonte | Achado |
|---|---|
| Endor Labs · Dependency Management Report | 90,5% das vulnerabilidades são unreachable — não há caminho de execução até a função vulnerável |
| Datadog · State of DevSecOps 2025 | Apenas 18% das CVEs críticas seguem críticas após o contexto de runtime |
| Coana · estudos de SCA + reachability | ~70% menos falsos positivos ao adicionar análise de alcançabilidade |
O resultado na Contabilizei: cerca de 99% do volume de vulnerabilidades críticas e altas era ruído, e o contexto filtrou até sobrar o que de fato traz risco — com 70% de assertividade nas correções sugeridas para vulnerabilidades de dependências e de container.
A frase que fechou a sessão resume melhor do que qualquer slide:
"A IA não tirou a decisão do time. Ela devolveu o tempo para decidir o que importa." — Lucas Veríssimo, Coordenador de AppSec e Resposta a Incidente, Contabilizei
Spec-Driven Development ao vivo, com Pedro Carrijo (GitLab)
A última sessão técnica foi conduzida por Pedro Carrijo, Senior Solutions Architect da GitLab — e foi ao vivo, sem rede de proteção.
O problema que ele atacou tem nome: vibe coding. O agente produz código plausível que dá drift do que você queria, inventa APIs e apodrece conforme o projeto cresce. Falta uma fonte de verdade.
A virada é simples de enunciar e difícil de praticar: spec first, code second. Uma especificação versionada e aprovada vira a fonte única da verdade — entradas e saídas, critérios de aceite, contratos. O código vem depois, para satisfazer a spec, não para adivinhá-la.
O paralelo com TDD ficou explícito: TDD é Spec-Driven no nível da unidade. O teste é uma micro-spec; a spec descreve a feature ou o sistema. Mesma disciplina, escalas diferentes.
No GitLab, isso tem um endereço concreto: a spec vive na Issue. Problema, critérios de aceite, caminhos de arquivo e exemplos — versionada, comentável, compartilhada entre o time e o agente. O fluxo demonstrado foi:
- Escrever a Issue-spec — história e critérios de aceite.
- Definir os testes (TDD) — o comportamento esperado, com apoio do Duo.
- Disparar o Duo Developer na issue ("Implement work item") e acompanhar pelo painel de AI Sessions.
- Revisar o MR draft gerado — contra a spec e contra os testes.
A regra de ouro: boa spec = bom MR. O agente só sabe o que você conta ou o que está no contexto. Spec ruim, MR ruim. Vale a pena listar o que uma boa Issue-spec precisa ter: problema claro e o porquê, critérios de aceite, caminhos de arquivo e padrões já existentes no repositório, exemplos de código e os testes que o MR precisa satisfazer.
O desenho do ciclo é o que interessa para quem pensa em governança: a spec entra na frente, o agente faz o meio, o humano decide no fim. O MR do agente entra pela porta da frente do fluxo de revisão — sujeito a aprovação obrigatória, code owners, quality gates e políticas de scan. Sem atalho. É o mesmo princípio que discutimos ao analisar a GitLab Duo Agent Platform.
O desafio dos 7 dias
O painel e o Q&A fecharam o dia, e o encerramento não foi um slide de agradecimento — foi um compromisso. Leve uma prática de IA segura para o seu pipeline. Uma só.
Quatro opções, nenhuma exigindo orçamento novo:
- Ligue o Secret Detection no seu repositório. É um toggle.
- Adicione SAST ao pipeline de um projeto piloto e veja o que aparece.
- Escreva uma página de política de IA — o que pode e o que nunca vai ao prompt. Depois traduza isso em guardrails:
AGENTS.mdno repositório e os controles do Duo. - Meça uma linha de base: lead time e vulnerabilidades por release. Sem número, não há melhoria.
O último item é o mais subestimado. Foi o fio condutor do dia inteiro: da McKinsey dizendo que o diferencial é processo e medição, à Contabilizei mostrando que só dá para afirmar "99% era ruído" porque alguém mediu antes e depois.
O que fica
Três leituras que atravessaram as cinco sessões:
- A IA não substitui o engenheiro — ela redefine o trabalho dele. O gargalo saiu dos dedos e foi para o critério. As habilidades que a IA valoriza (e não substitui) são leitura crítica de código, threat modeling, arquitetura, fazer boas perguntas e contexto de negócio.
- Plataforma única importa porque o loop precisa fechar no mesmo lugar. IA sugere, scanners rodam, vulnerabilidade é explicada e corrigida, tudo auditável numa cadeia de custódia só. Ferramenta solta em cada etapa deixa buraco entre elas — e é ali que o risco mora.
- Contexto vale mais que volume de alertas. Tanto o keynote quanto o case da Contabilizei chegaram na mesma conclusão por caminhos diferentes: o problema não é detectar mais, é decidir melhor.
Materiais
Todas as apresentações estão públicas, em PDF, no repositório do evento:
- Repositório com todos os decks — GitLab Meetup SP · 23/07/2026
- Página do evento no Meetup
- Grupo GitLab Meetup Brasil — para ficar por dentro dos próximos encontros
Obrigado ao Google pelo espaço, ao Pedro Carrijo e à GitLab pela demo ao vivo, ao Lucas Veríssimo e à Contabilizei por abrirem números reais de produção, e a todo mundo que trocou uma tarde de quinta-feira por isso.
Se o desafio dos 7 dias soou como uma boa ideia mas você não sabe por onde começar no seu contexto, é exatamente esse o ponto de partida que a gente ajuda a desenhar. Como GitLab Select Partner, Professional Services Partner e Partner Champion, a Excelium implanta DevSecOps e CI/CD em ambientes que já estão em produção — e, quando o mapa do estado atual ainda não existe, um HealthCheck transforma a dívida silenciosa em um plano priorizado. Sem pitch: começa com uma conversa.