A inteligência artificial generativa entregou aos times de desenvolvimento uma capacidade que era apenas promessa há poucos anos: produzir software em escala e velocidade inéditas. O que antes consumia uma manhã inteira de um desenvolvedor experiente — escrever um pedaço de código para gerenciar uma entidade de dados, por exemplo — hoje sai pronto em segundos com ajuda da IA. O problema é que essa abundância tem um custo. Quanto mais código se produz em espaços menores de tempo, maior a chance de nascerem mais vulnerabilidades, mais brechas, mais erros estruturais que ninguém percebe, até que alguém os explore pelo “lado obscuro da rede”.
O conceito de DevSecOps surgiu para resolver um problema parecido em outra escala. Por volta de 2010, as empresas começaram a tentar diminuir o atrito histórico entre as equipes de desenvolvimento, que precisavam entregar resultados de negócio com rapidez, e as equipes de infraestrutura, que precisavam manter o ambiente estável e íntegro. Desse movimento nasceu o DevOps. O modelo funcionou, mas expôs uma falha grave: a segurança chegava sempre depois, como remendo, quando a produção já estava no ar. O “Sec” do DevSecOps foi a resposta: incorporar a segurança em cada ponto do processo, transformando-a em parte do design, não em correção tardia.
Por mais de uma década, o DevSecOps deu conta. Mas a chegada dos LLMs muda a equação. Quando o ciclo de desenvolvimento acelera de forma tão radical, os controles automáticos de segurança precisam acelerar com ele ou se transformam em gargalo. Pior: a própria interação com a IA generativa cria novos vetores de risco. O “vibe coding” precisa dar lugar ao “Spec Driven Development”, em que a especificação detalhada do que precisa ser feito, com critérios de qualidade e aceitação, vira o verdadeiro produto da engenharia. Acrescente a isso um complicador: os LLMs têm um comportamento que precisa ser permanentemente monitorado, chamado drift. Na gíria popular, é como se a IA “desse uma brisada”, desviando-se gradualmente do foco original do trabalho, sem aviso e sem que nem ela perceba.
Na fronteira entre essa velocidade e o controle é que entra a pesquisa de ponta em cibersegurança. No CISSA, Centro de Competência Embrapii em Segurança Cibernética, operado pelo CESAR, em Recife, esse é um dos eixos de investigação aplicada. A combinação entre engenharia de software, ciência de dados, modelos de linguagem e segurança da informação tem produzido linhas de trabalho que vão muito além da aplicação direta de ferramentas comerciais — e é dela que devem sair as próximas gerações de mecanismos de defesa cibernética.
Pesquisador do CISSA e doutorando da CESAR School, o cientista Fabio Chicout atua há anos em DevSecOps, cibersegurança e automação de infraestrutura. Sua tese de doutorado investiga o uso de LLMs para a detecção de anomalias em redes, mas o coração do trabalho está em algo mais sofisticado: a explicabilidade. Não basta a máquina identificar um ataque, ela precisa produzir um relatório que um executivo sem formação técnica seja capaz de entender, descrevendo o que aconteceu, como aconteceu e qual a real criticidade do evento. Em entrevista à The Shift, Chicout explica como o DevSecOps virou aliado essencial dos LLMs, por que a explicabilidade pode ser a peça que falta para conectar equipes técnicas e gestão, e como uma cultura de desconfiança saudável precisa acompanhar quem trabalha com inteligência artificial. Confira na íntegra abaixo.
Para começar, como surge o DevSecOps e por que ele se tornou tão essencial?
“O DevSecOps nasce a partir de um problema seminal. Antes dele, o pessoal de desenvolvimento brigava o tempo todo com o pessoal de infraestrutura. Enquanto a infraestrutura precisava manter o ambiente coeso, íntegro e conservado — não conservador, mas conservado —, o desenvolvimento tinha o apelo forte do negócio, precisava entregar resultados, fazer o dinheiro fluir, e ficava muito sujeito às mudanças das regras do negócio. A cultura DevOps surgiu, por volta de 2010, justamente para diminuir esses atritos, criando processos e pensamentos de integração entre essas duas equipes.
Só que, à medida que isso foi sendo feito, ficou claro que a segurança virava um problema. No modelo anterior, os desenvolvedores produziam seu código, a infraestrutura produzia seu ambiente, eles começaram a se integrar, mas só após integrarem e lutar com a produção é que o pessoal de segurança entrava em cena. A ideia do DevSecOps foi pegar a segurança e colocar em todo o ponto do processo do DevOps. Ela permeia todas as áreas, oferecendo critérios de segurança no desenvolvimento e na infraestrutura. O caminho é entender que não adianta atender ao negócio rápido, de maneira fluida, se ao entregar você gera novos riscos.”
Com a chegada dos LLMs, a velocidade do desenvolvimento explodiu. Como isso muda a equação da segurança?
“Hoje, no problema dos LLMs, a cultura DevSecOps se torna cada vez mais necessária. Os LLMs criam velocidade e, se você não tiver os travamentos automáticos e inteligentes, aumentam também a velocidade de entrega de erros e novos problemas. A facilidade vira comodidade, vira preguiça. A gente vê um aumento de ataques severos justamente porque o pessoal está sendo preguiçoso nos processos de qualidade e de segurança. Sem contar o lado da criação de ataques, que passaram a ser produzidos com muita rapidez.
Eu tenho trabalhado muito em investigação usando LLMs para detectar anomalias em comportamentos gerais de rede. A gente pega um conjunto gigantesco de dados, processa esses dados e os injeta dentro de uma LLM, de maneira que ela possa apontar: ‘isso aqui é um problema, isso aqui é uma coisa estranha’. Ela começa a analisar o que está passando ali em tempo real. Mas, quando usada sem segurança, a LLM se torna um grande risco. Ela tem todas as estratégias internas para gerar atenção, e quanto mais atenção você dá sem os guias corretos e com informação poderosa demais, mais ela pode gerar resultado contrário ao que deveria — em vez de defesa, mais exposição.”
Você descreve a evolução do vibe coding para o Spec Driven Development. Como esse caminho ajudou a domar a IA no desenvolvimento?
“Quando os LLMs surgiram, todo mundo falava muito do tal vibe coding — chegar lá, orientar a IA com uma direção genérica, dizer ‘vai por esse caminho, faz isso aqui’. Rapidamente, quem estava levando esse trabalho a sério começou a entender que simplesmente “entrar na vibe”, dar a ordem solta para programar é muito pouco. Você tem que conduzir. É meio como se você tivesse um estagiário que conhece muita coisa, mas que não sabe o que fazer com o que sabe. Então não é simplesmente dizer ‘faça’: é conduzir como se faz.
A partir daí, a gente começou a fazer engenharia no contexto, refinando estratégias até chegar ao que ficou conhecido como Spec Driven Development. A ideia é criar uma especificação detalhada e passar essa especificação para a LLM. A spec define o que tem que ser feito, de que maneira, com quais critérios de qualidade, em quais pontos a IA precisa passar para garantir essa qualidade, o que é essa qualidade, e quais são os critérios de aceite. Quando você começa a ter essas coisas, o desenvolvimento fica muito rápido. Algumas estatísticas informais que circulam entre pessoas próximas mostram, por exemplo, que numa empresa de 50 desenvolvedores o setor de qualidade fazia, em média, dois ou três testes. Hoje, esse mesmo setor precisa fazer 20, 30 testes. O volume ficou maior, e ainda assim a qualidade está significativamente aceitável.”
Mas você fala de um fenômeno particular da LLM: o drift. Como ele acontece?
“Um exemplo simples ajuda a entender. Você pode pedir à LLM que respeite o princípio da responsabilidade única, que é um dos princípios arquiteturais clássicos: cada pedaço de código, em cada arquivo, deve responder por uma única responsabilidade. Você dá essa ordem, ela cumpre muito bem na primeira vez, porque está com foco naquilo. Mas, à medida que você vai dando novas ordens, novas coisas vão sendo construídas, novas questões vão entrando no contexto, e essa atenção ao princípio começa a ser esquecida pelo volume de outras informações que vão chegando dentro da própria rede neural.
O processo de aprendizado interno e em contexto da LLM é constante. Ela vai usando as entradas para aprender e, com isso, vai derivando (em inglês, drift) das definições originais. Quando isso acontece, ela nem te avisa, porque, para ela, aquilo não é necessariamente um problema. Não é uma coisa que você está pedindo explicitamente para resolver. É algo que ela está, no entendimento dela, até atendendo bem. E é exatamente nesse ponto que vão se acumulando, de forma sutil, novos problemas no código.”
Hoje já se fala em skills, projects, regras de contexto. Esses mecanismos resolvem o drift?
“Ajudam, mas precisam estar amarrados a uma infraestrutura mais robusta. É exatamente aí que as técnicas de DevSecOps fazem a diferença. Para fazer DevSecOps, você circula tanto no processo de desenvolvimento quanto no de infraestrutura, e uma das coisas que você acaba fazendo são os testes que garantem que tudo funcione adequadamente. No desenvolvimento, você tem análise estática, análise dinâmica, mapeamento de vulnerabilidades conhecidas. Já existem ferramentas que sabem cuidar disso muito bem.
O que você faz, na prática, é estabelecer um quality gate em cima de ferramentas que determinam, de maneira objetiva, quais são os critérios. Quem vai relembrar a LLM de que o foco precisa ser, por exemplo, o princípio da responsabilidade única? É a ferramenta lá na frente que vai analisar o código e dizer: ‘olha, identifiquei que o código está furando aqui, aqui e aqui’. A LLM observa isso, volta, percebe onde falhou e retoma. Você gerencia essa atenção, esse contexto, desenhando o caminho. A gente não perde as ferramentas que já existiam, mas elas se ressignificam para fazer com que esse volume todo de código gerado tenha validade.
É desse jeito que chegamos ao conceito mais novo sobre o desenvolvimento apoiado por LLM, que é o ‘Harness Engineering’. A ideia é simples: agentes = harness + model. No nosso caso, o harness é tudo externo à LLM (as práticas de qualidade de código, a cultura DevSecOps) que traz referência e critérios claros, revisitáveis para cada ação que a LLM precisa construir.”
Sua tese de doutorado está focada em explicabilidade. O que é isso e por que é importante?
“Por mais que eu esteja utilizando LLM para fazer a detecção de anomalias, tudo na minha tese aponta para um tema chamado explicabilidade. A pergunta é: tudo bem, detectei a anomalia usando a LLM, mas como eu consigo produzir um relatório humanamente legível para um CEO, que não tem essa noção toda que um especialista em LLM ou machine learning teria, mas tem a noção do negócio e precisa entender essa vulnerabilidade, o que ela fez e como aconteceu. Puxando um pouco do storytelling, tentando entender como foi que a coisa se construiu a partir de uma história.
A explicabilidade é fundamental porque a gente começa a trabalhar com empresas e percebe que muitas delas só cuidam da segurança quando a bomba estoura. E quando a bomba estoura, ainda não é compreendido o que está acontecendo, a situação como ela é. Um relatório automatizado que venha para clarificar isso ajuda as pessoas a se comunicarem melhor — as equipes técnicas e a gestão passam a trabalhar com mais sinergia. Já se sabe a criticidade, qual a questão, se foi um ataque, qual a estratégia de defesa, como reagimos. Hoje, sem isso, você simplesmente tem ‘ah, teve um ataque’. Tivemos um ataque, foi um DDoS, e fica por isso mesmo.”
Você tem um relato pessoal que ilustra exatamente essa lacuna — um ataque DDoS ao serviço de DNS. Pode contar?
“Aconteceu há mais de dez anos, num lugar onde eu trabalhava. A gente teve um ataque DDoS direcionado ao serviço de DNS. A gente tinha dois servidores DNS na infraestrutura e começou a sentir picos de uso de CPU, queda, religamento, novos picos. Como o DNS tem cache nos pontos que o utilizam, o efeito ia aparecendo aos poucos. Passou um dia, dois, e a equipe técnica não percebia que estava sob ataque: reiniciava o serviço, achava que era problema de atualização, refazia o sistema.
Após quatro dias tentando fazer troubleshooting local, a gente resolveu olhar a rede. Quando olhou, viu que era um ataque severo, massivo. A solução que a gente deu, naquela época, foi colocar 12 máquinas para servir como DNS. Foi literalmente uma briga de capacidade — a gente disse ao atacante: ‘você quer nos derrubar por falta de capacidade? A gente tem capacidade’. Funcionou porque a gente estava em data center on-premises, com equipamento e mobilidade para isso. Hoje, em nuvem, esse tipo de resposta é proibitivo por causa do custo. Não funciona.
Mas o que ficou mais incômodo foi o desfecho. Terminou o incidente, o atacante cansou, a gente reduziu os servidores para o normal — e não houve relatório, não houve análise. Nem a equipe entendeu o problema a tempo, nem a solução foi ótima, nem a gestão compreendeu a gravidade do que tinha acontecido. A gestão tratou aquilo como mais um problema bobo que a infraestrutura ficou batendo cabeça para resolver. É daí que vem a ideia central do meu doutorado: tentar fazer com que relatórios melhores conectem todos os elos da empresa — técnico, gestão, decisão.”
Você acredita que a sua tese tem potencial de aplicação prática rápida no mercado?
“Eu sinto que ela é útil. A aplicação prática, quem decide é o mercado, mas vejo um espaço claro. Hoje, a busca em cibersegurança tem se concentrado muito na detecção do malware, na detecção da anomalia. Eu acho que só detectar é pouco. A gente precisa dessa explicação que vem junto — e por isso acredito que a proposta tem potencial de se tornar algo agregado às soluções comuns do mercado.
No momento, a gente está experimentando em cima de datasets que simulam algumas situações específicas, para testar o conceito. O próximo passo é colocar isso em ambiente real, em tráfego real. Não estabelecemos ainda um limite sobre se isso vai funcionar melhor em ambientes claros ou em shadow IT, em ataques externos ou internos. O potencial existe para todos os cenários, porque a análise se apoia em cima dos logs, das evidências — e isso permite direcionar para qualquer um deles.”
Há um exemplo que você comentou — o erro ‘use after free‘ em C — que mostra que o problema é também cultural. Como isso conecta com tudo o que está sendo discutido?
“O erro use after free é um problema antigo na linguagem C. Quando você programa em C, trabalha com gerência de memória por meio de ponteiros — variáveis que guardam o endereço de outra variável. Quando você termina de usar uma área de memória, chama a função free, que avisa ao C que aquele espaço não está mais em uso. Mas o free não retira da memória a informação do endereço que estava apontando para aquela área, e isso é “by design”. Ele só informa que o local que guardava o endereço não está mais em uso, e isso é o comportamento esperado da função free. E aí vem o atacante que ganha uma janela de tempo, onde ele pode encontrar esse endereço, mapear outra variável apontando para ele, e usar tudo o que estava ali, sem autorização. Para se defender, após chamar o free, você precisa atribuir o endereço nulo à variável. Acontece que todo programador que aprende C na faculdade não recebe essa instrução.
Onde essa informação para tomar cuidados com esse erro (o Use-After-Free) estava guardada? Nas ferramentas de DevSecOps, que monitoram esses casos. E onde estava o caminho para o programador acessá-la? Nas ferramentas de análise estática, que já avisavam sobre esse tipo de problema bem antes dos LLMs existirem. Eu, como programador, podia olhar para um aviso desses e não saber o que fazer, mas, antes dos LLMs, era a ferramenta de análise que me avisava. A LLM precisa ser instruída a usar esse arsenal. Não dá para descartar nada disso, porque a cultura também injeta problemas — não só os resolve. A própria comunidade humana de desenvolvimento vai trazendo problemas como esse, e às vezes nem se toca.”
Para onde caminha a relação entre LLMs e cibersegurança? A era dos agentes muda alguma coisa?
“Muda bastante. A gente sai de uma fase em que usava os LLMs basicamente como geradores de texto e chats para resolver problemas pontuais e entra na era dos agentes, que são o elo que faz algo, que constrói algo. Para ações automatizadas em segurança, os agentes são o caminho mais promissor. Já existem agentes para fazer análise estática, agentes para fazer segurança, e as próprias ferramentas de DevSecOps têm evoluído para criar pontes — via MCP, por exemplo — com os LLMs, diminuindo o atrito de integração nos workflows e oferecendo melhores elementos para o Harness.
Em paralelo, dentro da minha área de pesquisa, eu trabalho muito com autoencoders, que são uma classe muito específica de modelos. Nos autoencoders, encontro uma especialização nos termos: como ferramenta linguística, se você está trabalhando com um vernáculo que não aponta bem para os significados relevantes do seu contexto, isso diminui sua capacidade de detectar e tratar bem o problema. Então, para a parte de ação, agentes melhores. Para a parte de compreensão do contexto de segurança, LLMs que tratem melhor o vocabulário específico da área. Já existe trabalho sério nessa direção, e é por aí que enxergo a evolução do campo.”
Qual é a recomendação final para quem está usando LLMs no dia a dia da engenharia de software?
“Desconfie. Um LLM nunca pode ser o seu ponto final de entrega, e ele não foi feito para isso. Eu uso as práticas de DevSecOps justamente para trabalhar nessa desconfiança permanente: tenho os guias, verifico, reconstruo, e às vezes, quando desconfio do resultado, vou eu mesmo refazer à mão para validar. Essa desconfiança é saudável. Quem trabalha com LLM tem que ter desconfiança.
É muito parecido com o pedreiro ou o marceneiro que usa uma furadeira. Se a furadeira fura errado, não é a furadeira que furou errado. A mão é a sua. O LLM é uma ferramenta poderosa, mas a responsabilidade pelo que ela produz é humana. Eu só me considero responsável por aquilo que fui capaz de olhar e dizer: ‘isso aqui é meu, eu respondo por isso’. É a essência do trabalho.”