Se vale a pena construir, vale a pena garantir.

A codificação de vibrações tem estado a gerar muito alarido. Embora a automatização e a codificação com IA não sejam uma novidade, a codificação de vibração tem a promessa de democratizar o desenvolvimento de software: basta descrever o que pretende em linguagem natural e deixar o LLM fazer o resto. 

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

Consulte o AINativeDev para uma visão geral do panorama de desenvolvimento da IA  

Queremos apenas boas vibrações

É libertador ser capaz de construir rapidamente e "esquecer que o código existe" - especialmente se não for um programador profissional - mas o maior risco com a codificação vibrante é não saber o que não sabe e, muitas vezes, pode não compreender o que o código gerado pela IA faz. 

Claro, pode validar que faz o que espera, mas sem saber o que se passa nos bastidores, nem sempre saberá quais os riscos que o código está a criar até ser tarde demais (e a depuração é notoriamente mais difícil do que escrever o código em primeiro lugar). Se está a fazer o esforço de construir algo - mesmo que esteja a acelerar esse processo através de codificação vibrante - a última coisa que quer é ser prejudicado por incidentes de segurança.

Até mesmo desenvolvedores experientes têm pontos cegos quando se trata de segurança e, embora a codificação vibe torne o desenvolvimento de software mais acessível, ela também torna mais rápido e fácil deixar seu aplicativo exposto a vulnerabilidades e ataques, como injeções de SQL, ataques de travessia de caminho e segredos vulneráveis a maus atores. Embora algumas plataformas de vibe coding estejam a fazer um esforço para se manterem à frente das vulnerabilidades(a v0 é, por defeito, cética em relação ao código LLM), ainda existe um risco muito real de falhas de segurança quando se faz vibe coding - levandoà observação sarcástica de que vibe coding = Vulnerability-as-a-Service. 

Basta ver o exemplo abaixo:

‍

Infelizmente, não há uma razão óbvia para que o nosso infeliz amigo acima tenha acabado por ter de encerrar a sua aplicação e começar de novo. É evidente que as suas chaves API foram divulgadas, o que permitiu que os hackers se fizessem passar por ele, o que significa que podiam aceder ou alterar dados, funcionalidades ou recursos.

Qualquer número de truques inseguros de gestão de chaves de API poderia ter estado aqui em causa: segredos de hardcoding na sua aplicação, um ficheiro de variável de ambiente inadvertidamente carregado para o seu servidor, ou ser vítima de uma vulnerabilidade de passagem de caminho (ei, até aconteceu à Atlassian). Sem verificações e processos de segurança adicionais, teria sido fácil para um hacker ou um bot obter acesso às suas chaves API. 

Vulnerabilidades e riscos de segurança comuns

Quer seja apenas você e o ChatGPT, ou esteja a codificar com uma ferramenta dedicada como o Lovable, está vulnerável a estes tipos comuns de ciberataques. 

XSS (Cross-Site Scripting)

Um ataque cross-site scripting (XSS) explora vulnerabilidades em aplicações Web em que a entrada fornecida pelo utilizador não é devidamente validada ou higienizada antes de ser apresentada ou processada. Os piratas informáticos podem então "injetar" código malicioso através da entrada do utilizador e, quando o script injetado é executado, pode aceder a informações sensíveis ou realizar acções não autorizadas em nome da vítima (neste caso, um dos seus utilizadores). Os ataques XSS podem ser divertidos e inofensivos (como neste tweet de auto-retweet), mas colocam os seus utilizadores em risco de verem os seus dados expostos ou mesmo as suas contas controladas por hackers. 

Ataques de injeção de SQL

