Vibe coding e a nova dívida de segurança: como governar código gerado por IA no seu SDLC

O ganho de produtividade que ninguém vê chegar ao ambiente de produção

Depois de anos acompanhando times de desenvolvimento em bancos, seguradoras e empresas de tecnologia no Brasil, aprendi a desconfiar de qualquer promessa de produtividade que não venha acompanhada de uma conversa honesta sobre risco. E o chamado vibe coding, essa prática de programar conversando com um assistente de Inteligência Artificial (IA) e aceitando o que ele sugere quase sem contestação, é exatamente esse tipo de promessa. O código sai mais rápido, os prazos parecem mais respiráveis, e o desenvolvedor sente que finalmente tem um par para os momentos de bloqueio. Tudo isso é verdade, e é justamente por ser verdade que o problema fica invisível.

O que vejo com frequência é uma euforia mal calibrada. Times que antes discutiam arquitetura, revisavam pull requests com rigor e questionavam cada dependência nova agora aceitam blocos inteiros de código gerado porque "funcionou no primeiro teste". Funcionar não é o mesmo que ser seguro, e essa distinção sempre foi difícil de comunicar para quem cobra entrega. Com a IA no meio do processo, ela ficou ainda mais difícil, porque o volume de código produzido cresceu de forma expressiva enquanto a capacidade de revisão humana permaneceu a mesma.

O ponto central deste artigo é simples de enunciar e desconfortável de aceitar: a produtividade da IA não elimina a dívida de segurança, ela a transfere para produção. O que antes seria uma discussão barata em code review vira um incidente caro em ambiente crítico. E, diferente da dívida técnica clássica, essa nova dívida tem características que os controles tradicionais não foram desenhados para capturar.

Por que a velocidade da IA empurra a dívida para o pior lugar possível

Toda decisão de engenharia carrega um custo, e a pergunta que um bom gestor faz não é "quanto custa", mas "quando e onde esse custo vai aparecer". O código gerado por IA tem uma propriedade perversa nesse sentido: ele adia o custo para o momento em que ele é mais difícil e mais caro de resolver. Um erro de lógica de autorização identificado na revisão custa alguns minutos de conversa. O mesmo erro descoberto após um vazamento de dados custa reputação, multa sob a Lei Geral de Proteção de Dados (LGPD) e madrugadas de resposta a incidente.

A raiz disso está na natureza estatística do modelo. Um assistente de IA não entende o seu contexto de negócio, não conhece o seu modelo de ameaças e não sabe que aquele endpoint específico manipula dados sensíveis de milhões de clientes. Ele produz o texto mais provável dado o que foi pedido, e o mais provável costuma ser o mais comum, não o mais seguro. Padrões inseguros que aparecem repetidos em fóruns e repositórios públicos foram absorvidos pelo modelo e voltam com naturalidade impressionante, revestidos de uma confiança que o desenvolvedor humano dificilmente teria ao copiar algo da internet.

Há também um efeito psicológico que subestimamos. Quando um colega humano sugere uma solução, existe um contrato social implícito de dúvida saudável, você questiona, ele defende, ambos aprendem. Quando a máquina sugere, a fluência do texto e a rapidez da resposta criam uma sensação de autoridade que desarma o senso crítico. O desenvolvedor deixa de ser autor e vira revisor de algo que não escreveu, mas revisa como se tivesse escrito, com o mesmo viés de propriedade e a mesma cegueira para os próprios erros.

Após anos trabalhando com organizações brasileiras, posso afirmar que o gargalo nunca foi gerar código. Sempre foi entender, validar e responsabilizar-se pelo código. A IA otimizou exatamente a etapa que já era barata e deixou intocada, ou até sobrecarregou, a etapa que sempre foi cara.

Dependências alucinadas: o risco que não estava no seu radar

