Vibe Check: A checklist de segurança do programador 'vibe'

Se vale a pena construir, vale a pena proteger.

O 'vibe coding' tem gerado muito burburinho. Embora automatizar e codificar com IA não seja novidade, o 'vibe coding' promete democratizar o desenvolvimento de software: basta descrever o que você quer em linguagem natural e deixar que o LLM faça o resto. 

Desde IDEs aprimoradas por IA como Cursor, Copilot in VS Code e Windsurf, até plataformas que abstraem completamente a codificação (como Bolt, Lovable e v0), já houve uma explosão de ferramentas neste espaço, e esperamos que o crescimento exponencial continue.

Confira AINativeDev para uma visão geral do cenário de desenvolvimento de IA  

Queremos apenas boas vibrações

É libertador poder construir rapidamente e “esquecer que o código sequer existe” — especialmente se você não é um desenvolvedor profissional — mas o maior risco com o vibe coding é que você não sabe o que não sabe, e muitas vezes pode não entender o que o código gerado por IA faz. 

Claro, você pode validar que ele faz o que você espera, mas sem saber o que está acontecendo 'sob o capô', você nem sempre saberá quais riscos o código está criando até que seja tarde demais (e depurar é notoriamente mais difícil do que realmente escrever o código em primeiro lugar). Se você está se esforçando para construir algo—mesmo que esteja acelerando esse processo através do 'vibe coding'—a última coisa que você quer é ser atrasado por incidentes de segurança.

Mesmo desenvolvedores experientes têm pontos cegos quando se trata de segurança, e embora o 'vibe coding' torne o desenvolvimento de software mais acessível, também o torna mais rápido e fácil de deixar seu aplicativo exposto a vulnerabilidades e ataques, como injeções SQL, ataques de path traversal e Secrets vulneráveis a agentes mal-intencionados. Enquanto algumas plataformas de 'vibe coding' estão se esforçando para se antecipar às vulnerabilidades (o v0 é cético em relação ao código LLM por padrão), ainda existe um risco muito real de lacunas de segurança ao usar 'vibe coding'—levando à observação sarcástica de que 'vibe coding' = Vulnerability-as-a-Service. 

Considere o exemplo abaixo:

‍

Infelizmente, não há uma razão óbvia pela qual nosso amigo infeliz acima teve que desligar seu aplicativo e começar de novo. É claro que suas chaves de API foram vazadas, o que permitiu que hackers o impersonassem, significando que eles poderiam acessar ou alterar dados, funcionalidades ou recursos.

Qualquer número de armadilhas de gerenciamento de chaves de API inseguras poderia ter estado em jogo aqui: hardcoding de Secrets em seu aplicativo, um arquivo de variável de ambiente inadvertidamente carregado em seu servidor, ou ser vítima de uma vulnerabilidade de path traversal (ei, até aconteceu com a Atlassian). Sem verificações e processos de segurança adicionais, teria sido fácil para um hacker ou bot obter acesso às suas chaves de API. 

Vulnerabilidades e riscos de segurança comuns

Seja apenas você e o ChatGPT, ou se você está fazendo 'vibe coding' com uma ferramenta dedicada como o Lovable, você está vulnerável a esses tipos comuns de ciberataques. 

cross-site scripting (XSS)

Um ataque de cross-site scripting (XSS) explora vulnerabilidades em aplicações web onde a entrada fornecida pelo usuário não é devidamente validada ou sanitizada antes de ser exibida ou processada. Hackers podem então “injetar” código malicioso através da entrada do usuário, e quando o script injetado é executado, ele pode acessar informações sensíveis ou realizar ações não autorizadas em nome da vítima (neste caso, um de seus usuários). Ataques XSS podem ser uma diversão inofensiva (como neste tweet de auto-retweet), mas eles colocam seus usuários em risco de ter seus dados expostos ou até mesmo suas contas controladas por hackers. 

Ataques de injeção SQL

