Como a Cibersegurança se Prepara para Ataques em Projetos de Código Gerados por IA
Um guia detalhado sobre como proteger projetos de código gerados por IA, utilizando ferramentas SAST, Quality Gates e modelos de IA para identificar e corrigir vulnerabilidades. O artigo explora a integração de ferramentas como SonarQube Cloud e Semgrep, além de discutir os desafios e soluções para garantir a segurança do código.
MundiX News·09 de maio de 2026·15 min de leitura·👁 4 views
Como a Cibersegurança se Prepara para Ataques em Projetos de Código Gerados por IA
Introdução
Projetos de código gerados por inteligência artificial (IA) podem ser incríveis, mas a realidade bate quando você abre o primeiro relatório de um scanner de segurança e se depara com centenas de problemas. Este artigo detalha como construir um pipeline em torno de um projeto de LLM (Large Language Model), integrando ferramentas SAST (Static Application Security Testing), configurando um Quality Gate como bloqueador de deploy e usando modelos para correções – não em substituição às ferramentas, mas em conjunto com elas. Apresentaremos um projeto real com dados concretos, útil para quem usa LLMs para escrever código e para especialistas em appsec/devsecops.
Parte 1: Contexto, Dados do Relatório DryRun Security e um Pouco de Teoria sobre DevSecOps
Começaremos com o contexto e alguns dados do relatório DryRun Security para entender a situação. Em julho de 2025, Brian Cherny, engenheiro da equipe Claude Code na Anthropic, escreveu no X (antigo Twitter): "Praticamente 100% do nosso código é escrito por Claude Code + Opus 4.5. Pessoalmente, já estou em 100% há mais de dois meses – nem faço edições manuais. Ontem fechei 22 pull requests, anteontem 27, e cada um deles foi escrito inteiramente por Claude." Ele acrescentou que a maioria da indústria atingiria estatísticas semelhantes nos próximos meses. A empresa DryRun Security publicou em março de 2026 o relatório "The Agentic Coding Security Report", que avaliou Claude (Sonnet 4.6), Codex (GPT 5.2) e Gemini (2.5 Pro). Cada um recebeu a mesma tarefa: escrever dois aplicativos do zero, adicionando recursos via pull requests. Após cada PR, um scanner de segurança foi executado. Os resultados foram interessantes: 87% dos pull requests continham pelo menos uma vulnerabilidade, totalizando 143 problemas de segurança em 38 verificações, além de outros problemas. As vulnerabilidades mais comuns foram Broken Access Control, Hardcoded JWT secrets, WebSocket Auth Bypass, IDOR, User Enumeration, XSS e Race Conditions (TOCTOU).
O relatório revelou que, embora os LLMs escrevam código de forma razoável, é crucial verificar a segurança e a qualidade. Portanto, neste artigo, discutiremos como aprimorar a segurança de projetos de código gerados por IA, levando-os a um estado mais seguro e de alta qualidade. Para isso, usaremos o Opensophy Hub, uma plataforma estática para documentação com blocos Markdown, painel de desenvolvimento, tabelas interativas, componentes de UI e um editor ao vivo.
Teoria DevSecOps: Quality Gate
Para entender o processo DevSecOps, é essencial entender o Quality Gate. Simplificadamente, é um conjunto de regras que o código deve cumprir antes de avançar no pipeline. Isso inclui: cobertura de testes mínima, ausência de novas vulnerabilidades, ausência de code smells críticos e uma avaliação de confiabilidade aceitável. Para projetos open-source, a escolha de uma ferramenta SAST em nuvem, como SonarQube Cloud, que verifica o código a cada push, é ideal. Se o Quality Gate não for aprovado, o GitHub Actions interrompe o processo, impedindo o deploy até que os problemas sejam corrigidos.
Integração de IA: Abordagem e Ferramentas
Para evitar que o mesmo modelo "escreva código = faça a avaliação", podemos usar uma abordagem em que Claude Sonnet 4.5 escreve o código e Claude Sonnet 4.6 corrige as vulnerabilidades. É crucial que o modelo não substitua as ferramentas de análise, como SonarQube Cloud, que fornecem detalhes precisos sobre os problemas. O modelo trabalha com essa lista, avaliando o código de forma direcionada, e não tentando avaliar o código inteiro "a olho".
Parte 2: Conectando o SonarQube Cloud e Configurando o Quality Gate
Após o registro no SonarQube Cloud e a primeira verificação, vá para Administration -> Analysis method para ver as opções de integração: Automatic analysis, GitHub Actions, CircleCI e Manual. O SonarQube Cloud fornece instruções detalhadas para cada método. Para a maioria dos projetos, a análise automática é preferível devido à sua fácil configuração. O GitHub Actions é útil para bloquear o deploy se o Quality Gate não for aprovado. Com a análise automática, o SonarQube Cloud analisa o código de forma assíncrona, e o deploy pode ocorrer antes da conclusão da análise. Com o GitHub Actions, você pode criar uma cadeia que bloqueia o deploy: push -> sonarqube job -> build -> deploy, onde build não é executado até que sonarqube seja concluído com sucesso.
Se o Quality Gate falhar, os logs do GitHub Actions mostrarão um erro e um link para o painel do SonarQube Cloud. O SonarQube Cloud usa o Sonar way como Quality Gate padrão, que pode ser personalizado em Policies -> Quality Gates. As condições padrão para código novo incluem Security Rating A, Reliability Rating A, Maintainability Rating A, Coverage ≥ 80% e Duplicated Lines ≤ 3%.
Parte 3: Verificação do Código Hub, Relatórios e Correções via Claude 4.6
Após o deploy, com o SonarQube Cloud conectado, você pode ver os resultados da primeira análise, que pode revelar centenas de problemas, principalmente code smells. Para corrigir esses problemas, você pode usar a interface web do Claude. O processo envolve escrever um prompt, copiar o código com problemas, fazer capturas de tela dos problemas e enviá-los ao Claude. O prompt deve instruir o modelo a corrigir o código, torná-lo simples, legível e otimizado, considerando a necessidade de verificar falsos positivos. É importante evitar comentários desnecessários para manter o código limpo. Após as correções, o código deve passar na análise estática e atender ao Quality Gate.
Parte 4: Implementando Ferramentas Adicionais e Analisando seus Desafios
Após a configuração do SonarQube Cloud e a correção dos problemas, você pode adicionar o Semgrep, outra ferramenta SAST focada em segurança. O Semgrep oferece dois modos de análise: padrão e "IA". Após a análise, o Semgrep pode encontrar problemas adicionais que o SonarQube Cloud não detectou. A tarefa se torna complexa, pois é preciso corrigir os problemas do Semgrep sem quebrar o que já foi aprovado pelo SonarQube Cloud. O Semgrep pode fazer correções diretamente no repositório, criando um pull request com as correções. É importante monitorar os resultados das verificações após cada commit para identificar falsos positivos e garantir que a funcionalidade não seja comprometida.
Conclusões
Ao seguir essas etapas, você pode tornar um projeto de código gerado por IA mais seguro e limpo. A abordagem descrita reduz vulnerabilidades e code smells, fornece relatórios estruturados e se integra ao pipeline de desenvolvimento. No entanto, a análise SAST não garante a detecção de todos os problemas. Problemas arquiteturais, como WebSocket Auth Bypass, podem ficar de fora. A combinação de um agente que gera código, uma ferramenta que analisa e um agente que corrige não substitui a revisão de código, mas a aprimora. É crucial que os desenvolvedores tenham conhecimento básico de segurança para avaliar as saídas do modelo e evitar erros.
Recomendações Adicionais
Se houver suspeita de problemas arquiteturais, você pode dar ao modelo acesso total ao código e solicitar uma revisão de segurança. Outras ferramentas, como CodeFactor e SonarQube Cloud, podem ser combinadas para cobrir diferentes tipos de problemas. A escolha de ferramentas em nuvem simplifica o processo, tornando-o acessível e gratuito para projetos que se enquadram nos planos gratuitos.
Como a Cibersegurança se Prepara para Ataques em Projetos de Código Gerados por IA
Introdução
Projetos de código gerados por inteligência artificial (IA) podem ser incríveis, mas a realidade bate quando você abre o primeiro relatório de um scanner de segurança e se depara com centenas de problemas. Este artigo detalha como construir um pipeline em torno de um projeto de LLM (Large Language Model), integrando ferramentas SAST (Static Application Security Testing), configurando um Quality Gate como bloqueador de deploy e usando modelos para correções – não em substituição às ferramentas, mas em conjunto com elas. Apresentaremos um projeto real com dados concretos, útil para quem usa LLMs para escrever código e para especialistas em appsec/devsecops.
Parte 1: Contexto, Dados do Relatório DryRun Security e um Pouco de Teoria sobre DevSecOps
Começaremos com o contexto e alguns dados do relatório DryRun Security para entender a situação. Em julho de 2025, Brian Cherny, engenheiro da equipe Claude Code na Anthropic, escreveu no X (antigo Twitter): "Praticamente 100% do nosso código é escrito por Claude Code + Opus 4.5. Pessoalmente, já estou em 100% há mais de dois meses – nem faço edições manuais. Ontem fechei 22 pull requests, anteontem 27, e cada um deles foi escrito inteiramente por Claude." Ele acrescentou que a maioria da indústria atingiria estatísticas semelhantes nos próximos meses. A empresa DryRun Security publicou em março de 2026 o relatório "The Agentic Coding Security Report", que avaliou Claude (Sonnet 4.6), Codex (GPT 5.2) e Gemini (2.5 Pro). Cada um recebeu a mesma tarefa: escrever dois aplicativos do zero, adicionando recursos via pull requests. Após cada PR, um scanner de segurança foi executado. Os resultados foram interessantes: 87% dos pull requests continham pelo menos uma vulnerabilidade, totalizando 143 problemas de segurança em 38 verificações, além de outros problemas. As vulnerabilidades mais comuns foram Broken Access Control, Hardcoded JWT secrets, WebSocket Auth Bypass, IDOR, User Enumeration, XSS e Race Conditions (TOCTOU).
O relatório revelou que, embora os LLMs escrevam código de forma razoável, é crucial verificar a segurança e a qualidade. Portanto, neste artigo, discutiremos como aprimorar a segurança de projetos de código gerados por IA, levando-os a um estado mais seguro e de alta qualidade. Para isso, usaremos o Opensophy Hub, uma plataforma estática para documentação com blocos Markdown, painel de desenvolvimento, tabelas interativas, componentes de UI e um editor ao vivo.
Teoria DevSecOps: Quality Gate
Para entender o processo DevSecOps, é essencial entender o Quality Gate. Simplificadamente, é um conjunto de regras que o código deve cumprir antes de avançar no pipeline. Isso inclui: cobertura de testes mínima, ausência de novas vulnerabilidades, ausência de code smells críticos e uma avaliação de confiabilidade aceitável. Para projetos open-source, a escolha de uma ferramenta SAST em nuvem, como SonarQube Cloud, que verifica o código a cada push, é ideal. Se o Quality Gate não for aprovado, o GitHub Actions interrompe o processo, impedindo o deploy até que os problemas sejam corrigidos.
Integração de IA: Abordagem e Ferramentas
Para evitar que o mesmo modelo "escreva código = faça a avaliação", podemos usar uma abordagem em que Claude Sonnet 4.5 escreve o código e Claude Sonnet 4.6 corrige as vulnerabilidades. É crucial que o modelo não substitua as ferramentas de análise, como SonarQube Cloud, que fornecem detalhes precisos sobre os problemas. O modelo trabalha com essa lista, avaliando o código de forma direcionada, e não tentando avaliar o código inteiro "a olho".
Parte 2: Conectando o SonarQube Cloud e Configurando o Quality Gate
Após o registro no SonarQube Cloud e a primeira verificação, vá para Administration -> Analysis method para ver as opções de integração: Automatic analysis, GitHub Actions, CircleCI e Manual. O SonarQube Cloud fornece instruções detalhadas para cada método. Para a maioria dos projetos, a análise automática é preferível devido à sua fácil configuração. O GitHub Actions é útil para bloquear o deploy se o Quality Gate não for aprovado. Com a análise automática, o SonarQube Cloud analisa o código de forma assíncrona, e o deploy pode ocorrer antes da conclusão da análise. Com o GitHub Actions, você pode criar uma cadeia que bloqueia o deploy: push -> sonarqube job -> build -> deploy, onde build não é executado até que sonarqube seja concluído com sucesso.
Se o Quality Gate falhar, os logs do GitHub Actions mostrarão um erro e um link para o painel do SonarQube Cloud. O SonarQube Cloud usa o Sonar way como Quality Gate padrão, que pode ser personalizado em Policies -> Quality Gates. As condições padrão para código novo incluem Security Rating A, Reliability Rating A, Maintainability Rating A, Coverage ≥ 80% e Duplicated Lines ≤ 3%.
Parte 3: Verificação do Código Hub, Relatórios e Correções via Claude 4.6
Após o deploy, com o SonarQube Cloud conectado, você pode ver os resultados da primeira análise, que pode revelar centenas de problemas, principalmente code smells. Para corrigir esses problemas, você pode usar a interface web do Claude. O processo envolve escrever um prompt, copiar o código com problemas, fazer capturas de tela dos problemas e enviá-los ao Claude. O prompt deve instruir o modelo a corrigir o código, torná-lo simples, legível e otimizado, considerando a necessidade de verificar falsos positivos. É importante evitar comentários desnecessários para manter o código limpo. Após as correções, o código deve passar na análise estática e atender ao Quality Gate.
Parte 4: Implementando Ferramentas Adicionais e Analisando seus Desafios
Após a configuração do SonarQube Cloud e a correção dos problemas, você pode adicionar o Semgrep, outra ferramenta SAST focada em segurança. O Semgrep oferece dois modos de análise: padrão e "IA". Após a análise, o Semgrep pode encontrar problemas adicionais que o SonarQube Cloud não detectou. A tarefa se torna complexa, pois é preciso corrigir os problemas do Semgrep sem quebrar o que já foi aprovado pelo SonarQube Cloud. O Semgrep pode fazer correções diretamente no repositório, criando um pull request com as correções. É importante monitorar os resultados das verificações após cada commit para identificar falsos positivos e garantir que a funcionalidade não seja comprometida.
Conclusões
Ao seguir essas etapas, você pode tornar um projeto de código gerado por IA mais seguro e limpo. A abordagem descrita reduz vulnerabilidades e code smells, fornece relatórios estruturados e se integra ao pipeline de desenvolvimento. No entanto, a análise SAST não garante a detecção de todos os problemas. Problemas arquiteturais, como WebSocket Auth Bypass, podem ficar de fora. A combinação de um agente que gera código, uma ferramenta que analisa e um agente que corrige não substitui a revisão de código, mas a aprimora. É crucial que os desenvolvedores tenham conhecimento básico de segurança para avaliar as saídas do modelo e evitar erros.
Recomendações Adicionais
Se houver suspeita de problemas arquiteturais, você pode dar ao modelo acesso total ao código e solicitar uma revisão de segurança. Outras ferramentas, como CodeFactor e SonarQube Cloud, podem ser combinadas para cobrir diferentes tipos de problemas. A escolha de ferramentas em nuvem simplifica o processo, tornando-o acessível e gratuito para projetos que se enquadram nos planos gratuitos.