Tal como o XSS, um ataque de injeção de SQL (SQLi) injecta código malicioso numa aplicação, muitas vezes através de um campo de entrada do utilizador vulnerável. Uma vez que a SQL é a linguagem que muitas aplicações utilizam para consultar a sua base de dados subjacente, este tipo de ataque permite que os hackers vejam ou modifiquem a sua base de dados - acedendo a dados confidenciais ou mesmo apagando registos. A violação de dados da Equifax em 2017 resultou de um ataque de injeção de SQL. A Equifax em si não foi visada - a empresa não aplicou um patch de segurança a uma das suas dependências.  

Ataques de travessia de caminhos

Os atacantes podem manipular as entradas de caminhos de ficheiros (normalmente URLs ou parâmetros de ficheiros) para enganar a sua aplicação e fazê-la devolver ficheiros ou diretórios não públicos, contornando os controlos de acesso e permitindo-lhes ler e escrever em ficheiros que contêm dados confidenciais. Este tipo de ataque também é possível graças a entradas inseguras do utilizador. Em 2010, os investigadores descobriram uma vulnerabilidade de passagem de caminho na aplicação Confluence da Atlassian que teria permitido aos atacantes recuperar qualquer ficheiro no servidor que executa o Confluence, com base nas permissões do utilizador sob o qual o Confluence estava a ser executado.

Fuga de segredos

Segredos - como palavras-passe, chaves de encriptação, tokens de API e certificados digitais - dão aos maus actores as chaves do seu reino. Estes dados sensíveis podem permitir que os hackers se façam passar por si, acedam aos seus dados e modifiquem o seu código. Um número impressionante de 23 milhões de segredos foi encontrado em repositórios de código-fonte públicos em 2024, de acordo com o relatório GitGuardian State of Secrets Sprawl (um aumento de 25% em relação ao ano anterior). Os segredos podem ser expostos através de hardcoding acidental na sua aplicação, ou através de uma vulnerabilidade como o compromisso tj-actions/changed-files de março de 2025: os atacantes modificaram o código tj-actions/changed-files do GitHub Action, fazendo com que a ação comprometida imprimisse segredos de CI/CD nos registos de compilação do GitHub Actions.

Ataques à cadeia de abastecimento

Cerca de 85-95% do código da sua aplicação pode ser alimentado por bibliotecas e projectos de código aberto. Os ataques à cadeia de abastecimento não exploram um tipo específico de vulnerabilidade ou visam uma determinada aplicação, mas sim os projectos de código aberto subjacentes dos quais muitas empresas dependem. A violação de dados da Equifax acima referida foi o resultado de um ataque à cadeia de fornecimento que já tinha sido mitigado - o que mostra a importância de monitorizar as suas dependências e de aplicar rapidamente correcções de segurança. 

O Vibe Coding é uma ferramenta fantástica para a exploração e construção de uma prova de conceito, mas no momento em que estiver interessado em transformar algo num produto e negócio viáveis, vai querer definir verificações de segurança e melhores práticas para proteger o que construiu. 

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

Olha, esta é uma pergunta válida. Sabemos que a IA não escreve código seguro por defeito, mas uma melhoria muito rápida e suja é pedir-lhe explicitamente para o tornar seguro (ou seja, adicionar literalmente as palavras "e torná-lo seguro" ao seu pedido). Surpreendentemente, isto resulta efetivamente num código com menos vulnerabilidades.

Também pode fazer com que a IA reveja o seu próprio código em busca de vulnerabilidades e falhas de segurança, por exemplo, pedindo-lhe para encontrar segredos codificados, verificar se os dados não estão acessíveis publicamente, analisar o projeto em busca de dependências vulneráveis ou identificar campos de entrada do utilizador (como formulários) com validação de entrada insuficiente. Todos estes esforços irão melhorar a segurança da sua aplicação.

Mas o objetivo de verificar os factos do código gerado pela IA para detetar potenciais alucinações, vulnerabilidades ou outras lacunas de segurança é que é demasiado arriscado fazer com que ele se corrija sozinho sem supervisão humana. É absolutamente possível integrar a IA com os métodos de verificação tradicionais para melhorar as coisas, mas não para as substituir (por exemplo, o Aikido utiliza a IA para fazer uma triagem automática dos alertas de segurança e propor correcções).