Assim como o XSS, um ataque de injeção SQL (SQLi) injeta código malicioso em uma aplicação, frequentemente por meio de um campo de entrada de usuário vulnerável. Como SQL é a linguagem que muitas aplicações usam para consultar seus bancos de dados subjacentes, esse tipo de ataque permite que hackers visualizem ou modifiquem seu banco de dados — acessando dados confidenciais ou até mesmo excluindo registros. A violação de dados da Equifax em 2017 foi resultado de um ataque de injeção SQL; a própria Equifax não foi o alvo — a empresa falhou em aplicar um patch de segurança em uma de suas dependências.  

Ataques de path traversal

Atacantes podem manipular entradas de caminho de arquivo (tipicamente URLs ou parâmetros de arquivo) para enganar seu aplicativo a retornar arquivos ou diretórios não públicos, contornando os controles de acesso e permitindo que leiam e escrevam em arquivos contendo dados confidenciais. Este tipo de ataque também é possível devido a entradas de usuário inseguras. Em 2010, pesquisadores descobriram uma vulnerabilidade de path traversal no aplicativo Confluence da Atlassian que teria permitido aos atacantes recuperar qualquer arquivo no servidor que estivesse executando o Confluence, com base nas permissões do usuário sob o qual o Confluence estava sendo executado.

Vazamento de Secrets

Secrets—como senhas, chaves de criptografia, tokens de API e certificados digitais—dão a agentes mal-intencionados as chaves do seu reino. Esses dados sensíveis podem permitir que hackers se passem por você, acessem seus dados e modifiquem seu código. Impressionantes 23 milhões de Secrets foram encontrados em repositórios de código-fonte públicos em 2024, de acordo com o relatório State of Secrets Sprawl da GitGuardian (um aumento de 25% em relação ao ano anterior). Secrets podem ser expostos por hardcoding acidental em seu aplicativo, ou através de uma vulnerabilidade como o comprometimento tj-actions/changed-files de março de 2025: atacantes modificaram o código da GitHub Action tj-actions/changed-files, fazendo com que a ação comprometida imprimisse Secrets de CI/CD nos logs de build do GitHub Actions.

ataques à Supply chain

Até 85-95% do código da sua aplicação pode ser alimentado por bibliotecas e projetos open-source. Os ataques à Supply chain não exploram um tipo específico de vulnerabilidade ou visam uma aplicação em particular, mas sim os projetos open-source subjacentes dos quais muitas empresas dependem. A violação de dados da Equifax mencionada acima foi resultado de um ataque à Supply chain que já havia sido mitigado — demonstrando a importância de monitorar suas dependências e aplicar patches de segurança prontamente. 

Vibe coding é uma ferramenta incrível para exploração e construção de uma prova de conceito, mas no momento em que você estiver interessado em transformar algo em um produto e negócio viável, você vai querer configurar verificações de segurança e melhores práticas para proteger o que você construiu. 

Não posso simplesmente pedir à IA para escrever código mais seguro?

Veja bem, esta é uma pergunta válida. Sabemos que a IA não escreve código seguro por padrão, mas uma melhoria muito rápida e simples é pedir explicitamente para que o torne seguro (literalmente adicionando as palavras “e torne-o seguro” ao seu prompt). Surpreendentemente, isso realmente resulta em código com menos vulnerabilidades.

Você também pode fazer com que a IA revise seu próprio código em busca de vulnerabilidades e lacunas de segurança, como pedir para encontrar Secrets hardcoded, verificar se os dados não estão acessíveis publicamente, escanear o projeto em busca de dependências vulneráveis ou identificar campos de entrada do usuário (como formulários) com validação de entrada insuficiente. Todos esses esforços melhorarão a segurança da sua aplicação.

Mas o ponto de verificar o código gerado por IA em busca de potenciais alucinações, vulnerabilidades ou outras lacunas de segurança é que é muito arriscado deixá-lo corrigir-se sem supervisão humana. Você pode absolutamente integrar a IA com métodos de varredura tradicionais para aprimorar as coisas, mas não substituí-los (por exemplo, o Aikido usa IA para fazer o auto-triage de alertas de segurança e propor correções).

