A geração de código assistida por inteligência artificial aumenta em quatro vezes a produtividade dos engenheiros de software, mas multiplica por dez o número de vulnerabilidades de segurança nos projetos. As conclusões resultam de uma investigação conduzida pela empresa de cibersegurança Apiiro junto de companhias do índice Fortune 50, revelando que a ausência de revisão humana expõe dispositivos, programadores e utilizadores finais a riscos severos.
Popularizado no início do ano passado por Andrej Karpathy, cofundador da OpenAI, o conceito de “vibe coding” descreve o hábito de criar software conversando apenas com um modelo de IA, sem analisar a fundo a estrutura subjacente. Na altura, o investigador resumiu esta prática na rede social X afirmando: “Eu apenas vejo coisas, digo coisas, executo coisas e copio e colo coisas, e na maioria das vezes funciona”. Embora este método permita avançar rapidamente com menos recursos, requer a aplicação de cinco medidas de proteção essenciais.
Especificar regras de segurança num ficheiro de contexto
Os modelos de IA tendem a procurar atalhos rápidos para entregar um resultado funcional imediato, ignorando verificações de segurança ou a proteção de informações críticas se não forem instruídos nesse sentido. Quem desenvolve um projeto deve detalhar nos pedidos todas as exigências de privacidade, limites de permissões de acesso a cada área do sistema e mecanismos de encriptação (codificação que impede a leitura de dados por terceiros não autorizados). Solicitar ao assistente que consulte a lista OWASP Top 10 ajuda a travar as vulnerabilidades mais comuns antes mesmo de a primeira linha ser escrita.
Para evitar repetir estas instruções em todas as sessões, a solução passa por criar regras persistentes através de um ficheiro Markdown (.md) ou configurar a secção “Knowledge” no agente Lovable e a área “Memory” no Replit. Estes documentos obrigam o modelo a respeitar as diretrizes de cibersegurança em cada nova tarefa. A escolha de ferramentas de programação que suportem registos de auditoria (audit logs) permite ainda acompanhar o histórico completo de modificações feitas no projeto.
Isolar chaves de API e palavras-passe fora do código
Introduzir palavras-passe ou chaves de API (credenciais que permitem a comunicação e autenticação direta entre diferentes serviços de software) diretamente na janela de conversação ou no código-fonte representa um perigo imediato. Se o projeto for posteriormente publicado em plataformas como o GitHub, essas credenciais ficam visíveis para qualquer pessoa. Restringir o acesso da ferramenta de IA a dados sensíveis previne igualmente ataques de injeção de prompts, nos quais instruções maliciosas escondidas tentam manipular o comportamento do modelo.
O método mais seguro para principiantes consiste em guardar estes dados num gestor de palavras-passe dedicado e recorrer aos separadores de variáveis de ambiente (“environmental variables” ou “secrets”) integrados em plataformas como o Replit, Lovable ou Vercel. Caso o programa utilizado não inclua esta funcionalidade de origem, é necessário criar um ficheiro .env no servidor (backend) e adicioná-lo ao ficheiro .gitignore, garantindo que nunca se torna público nem fica acessível na interface visível da aplicação ou do site (frontend). A ferramenta TruffleHog pode ser utilizada para analisar o repositório e confirmar que nenhuma informação confidencial foi exposta acidentalmente.
Blindar bases de dados SQL e validar bibliotecas
Aplicações que processam grandes volumes de informação, à semelhança do que acontece em serviços de consumo como o Spotify para otimizar o envio de dados, recorrem frequentemente à linguagem SQL (Structured Query Language). Bases de dados SQL mal protegidas abrem portas a ataques de injeção de SQL, permitindo que piratas informáticos roubem, apaguem ou substituam registos livremente.
Para bloquear estas intrusões, o utilizador deve exigir que a IA parametrize as consultas, limpe os dados de entrada (sanitização de inputs), utilize Server Actions para operações críticas e ative políticas de segurança ao nível da linha (Row-Level Security, ou RLS), que restringem a leitura de dados consoante o perfil de quem acede. É igualmente necessário confirmar se o modelo está a aplicar as versões mais recentes das bibliotecas de software, vigiando eventuais alucinações da IA que possam referenciar pacotes inexistentes ou integrar módulos maliciosos por engano.
Limitar a frequência de pedidos e auditar o resultado final
A aplicação de limites de frequência (rate limiting) restringe o número de vezes que uma pessoa ou um bot consegue executar uma ação específica num determinado período. Esta barreira protege o sistema contra ataques de negação de serviço distribuídos (DDoS, que tentam deitar abaixo um servidor através de um volume massivo de tráfego) e trava tentativas de adivinhar credenciais por força bruta ou credential-stuffing. Num assistente gratuito, por exemplo, limitar o consumo diário de tokens por utilizador evita despesas financeiras descontroladas. O bloqueio deve priorizar o identificador da conta (ID) antes do endereço IP, impedindo que os atacantes contornem as restrições através do uso de redes privadas virtuais (VPN), sendo recomendável complementar o acesso com sistemas CAPTCHA e autenticação por email ou telemóvel.
Quando não é possível recorrer a um engenheiro de software profissional para inspecionar o trabalho, o próprio modelo que gerou o projeto deve ser instruído para procurar falhas e testar o código novamente face aos riscos do OWASP Top 10, cruzando depois essa revisão com outros modelos de IA distintos. Existem também plataformas especializadas na avaliação de projetos criados por esta via, nomeadamente o Claude Code Security, Codex Security, Wingman da Stackhawk, CheckVibe, SafeToShip e o Vibe App Scanner, mas a monitorização contínua tem de ser mantida mesmo após o lançamento público da aplicação ou página Web.
(TT)