Os engenheiros de software mais fortes também são normalmente os que se sentem mais à vontade para admitir quando não sabem alguma coisa. O problema de confiar demasiado na IA para se policiar a si própria é que não é invulgar que ela faça uma afirmação confiante sobre algo que está errado, em vez de admitir a incerteza. É por isso que não recomendamos que se confie apenas na IA para proteger a sua aplicação.

A boa notícia é que muitas empresas e projectos de código aberto têm-se dedicado a resolver estas questões de segurança muito antes de a codificação vibe se ter tornado uma coisa. Uma das maiores lições que os novos programadores aprendem é apoiarem-se nos ombros de gigantes. Haverá muitos componentes da sua aplicação que são sensíveis e de missão crítica (coisas como autenticação, criptografia, ou mesmo apenas 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 contribuir para a diferenciação do seu produto
2. Elevada probabilidade de introduzir riscos de segurança

Nesses casos, é muito melhor recorrer a fornecedores que se concentram apenas em soluções para esses problemas. Os LLMs não têm formação específica sobre as melhores práticas ou sobre como resolver um problema da forma mais eficiente ou segura. Em muitos casos, a solução mais elegante é utilizar um serviço pré-existente em vez de construir o seu próprio serviço (mesmo que esteja a transferir o trabalho pesado para a IA).

É fácil ficar sobrecarregado e não saber por onde começar. Elaborámos esta lista de verificação para o ajudar a começar a construir de forma mais segura. 

‍

Nível 0

Estas são as medidas de segurança que devem ser implementadas o mais rapidamente possível. Assim que estas práticas estiverem implementadas e fizerem parte do seu processo, pode construir livremente sem matar a vibração.

Implementar as melhores práticas do Git

Uma das armadilhas comuns da codificação por vibração é que, ao adicionar uma nova funcionalidade ou tentar resolver um problema, é mais intuitivo simplesmente substituir o que tinha antes pelo novo código gerado pela IA. Isto funciona até não funcionar; eventualmente, pode chegar a um ponto em que nada do que a IA produz está a ajudar e fica ainda pior do que estava antes.

É para isso que serve o controlo de versões

O controlo de versões como o Git surgiu como uma forma de os programadores colaborarem em projectos sem substituírem o trabalho uns dos outros. Mas mesmo que esteja a construir sozinho, serve como uma forma de fazer cópias de segurança do seu progresso, o que ajuda a isolar bugs e a poder reverter uma alteração quando algo corre mal. Aqui estão três práticas chave do Git que o ajudarão a construir com mais segurança:

Criar um ficheiro .gitignore para ficheiros sensíveis

Um ficheiro .gitignore é simplesmente um ficheiro de texto simples que diz ao Git o que deve ignorar (ou seja, não fazer commit no seu repositório). Normalmente, pretende que o Git ignore ficheiros gerados por computador, como logs, uma vez que estes desorganizam o seu repositório e podem conter informações sobre a aplicação que podem ser utilizadas para a comprometer. O seu ficheiro .env também deve ser ignorado, pois contém variáveis de ambiente sensíveis (como chaves de API e palavras-passe) que os hackers podem utilizar para se fazerem passar por si e obter acesso ao seu sistema. 

Manter um histórico de commits claro

Manter as alterações tão autónomas quanto possível torna mais fácil identificar quando um erro ou vulnerabilidade foi introduzido e mais fácil de reverter sem ter de refazer outro trabalho. Dar um passo em frente e configurar commits assinados verifica se os programadores certos estão a fazer commits de código no seu repositório (mesmo que seja apenas você!). 

Ramos separados de desenvolvimento, preparação e produção de funcionalidades

A ramificação no Git ajuda a criar espaços distintos e autónomos para trabalhar, pré-visualizar e lançar código. O desenvolvimento ativo de novos recursos em uma ramificação separada ajuda a evitar que códigos inacabados, com erros ou inseguros sejam acidentalmente confirmados no aplicativo ativo. Quando um novo recurso ou funcionalidade é totalmente desenvolvido e testado, um ramo de teste atua como outro portão de segurança e qualidade, permitindo que você revise e finalize as alterações antes de liberar para a produção. Somente os recursos totalmente testados e estáveis podem ser mesclados no ramo de produção (geralmente chamado de principal).

Repositórios Git alojados: GitHub GitLab   

Manter os segredos separados do código

‍

‍

Os segredos - tais como as suas palavras-passe, chaves de encriptação, tokens de API e certificados digitais - devem ser tratados separadamente do código para evitar que sejam comprometidos diretamente na sua base de código. Pode verificar se há segredos no seu código com o Aikido, mesmo a partir do IDE do Cursor.

Proteja a sua aplicação contra ataques DDoS

Um ataque de negação de serviço distribuído (DDoS) tenta interromper o tráfego normal de um servidor, serviço ou rede alvo, sobrecarregando o alvo ou a sua infraestrutura circundante com um pico de tráfego da Internet. Estes ataques podem ter consequências devastadoras e é surpreendentemente simples proteger-se integrando protecções DDoS básicas com uma rede de distribuição de conteúdos (CDN) como o CloudFlare ou o CloudFront. Alguns fornecedores de alojamento de domínios até oferecem uma CDN como um serviço integrado. 

Não fazer a autenticação sozinho

A autenticação (tal como o seu fluxo de início de sessão) é uma componente sensível da sua aplicação que deve ser deixada para os especialistas. A utilização de uma ferramenta dedicada para aplicar uma política de palavras-passe e oferecer facilmente um início de sessão único ou até mesmo uma autenticação multifactor para a sua aplicação à medida que aumenta a escala protegerá as suas contas de utilizador e a sua reputação. 

Ferramentas fantásticas: Auth0, Quasr 

Nunca faça a sua própria criptografia

Da mesma forma, a criptografia é uma especialidade, por isso confie sempre nos mecanismos, bibliotecas e ferramentas estabelecidos. Não construa suas próprias implementações ou use sinalizadores e opções que você não entende completamente,

expô-lo-á a grandes riscos. Bibliotecas como a NaCL expõem poucas opções, restringindo-o a boas escolhas.

‍

Nível 1

Configurar um pipeline de CI/CD para monitorizar o seu código

A implementação de um pipeline de CI/CD com testes é como adicionar pontos de controlo de qualidade à linha de montagem do código da sua aplicação. Pode integrar ferramentas de análise de código estático para efetuar o teste estático de segurança da aplicação (SAST), que analisa o seu código em busca de falhas que possam conduzir a vulnerabilidades de segurança. Também pode integrar uma ferramenta para Testes Dinâmicos de Segurança de Aplicações (DAST, por vezes designado por monitorização 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 sem restrições). 

DAST de fonte aberta: ZAP

Opensource SAST: Opengrep

Monitorizar as suas dependências  

Quer tenha consciência disso ou não, a maior parte do código que alimenta a sua aplicação é provavelmente retirado dos projectos de código aberto e das bibliotecas de terceiros em que os modelos de IA são treinados. Estas são as suas dependências e, por vezes, mesmo estas têm as suas próprias dependências - todas elas constituem a sua cadeia de fornecimento de software. Uma única falha em qualquer uma destas bibliotecas pode colocar toda a sua aplicação em risco, mas pode reduzir o risco utilizando as ferramentas certas para monitorizar as suas dependências para detetar vulnerabilidades conhecidas.

Ferramenta recomendada: Trivy

Configure-o em segundos com o Aikido

Verifique se as suas dependências têm malware

Da mesma forma, a sua cadeia de fornecimento pode incluir pacotes maliciosos contendo malware. Estes são excecionalmente perigosos, uma vez que os atacantes normalmente actuam rapidamente depois de terem conseguido introduzir malware no seu código. Por isso, também precisa de reagir rapidamente. Tenha em atenção que as bases de dados de Vulnerabilidades e Exposições Comuns (CVE) são demasiado lentas e não o manterão a salvo deste tipo de ataques.

Ferramentas: Aikido Intel

Configure-o em segundos com o Aikido

Utilize ficheiros de bloqueio para proteger a sua cadeia de abastecimento

Se não utilizar lockfiles, sempre que compilar a sua aplicação, irá obter as versões mais recentes de todos os pacotes de código aberto. Os lockfiles permitem compilações reproduzíveis ao puxar as mesmas versões das suas dependências de código aberto. Isto mantém a sua aplicação estável no caso de quaisquer alterações de rutura nas suas dependências, mas também protege a sua aplicação contra ataques à cadeia de fornecimento quando a última versão de uma dependência foi comprometida. Um exemplo recente disso é a vulnerabilidade tj-actions/changed-files de março de 2025: os invasores modificaram o código tj-actions/changed-files do GitHub Action, fazendo com que a ação comprometida imprimisse segredos de CI/CD nos logs de compilação do GitHub Actions.

Evitar ataques de scripting entre sítios com cabeçalhos CSP rigorosos

Os cabeçalhos CSP podem protegê-lo de ataques XSS comuns, fornecendo uma camada de segurança adicional que controla os recursos dinâmicos que podem ser carregados. Isto evita que os atacantes injectem scripts nas suas páginas Web.

Verificar se os preparou corretamente com o Aikido

Utilizar uma firewall de aplicação web

Utilize uma firewall de aplicação Web (WAF) ou a Auto-proteção de Aplicação em Tempo de Execução (RASP) para proteger os servidores virados para a Web contra ameaças desconhecidas de dia zero, incluindo injeção de SQL desconhecida ou ameaças XSS. A ferramenta analisa e impede pedidos de utilizadores com comportamento suspeito ou malicioso (como um payload de injeção), actuando como uma última linha de defesa contra ataques. 

Ferramentas fantásticas: AWS WAF Aikido Zen

‍

Nível 2

Com as medidas de segurança acima implementadas, é altura de melhorar a sua postura de segurança.

Implementar as melhores práticas para contentores

Os contentores empacotam software para que este possa ser executado de forma fiável quando transferido de um ambiente informático para outro. Eles agrupam uma aplicação com todas as suas dependências necessárias, tais como bibliotecas, estruturas e ficheiros de configuração (tudo na sua cadeia de fornecimento), num único pacote. Isto garante que a aplicação é executada de forma consistente, independentemente do ambiente em que é implementada. 

Se utilizar contentores para a implantação, existem algumas práticas recomendadas que ajudarão a proteger a sua aplicação.

Mantenha as suas imagens de base do Docker actualizadas 

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

Verificar a segurança do Docker utilizando: Syft Grype Trivy

Configure-o em segundos com o Aikido

Executar contentores Docker com privilégios restritos

Os privilégios limitados dificultam que os atacantes bem-sucedidos assumam o controlo do anfitrião ou se infiltrem noutros serviços. Evite executar contentores com funções de utilizador privilegiadas, como root em sistemas Unix, ou Administrador ou Sistema em sistemas Windows.

Proteja os seus segredos

Manter os segredos separados do código é um ótimo começo. Se estiver a utilizar contentores, também vai querer garantir que os seus ficheiros secretos e outros dados sensíveis estão adequadamente protegidos. Isso inclui o uso de ferramentas de gerenciamento de segredos (muitos provedores de nuvem oferecem as suas próprias), segredos do Kubernetes se estiver usando o Kubernetes, rotação de segredos regularmente e definição de datas de expiração nos seus segredos. 

Ferramentas de gestão de segredos: HashiCorp Vault Gestor de segredos AWS Gestor de segredos Google Cloud

Leia mais: Gerir Segredos em Contentores com Segurança: Melhores práticas e estratégias

Verifique se os seus pacotes estão no fim da vida útil (EOL)

À medida que os pacotes envelhecem e deixam de ser suportados, o risco de exploits aumenta. Deve certificar-se de que actualiza os pacotes que estão prestes a chegar ao fim da sua vida útil.

Ou configure-o em segundos com a funcionalidade de digitalização de contentores do Aikido

Implementar as melhores práticas para as suas contas na nuvem

Mantenha as contas de nuvem de desenvolvimento, preparação e produção separadas 

Assim como você deseja manter suas ramificações Git de desenvolvimento, preparação e produção separadas, o mesmo se aplica às suas contas na nuvem. Embora possa criar redes virtuais dentro das suas contas na nuvem para manter a preparação e a produção separadas, isto pode tornar-se complicado mais tarde à medida que cresce, uma vez que acabará por gerir continuamente os direitos de acesso do utilizador para os novos programadores. Recomendamos que mantenha as infra-estruturas de desenvolvimento, preparação e produção em contas de nuvem completamente separadas. Todos os fornecedores de serviços na nuvem oferecem faturação unificada, pelo que é menos uma dor de cabeça.

Utilizar ferramentas de gestão da postura na nuvem

Os fornecedores de serviços de computação em nuvem oferecem tantas funcionalidades que é fácil não ver ou configurar incorretamente algo que o coloca em risco. Utilize uma ferramenta de gestão da postura de segurança na nuvem (CSPM) para analisar a sua nuvem em busca de anomalias.

Ferramentas CSPM: Inspetor Cloudsploit AWS

Configure-o em segundos com o Aikido

Ativar alertas de orçamento da nuvem

No caso de a sua conta na nuvem ser pirateada, uma forma segura de detetar que alguém está a minerar Bitcoin na sua conta é ter alertas de orçamento configurados para monitorizar as despesas. O seu fornecedor de serviços na nuvem deve oferecer alertas integrados para este efeito, ou pode configurar a análise da nuvem com o Aikido para verificar se existem preocupações orçamentais e configurações incorrectas arriscadas. 

Verifique os LLMs para as explorações mais comuns

Para além de construir com LLMs, poderá estar a integrar LLMs no seu produto virado para o público. Poderá ter um chatbot que ofereça suporte aos utilizadores ou um assistente de IA que os ajude a integrar o produto. Se os seus clientes interagem com um LLM de qualquer forma, é uma boa ideia testá-los para as explorações mais comuns, de modo a não expor os clientes a riscos de segurança. 

Verificar os exploits mais comuns: OWASP Top 10 para LLMs

Para além

Implementar um ciclo de vida de desenvolvimento seguro

Uma grande parte da prática de segurança moderna está a mudar para a esquerda - trazendo as medidas de segurança para o ciclo de vida do desenvolvimento mais cedo. Isto ajuda-o a adquirir o hábito das boas práticas em todas as fases do projeto e a detetar os problemas mais cedo, antes de se tornarem uma ameaça real. Isso significa aderir a uma lista de verificação de segurança como esta, familiarizar-se com as falhas de segurança típicas e estar atento a elas durante a revisão do código, e implementar verificações de segurança também nos pull requests. 

Leia mais: OWASP Top Ten

Ler mais: Artigo da Wikipédia sobre o ciclo de vida do desenvolvimento de sistemas

Qualquer pessoa pode ser vítima de um ataque informático - mesmo as empresas multinacionais com departamentos de segurança dedicados continuam a ser vulneráveis a violações. Embora o código de vibração não seja seguro por defeito, se adotar as melhores práticas de segurança desde o início, ainda pode ceder totalmente às vibrações. O que quer que esteja a construir vale a pena o esforço. 

Ler mais

• Lista de verificação de segurança do CTO SaaS 2025 da Aikido
• O Guia de Código Aberto para Segurança de Aplicações de uma Startup

‍