Os engenheiros de software mais competentes são geralmente aqueles que se sentem mais à vontade para admitir quando não sabem algo. O problema de depender demais da IA para se policiar é que não é incomum que ela faça uma afirmação confiante sobre algo que está errado, em vez de admitir incerteza. É por isso que não recomendamos depender apenas da IA para proteger sua aplicação.

A boa notícia é que muitas empresas e projetos de código aberto têm se dedicado a abordar essas questões de segurança muito antes de o vibe coding se tornar uma realidade. Uma das maiores lições que novos desenvolvedores aprendem é a de se apoiar nos ombros de gigantes. Haverá muitos componentes em sua aplicação que são sensíveis e de missão crítica (coisas como autenticação, criptografia, ou até mesmo como você permite que os usuários façam upload de arquivos para sua UI), e pedir ao Cursor ou GPT para construí-los para você é: 

1. Não vai agregar à diferenciação do seu produto
2. Altamente provável de introduzir riscos de segurança

Nesses casos, é muito melhor contar com provedores que se concentram puramente em soluções para esses problemas. LLMs não são especificamente treinados em melhores práticas ou na resolução de um problema da maneira mais eficiente ou segura. Em muitos casos, a solução mais elegante é usar um serviço pré-existente em vez de construir o seu próprio (mesmo que você esteja delegando o trabalho pesado à IA).

É fácil ficar sobrecarregado e não saber por onde começar. Compilamos esta lista de verificação para ajudar você a começar a desenvolver com mais segurança. 

Nível 0

Estas são as medidas de segurança básicas que você vai querer implementar o mais rápido possível. Uma vez que essas práticas estejam configuradas e façam parte do seu processo, você pode construir livremente sem "matar a vibe".

Implemente melhores práticas de Git

Um dos erros comuns do vibe coding é que, ao adicionar novas funcionalidades ou tentar corrigir um problema, é mais intuitivo simplesmente substituir o que você tinha antes pelo novo código gerado por IA. Isso funciona até deixar de funcionar; eventualmente, você pode chegar a um ponto em que nada que a IA produz ajuda e você está em uma situação ainda pior do que antes.

É para isso que serve o controle de versão

O controle de versão, como o Git, surgiu como uma forma de os desenvolvedores colaborarem em projetos sem sobrescrever o trabalho uns dos outros. Mas mesmo que você esteja desenvolvendo sozinho, ele serve como uma forma de fazer backup do seu progresso, o que ajuda a isolar bugs e a reverter uma alteração quando algo dá errado. Aqui estão três práticas essenciais do Git que o ajudarão a construir com mais segurança:

Crie um arquivo .gitignore para arquivos sensíveis

Um arquivo .gitignore é simplesmente um arquivo de texto simples que informa ao Git o que ignorar (ou seja, não commitar para o seu repositório). Normalmente, você quer que o Git ignore arquivos gerados por computador, como logs, pois eles sobrecarregam seu repositório e podem conter informações sobre o aplicativo que poderiam ser usadas para comprometê-lo. Seu arquivo .env também deve ser ignorado, pois ele contém variáveis de ambiente sensíveis (como chaves de API e senhas) que hackers poderiam usar para se passar por você e obter acesso ao seu sistema. 

Mantenha um histórico de commits claro

Manter as alterações o mais autocontidas possível facilita a identificação de quando um bug ou vulnerabilidade foi introduzido, e torna mais fácil reverter sem ter que refazer outro trabalho. Indo um passo além e configurando commits assinados verifica se os desenvolvedores corretos estão commitando código para o seu repositório (mesmo que seja apenas você!). 

Separe os branches de desenvolvimento de features, staging e produção