Existe uma categoria de falha específica do código gerado por IA que merece atenção especial dos líderes técnicos, porque ela não tem paralelo claro no mundo pré-IA. Os modelos alucinam dependências. Ao sugerir a instalação de uma biblioteca para resolver um problema, o assistente pode indicar um pacote que simplesmente não existe, com um nome plausível, uma sintaxe de instalação correta e uma descrição convincente de funcionalidades que nunca foram implementadas por ninguém.

Na melhor das hipóteses, o desenvolvedor tenta instalar, recebe um erro de pacote não encontrado e segue em frente irritado com a perda de tempo. O problema é que essa não é a única hipótese. Quando um modelo alucina consistentemente um mesmo nome de pacote inexistente, e os modelos tendem a repetir alucinações porque elas derivam de padrões estatísticos estáveis, esse nome vira um alvo previsível. Atacantes observam quais pacotes fantasmas a IA costuma recomendar e registram esses nomes em repositórios públicos com código malicioso dentro.

Essa técnica ganhou o nome de slopsquatting, uma evolução do velho typosquatting. No typosquatting, o atacante aposta que você vai errar a digitação de um pacote legítimo. No slopsquatting, ele aposta que a sua IA vai recomendar um pacote que não existe, e ele apenas se antecipa criando esse pacote antes de você. O desenvolvedor confia na sugestão, roda o comando de instalação, e acabou de trazer código controlado por um adversário para dentro do seu pipeline, muitas vezes com permissões de execução na etapa de build.

O que torna esse vetor especialmente traiçoeiro é que ele contorna a intuição de segurança que construímos ao longo de anos. Ensinamos os times a desconfiar de links suspeitos e de fontes desconhecidas, mas não os ensinamos a desconfiar da sugestão do próprio assistente que eles usam o dia inteiro. A cadeia de suprimentos de software brasileira, que já vinha amadurecendo lentamente na gestão de terceiros, agora precisa lidar com um vetor que nasce dentro da ferramenta de produtividade.

Por que seus controles atuais estão sendo contornados

A maioria das organizações que atendo tem controles razoáveis no papel: análise estática de código, revisão de pull request, gestão de vulnerabilidades em dependências, política de aprovação de bibliotecas. O problema é que esses controles foram calibrados para um volume e um ritmo de produção humanos, e o artefato de IA quebra ambos os pressupostos sem que ninguém tenha decidido conscientemente afrouxar nada.

Comece pela revisão de pull request. Ela funciona quando o revisor consegue reconstruir mentalmente o raciocínio de quem escreveu o código. Quando o autor humano nem ele mesmo sabe explicar por que o código está daquele jeito, porque a IA escreveu e ele apenas aprovou, a revisão vira uma inspeção superficial de sintaxe. O revisor vê que compila, vê que os testes passam, e aprova. A profundidade que fazia da revisão um controle real evaporou, mesmo com o processo formalmente intacto.

As ferramentas de análise estática e de varredura de dependências também têm pontos cegos relevantes. Elas comparam o seu código contra bases de vulnerabilidades conhecidas, o que é ótimo para falhas catalogadas e inútil para um pacote malicioso recém-registrado via slopsquatting, que ainda não está em nenhuma base porque foi criado ontem justamente para atacar você. A janela entre a criação do pacote hostil e sua catalogação como ameaça é exatamente o período em que a IA o recomenda e o desenvolvedor o instala.

Há ainda uma questão de proveniência que os controles tradicionais raramente endereçam. Quando revisamos código, assumimos implicitamente que sabemos de onde ele veio, quem o escreveu e sob qual raciocínio. Código gerado por IA rompe essa cadeia de custódia. Você tem um artefato sem autoria clara, sem histórico de intenção e sem um humano que possa responder com segurança pela cada linha. Governança sem proveniência é ilusão de controle, e é nesse ponto que a maioria dos SDLC brasileiros está descoberta hoje.

O assistente de IA é um colega, mas não um colega confiável

A melhor moldura mental que encontrei para governar isso, e que uso ao conversar com diretores, é tratar o assistente de IA como um novo integrante da equipe. Ele é rápido, produtivo, conhece uma quantidade absurda de padrões e nunca reclama de prazo. Mas ele também mente com convicção, não entende o contexto do seu negócio, não tem responsabilidade legal por nada e ocasionalmente sugere trazer para dentro de casa um pacote que um atacante plantou. É, em resumo, um colega talentoso e não confiável.