O branching no Git ajuda a criar espaços distintos e autocontidos para trabalhar, pré-visualizar e lançar código. Desenvolver ativamente novas funcionalidades em um branch separado ajuda a evitar que código inacabado, com bugs ou inseguro seja acidentalmente commitado na sua aplicação em produção. Uma vez que uma nova funcionalidade ou recurso é totalmente desenvolvido e testado, um branch de staging atua como outra barreira de segurança e qualidade, permitindo revisar e finalizar as alterações antes de lançar para produção. Apenas funcionalidades totalmente testadas e estáveis podem então ser mescladas no seu branch de produção (geralmente chamado de main).

Repositórios Git hospedados: GitHub GitLab   

Mantenha os Secrets separados do código

‍

‍

Secrets — como suas senhas, chaves de criptografia, tokens de API e certificados digitais — devem ser tratados separadamente do código para evitar fazer commit diretamente em sua base de código. Você pode verificar seu código em busca de Secrets com o Aikido, mesmo a partir do seu Cursor IDE.

Proteja seu aplicativo contra ataques DDoS

Um Ataque Distribuído de Negação de Serviço (DDoS) tenta interromper o tráfego normal de um servidor, serviço ou rede alvo, sobrecarregando o alvo ou sua infraestrutura circundante com um pico de tráfego da Internet. Esses ataques podem ter consequências devastadoras, e é surpreendentemente simples proteger-se integrando proteções DDoS básicas com uma rede de entrega de conteúdo (CDN) como Cloudflare ou CloudFront. Alguns provedores de hospedagem de domínio até oferecem uma CDN como um serviço integrado. 

Não faça a autenticação por conta própria

A autenticação (como seu fluxo de login) é um componente sensível da sua aplicação que você vai querer deixar para os especialistas. Usar uma ferramenta dedicada para impor uma política de senhas e oferecer facilmente single sign-on ou até mesmo autenticação multifator para seu aplicativo à medida que você escala protegerá suas contas de usuário e sua reputação. 

Ótimas ferramentas: Auth0, Quasr 

Nunca faça sua própria criptografia

Da mesma forma, criptografia é uma expertise, então sempre confie em mecanismos, bibliotecas e ferramentas estabelecidos. Construir suas próprias implementações, ou usar flags e opções que você não compreende totalmente,

o exporá a grandes riscos. Bibliotecas como NaCL expõem poucas opções, restringindo você a boas escolhas.

Nível 1

Configure um pipeline de CI/CD para monitorar seu código

Implementar um pipeline de CI/CD com testes é como adicionar pontos de controle de qualidade à linha de montagem do código da sua aplicação. Você pode integrar ferramentas de análise estática de código para realizar Testes de segurança de aplicações estáticas (SAST), que escaneia seu código em busca de falhas que podem levar a vulnerabilidades de segurança. Você também pode integrar uma ferramenta para Testes Dinâmicos de Segurança de Aplicações (DAST) (às vezes chamado de monitoramento de superfície) para simular ataques e identificar vulnerabilidades no frontend da sua aplicação web (como procurar portas abertas ou tráfego de entrada irrestrito). 

DAST Open-source: ZAP

SAST Open-source: Opengrep

Monitore suas dependências  

Quer você esteja ciente ou não, a maior parte do código que alimenta sua aplicação provavelmente é proveniente de projetos de código aberto e bibliotecas de terceiros nos quais os modelos de IA são treinados. Essas são suas dependências, e às vezes até elas têm suas próprias dependências — tudo isso compõe sua cadeia de suprimentos de software. Uma única falha em qualquer uma dessas bibliotecas pode colocar toda a sua aplicação em risco, mas você pode reduzir o risco usando as ferramentas certas para monitorar suas dependências em busca de vulnerabilidades conhecidas.

Ferramenta recomendada: Trivy

Configure-o em segundos com o Aikido

Verifique suas dependências em busca de malware

Da mesma forma, sua cadeia de suprimentos pode incluir pacotes maliciosos contendo malware. Estes são excepcionalmente perigosos, pois os atacantes geralmente agem rapidamente depois de conseguirem inserir malware em seu código. Portanto, você também precisa reagir rapidamente. Observe que os bancos de dados de Common Vulnerabilities and Exposures (CVE) são muito lentos e não o manterão seguro contra esses tipos de ataques.

Ferramentas: Aikido Intel

Configure-o em segundos com o Aikido

Use lockfiles para proteger sua cadeia de suprimentos

Se você não usar lockfiles, sempre que compilar sua aplicação, você puxará as versões mais recentes de todos os pacotes de código aberto. Lockfiles permitem builds reproduzíveis ao puxar as mesmas versões de suas dependências de código aberto. Isso mantém sua aplicação estável no caso de quaisquer mudanças disruptivas em suas dependências, mas também protege seu aplicativo contra ataques à cadeia de suprimentos quando a versão mais recente de uma dependência foi comprometida. Um exemplo recente disso é a vulnerabilidade tj-actions/changed-files de março de 2025: atacantes modificaram o código da GitHub Action tj-actions/changed-files, fazendo com que a ação comprometida imprimisse Secrets de CI/CD nos logs de build do GitHub Actions.  

Previna ataques de cross-site scripting com cabeçalhos CSP rigorosos

Cabeçalhos CSP podem protegê-lo de ataques XSS comuns, fornecendo uma camada de segurança adicional que controla quais recursos dinâmicos podem ser carregados. Isso impede que atacantes injetem scripts em suas páginas da web.

Verifique se você os configurou corretamente com o Aikido

Use um firewall de aplicação web

Use um firewall de aplicação web (WAF) ou autoproteção de aplicações em tempo de execução (RASP) para proteger servidores expostos à web contra ameaças zero-day desconhecidas, incluindo injeção de SQL ou ameaças XSS desconhecidas. A ferramenta varre e previne requisições de usuários com comportamento suspeito ou malicioso (como um payload de injeção), atuando como uma última linha de defesa contra ataques. 

Ótimas ferramentas: AWS WAF Aikido Zen

Nível 2

Com as medidas de segurança acima implementadas, é hora de aprimorar sua postura de segurança.

Implemente melhores práticas para Containers

Containers empacotam software para que ele possa ser executado de forma confiável ao ser movido de um ambiente de computação para outro. Eles agrupam uma aplicação com todas as suas dependências necessárias, como bibliotecas, frameworks e arquivos de configuração (tudo em sua cadeia de suprimentos), em um único pacote. Isso garante que a aplicação seja executada de forma consistente, independentemente do ambiente em que é implantada. 

Se você usa Containers para implantação, existem algumas boas práticas que ajudarão a fortalecer sua aplicação.

Mantenha suas imagens base Docker atualizadas 

Vulnerabilidades na sua imagem base de Container (o projeto do que seu Container é composto) colocam sua aplicação em risco. Baixe regularmente todas as atualizações de segurança para sua imagem base. Para servidores, você pode delegar isso a um provedor de PaaS como Heroku ou AWS Beanstalk.

Verifique a segurança do seu Docker usando: Syft Grype Trivy

Configure-o em segundos com o Aikido

Execute Container Docker com privilégios restritos

Privilégios limitados dificultam que atacantes bem-sucedidos assumam o controle do host ou saltem para outros serviços. Evite executar Containers com funções de usuário privilegiadas, como root em sistemas Unix, ou Administrator ou System em sistemas Windows.

Proteja seus Secrets

Manter os Secrets separados do código é um ótimo começo. Se você estiver usando Containers, também vai querer garantir que seus arquivos de Secrets e outros dados sensíveis estejam adequadamente protegidos. Isso inclui o uso de ferramentas de gerenciamento de Secrets (muitos provedores de Cloud oferecem as suas próprias), Secrets do Kubernetes se estiver usando Kubernetes, rotacionar Secrets regularmente e definir datas de expiração para seus Secrets. 