A palavra não confiável aqui não é um julgamento moral, é uma classificação de segurança. No design de sistemas seguros, tratamos entradas não confiáveis com validação, sanitização e privilégio mínimo. Não damos a uma fonte não confiável acesso direto a produção, não aceitamos o que ela diz sem verificação e não a colocamos numa posição onde um erro dela vire um incidente nosso. O código de IA merece exatamente essa mesma postura, sem exceção e sem constrangimento com o time.

Isso muda a conversa dentro da organização de uma forma saudável. Em vez de proibir a ferramenta, o que é inútil porque os desenvolvedores vão usá-la de qualquer forma, você reconhece o valor dela e desenha o processo assumindo que ela vai errar. A pergunta deixa de ser "podemos confiar no código da IA" e passa a ser "que controles garantem que um erro da IA nunca chegue sozinho até produção". Essa segunda pergunta tem respostas concretas e implementáveis.

Proveniência: saiba o que foi gerado e por quem foi aceito

O primeiro pilar de um SDLC que governa código de IA é a proveniência. Você precisa saber, de forma rastreável, quais trechos foram gerados por assistente, qual assistente, e qual humano assumiu a responsabilidade por incorporá-los. Isso não é burocracia, é a reconstrução da cadeia de custódia que a IA quebrou. Sem isso, você não consegue nem mesmo dimensionar sua exposição depois que uma nova classe de falha for descoberta.

Na prática, isso significa registrar a origem do artefato de forma leve mas consistente. Alguns times marcam commits ou pull requests que contêm código majoritariamente gerado, outros mantêm metadados no próprio sistema de controle de versão. O detalhe da implementação importa menos do que o princípio: quando um pacote se revelar malicioso ou um padrão se mostrar inseguro, você precisa conseguir responder rapidamente onde mais aquilo foi usado, quem aprovou e desde quando está rodando.

A proveniência também restabelece a responsabilização, que é o coração de qualquer governança. Um artefato de IA não pode ser aprovado por outro artefato de IA nem entrar em produção sem que um humano identificável tenha colocado o nome dele naquela decisão. Não se trata de punir pessoas, e sim de garantir que exista sempre alguém que entend

Perguntas frequentes

O que é vibe coding e como afeta a segurança do desenvolvimento?
Vibe coding é a prática de usar assistentes de IA para gerar código rapidamente sem análise profunda do que está sendo produzido. Essa abordagem compromete a segurança porque o código gerado pode conter vulnerabilidades, dependências inseguras ou padrões inadequados que não são detectados no momento da criação. A velocidade de desenvolvimento não compensa os riscos introduzidos no ciclo de vida do software.

Por que gestores devem se preocupar com código gerado por IA?
Código gerado por IA pode conter falhas de segurança que passam despercebidas em testes superficiais, aumentando a exposição a ataques e conformidade regulatória. A responsabilidade legal sobre vulnerabilidades permanece com a empresa, independente de quem ou o que gerou o código. Sem governança adequada, acumula-se uma dívida de segurança que se torna custosa de remediar posteriormente.

Qual é o impacto financeiro da dívida de segurança gerada por IA?
Estudos mostram que corrigir vulnerabilidades em produção custa entre 5 a 20 vezes mais do que preveni-las na fase de desenvolvimento. Incidentes de segurança envolvendo código com defeitos causam danos reputacionais, multas regulatórias e custos operacionais significativos. Investir em governança preventiva retorna rapidamente em economia de remediação.

Como implementar governança de código gerado por IA no SDLC?
Estabeleça políticas que exigem revisão de segurança obrigatória para todo código gerado por IA antes da produção, integre ferramentas de análise estática (SAST) e análise dinâmica (DAST) no pipeline de CI/CD, e defina um processo de aprovação que envolva arquitetos de segurança. Treine times de desenvolvimento em reconhecer padrões inseguros e limitar o uso de IA em componentes críticos.

Quais ferramentas tecnológicas ajudam a governar código gerado por IA?
Ferramentas de análise estática (SAST), software composition analysis (SCA) para rastrear dependências, e testes de segurança contínuos (DAST) identificam vulnerabilidades automaticamente. Plataformas de code review com IA que validam a qualidade do código gerado complementam a detecção manual. Orquestração dessas ferramentas no CI/CD garante que nenhum código vulnerável chegue à produção.

Quando devo auditar meu SDLC para riscos de vibe coding?
Recomenda-se realizar uma auditoria imediatamente se sua equipe já usa assistentes de IA para geração de código sem processos de validação formal. Estabeleça uma cadência de auditorias trimestrais para revisar a conformidade com as políticas de segurança e ajustar controles conforme novos riscos emergem. O diagnóstico inicial identifica gaps críticos que precisam ser endereçados em curto prazo.

Como medir a qualidade e segurança do código gerado por IA?
Estabeleça métricas como taxa de vulnerabilidades encontradas por linha de código, tempo médio de correção de falhas de segurança, e percentual de código que passa na primeira revisão de segurança. Acompanhe o volume de dependências inseguras introduzidas e a velocidade de remediação em comparação com código desenvolvido manualmente. Essas métricas orientam decisões sobre expansão ou restrição do uso de IA.

Qual é o papel do board e dos executivos na governança de código IA?
O board deve estabelecer diretrizes de risco aceitável e garantir que a gestão implemente controles adequados de segurança de software. Executivos de TI precisam alocar recursos para implementar SAST, DAST e processos de revisão robustos. A responsabilidade por incidentes de segurança relacionados a código gerado por IA permanece no nível executivo, exigindo supervisão contínua.

Como comunicar os riscos de vibe coding para o board e stakeholders?
Apresente casos reais de incidentes causados por código com defeitos, traduza riscos técnicos em termos financeiros e regulatórios, e mostre o impacto na reputação da empresa. Demonstre que implementar governança é mais econômico do que responder a incidentes e multas de conformidade. Use métricas de dívida técnica e segurança como linguagem comum com executivos.

Qual é a conformidade regulatória relacionada a código gerado por IA?
Regulações como LGPD, GDPR e frameworks de segurança financeira exigem que as empresas respondam por vulnerabilidades em suas aplicações, independente de quem gerou o código. Auditorias de segurança e testes de penetração precisam incluir validação de código IA para garantir conformidade. A falta de governança pode resultar em não conformidade demonstrada e exposição a penalidades.

A GovSimplix integra o Desenvolvimento Seguro ao seu modelo de governança como parte do domínio de Segurança da Informação, conectando as práticas de SDLC seguro às políticas corporativas, à gestão de riscos tecnológicos e aos controles de conformidade que dão visibilidade executiva ao estado de segurança do software da organização.

Sobre o autor

Julio César
Fundador e Arquiteto das Soluções, GovSimplix

Julio César é bacharel em Ciências da Computação pela USTJ e graduado em Análise e Desenvolvimento de Sistemas. É especialista pós-graduado em Cibersegurança e Governança de Dados pela PUC Minas e pós-graduado em Gestão Estratégica de Negócios pela Universidade Presbiteriana Mackenzie.

Possui certificação internacional de Lead Auditor para as normas ISO 27001 (Segurança da Informação), ISO 27701 (Privacidade da Informação) e ISO 42001 (Gestão de Inteligência Artificial), além da certificação Lean Six Sigma Black Belt, voltada para melhoria de processos e redução de variabilidade operacional.

Na GovSimplix, é o responsável pela concepção e evolução da arquitetura metodológica que estrutura os 11 domínios de governança empresarial da plataforma. Combina formação técnica, experiência em auditoria de sistemas de gestão e visão executiva para traduzir a complexidade da governança em estrutura operável para organizações de qualquer porte e setor.