Ferramentas de gerenciamento de Secrets: HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

Leia mais: Gerenciando Secrets com Segurança em Containers: Melhores Práticas e Estratégias

Verifique seus pacotes quanto ao seu Fim de Vida (EOL)

À medida que os pacotes envelhecem e deixam de ser suportados, o risco de exploits aumenta. Você deve se certificar de atualizar os pacotes que estão prestes a atingir o fim de sua vida útil.

Ou configure em segundos com o recurso de varredura de Container do Aikido

Implemente melhores práticas para suas contas Cloud

Mantenha as contas Cloud de desenvolvimento, staging e produção separadas 

Assim como você deseja manter seus branches Git de desenvolvimento, staging e produção separados, o mesmo se aplica às suas contas Cloud. Embora você pudesse criar redes virtuais dentro de suas contas Cloud para manter staging e produção separadas, isso pode se tornar complicado mais tarde, à medida que você cresce, pois você acabará gerenciando continuamente os direitos de acesso de usuários para novos desenvolvedores. Recomendamos manter a infraestrutura de desenvolvimento, staging e produção em contas Cloud completamente separadas. Todos os provedores Cloud oferecem faturamento unificado, o que é uma dor de cabeça a menos.

Utilize ferramentas de gestão de postura de Cloud

Provedores de Cloud oferecem tantos recursos que é fácil perder ou configurar incorretamente algo que o coloca em risco. Use uma ferramenta de gerenciamento de postura de segurança na Cloud (CSPM) para escanear sua Cloud em busca de anomalias.

Ferramentas CSPM: Cloudsploit AWS Inspector

Configure-o em segundos com o Aikido

Habilitar alertas de orçamento da Cloud

No caso de sua conta na Cloud ser invadida, uma maneira infalível de detectar que alguém está minerando Bitcoin em sua conta é ter alertas de orçamento configurados para monitorar os gastos. Seu provedor de Cloud deve oferecer alertas integrados para isso, ou você pode configurar o scanning da Cloud com Aikido para verificar preocupações orçamentárias e configurações incorretas de risco. 

Verifique seus LLMs em busca dos exploits mais comuns

Além de construir com LLMs, você pode estar integrando LLMs em seu produto voltado para o público. Você pode ter um chatbot oferecendo suporte aos usuários, ou um assistente de IA que os ajuda no onboarding. Se seus clientes interagem com um LLM de qualquer forma, é uma boa ideia testá-los para os exploits mais comuns, para que você não exponha os clientes a riscos de segurança. 

Verifique os exploits mais comuns: Top 10 OWASP para LLMs

Além

Implemente um ciclo de vida de desenvolvimento seguro

Uma grande parte da prática de segurança moderna é o 'shifting left' — trazer as medidas de segurança para o ciclo de vida de desenvolvimento mais cedo. Isso ajuda você a adquirir o hábito de boas práticas em todas as etapas do projeto e a identificar problemas mais cedo, antes que se tornem uma ameaça real. Isso significa aderir a uma lista de verificação de segurança como esta, familiarizar-se com falhas de segurança típicas e procurá-las durante a revisão de código, e implementar verificações de segurança em pull requests também. 

Leia mais: OWASP Top Ten

Leia mais: artigo da Wikipedia sobre ciclo de vida de desenvolvimento de sistemas

Qualquer um pode ser vítima de um ciberataque — mesmo empresas multinacionais com departamentos de segurança dedicados ainda são vulneráveis a violações. Embora o código 'vibe' não seja seguro por padrão, ao adotar as melhores práticas de segurança desde o início, você ainda pode se entregar totalmente às 'vibes'. Tudo o que você está construindo vale o esforço. 

Leitura adicional

• Checklist de Segurança para CTOs de SaaS 2025 do Aikido
• O Guia de Código Aberto da Startup para Segurança de Aplicações

Baixe sua Checklist de Segurança de Codificação Vibe gratuita