Backdoor em app terceirizado: o código malicioso que eu só descobri quando contratei um dev
Em 2010 eu não tinha dev mobile e terceirizei o aplicativo de um cliente. A empresa parecia super profissional e o app rodou bem. Até eu contratar um dev, ele abrir o código-fonte e achar um backdoor mandando informação pra uma API do fornecedor. Aqui eu conto o caso e o que eu recomendo pôr no pipeline.
🎧 PREFERE OUVIR? · 7 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 7 minutos no canal @josimarjmv em 1º de junho de 2026, como alerta pra quem contrata terceirizado. Assista e leia junto. Aqui embaixo eu conto a mesma história por escrito, com mais calma, e ponho o que eu fui conferir depois.
quem terceiriza desenvolvimento precisa de alguém do próprio lado que leia o código entregue. Site bonito, dashboard com kanban e processo organizado não mostram o que está dentro do aplicativo. Em 2010 eu contratei uma empresa de fora pra fazer o app de um cliente, não vistoriei o código porque não sabia mobile, e só descobri o backdoor quando um dev meu abriu o source. A lição que eu tirei: exigir o código-fonte, vistoriar antes de publicar e colocar um estágio de checagem antes do build no CI/CD.
Pra quem é este alerta
É um alerta pra CEO e pra quem contrata terceirizado, inclusive em site de frila, como freelancer.com, upwork.com e outros. A gente recebe um enxame de e-mail de empresa oferecendo terceirização. E tem hora em que você quer mesmo terceirizar um serviço.
Vou dar minha carteirada antes. Meu nome é Josimar, eu sou CEO de uma empresa de tecnologia de verdade, de economia real. Não sou de marketing digital vendendo curso encapsulado. Eu tenho plataforma de vídeo, rastreamento veicular e outras coisas.
Eu sou engenheiro de infraestrutura. Sou técnico, CEO hands-on: boto a mão na massa. Entendo de infraestrutura, entendo de ASN, sou eu que faço configuração de anúncio, que monto e desmonto servidor dedicado. A gente tem data center em São Paulo, no mesmo ambiente do Facebook, e em Miami também.
Então você tem a garantia de que não vai perder o seu tempo com papagaio de pirata, com papagaio digital. O que vem abaixo aconteceu comigo.
2010: o cliente queria a rádio dele num aplicativo
Em 2009, acho que foi 2009, nós começamos a fornecer streaming de vídeo ao vivo pra emissoras de rádio. Em 2010 chegou um pedido: um cliente queria colocar a rádio dele, que já estava ao vivo no site, em um aplicativo móvel.
Eu não tinha dev mobile na época. Eu não fazia nem ideia de como se desenvolvia um aplicativo.
O que a gente faz nesse cenário? Larga o cliente na mão ou procura terceirização? Eu procurei terceirização. Eu jamais deixo um cliente na mão.
Por que eu não digo "não temos isso"
Nos meus negócios, mais de 70% dos recursos que a gente tem, eu acho que cerca de 80%, são ideia de cliente. O cliente dá a ideia, a gente vê se é válida, pesquisa se outros clientes vão querer, desenvolve pra ele usar e divulga pros outros usarem também.
A gente é o que eu chamo de empresa parceira. Não é produto de prateleira. Tem muita empresa que faz o software dela e, se ele não estiver adequado, vai ficar sem adequação mesmo, e perde o cliente. Eu acredito muito em parceria, e sempre desenvolvi os recursos pros meus clientes.
Foi por isso que eu fui atrás de alguém pra fazer o aplicativo, em vez de recusar o pedido.
A terceirização que parecia profissional
Fizemos várias cotações. Sem qualquer julgamento de valor: eu não lembro qual foi o meu critério, e possivelmente preço foi um deles. Cheguei em empresas de Macau e cheguei numa empresa indiana.
Era uma empresa, na época, bonitinha. Olha o que eu enxerguei de fora:
- tinha página no Facebook;
- tinha site;
- tinha um pipeline certinho;
- me dava acesso a uma dashboard com kanban, onde eu via por onde andava o projeto e o status de cada coisa.
Eu achei super profissional. Achei muito bacana.
E o processo foi bem feitinho. A gente fez o desenho, o esboço de baixa fidelidade. Depois o esboço de alta fidelidade. Definimos as funções de back-end e de front que o aplicativo ia ter. Aí foi pro desenvolvimento.
Pra variar, entregaram atrasado. Acontece, a gente sabe como é entrega de software. Me entregaram um pouco atrasado. Um poucão atrasado. Mas entregaram. Sobre atraso de entrega eu tenho outro texto: SaaS ou software house? O atraso na entrega que custou R$ 263 mil.
Começamos a rodar o aplicativo. Ele rodava relativamente bem, e era algo inovador no mercado brasileiro na época.
O susto do dev quando abriu o código-fonte
Aí a gente precisou começar a desenvolver recurso próprio. Contratamos um dev que fazia mobile, iOS e Android.
Eu lembro do susto dele. Na hora em que ele abriu o código-fonte do aplicativo, e a gente tinha o source, estava lá: um backdoorzão gigante, mandando informação estatística pra uma API dos caras da Índia.
Você acredita num negócio desses?
Eu não tinha vistoriado o código. Eu não tinha habilidade técnica pra isso na época. Mobile, pra mim, era um bicho de sete cabeças. Só depois é que eu fui aprender.
O que isso ensina pra quem terceiriza
O amigo que for terceirizar, o empresário, o CEO, o CTO, até o vibe coder que às vezes terceiriza alguma coisa pra outro lugar: muito cuidado.
Repara no que me enganou. Não foi um site mal feito nem um fornecedor amador. Foi exatamente o contrário: Facebook, site, pipeline, dashboard, processo de esboço. Tudo o que eu conseguia avaliar estava certo. O que eu não conseguia avaliar era o código, e era lá que estava o problema.
E repara no que permitiu achar: a gente tinha o source. Se eu tivesse recebido só o aplicativo publicado, o dev não teria o que abrir.
O que eu fui conferir: a OWASP descreve esse risco em app móvel
Depois da gravação eu fui ver se isso que aconteceu comigo tem nome. Tem. Na lista de riscos de aplicativo móvel da OWASP, o item M2, segurança inadequada da cadeia de suprimentos, descreve o atacante que insere código malicioso na base do aplicativo, ou modifica o código durante o build, pra introduzir backdoor, spyware ou outro código malicioso. Li a página em 12 de outubro de 2026.
Duas coisas ali batem com a minha história. A primeira: o texto cita o agente interno, alguém de dentro do desenvolvimento, injetando código malicioso nessa fase. A segunda: a OWASP classifica a detecção desse tipo de falha como difícil. E a primeira medida de prevenção da lista é prática de código seguro, revisão de código e teste durante todo o ciclo de desenvolvimento. A tradução é minha.
Ou seja, o que o meu dev fez quando abriu o código pra começar a trabalhar é o que devia ter sido feito de propósito, antes de publicar.
A era do vibe coder é a era das invasões
A gente está na era das invasões digitais. Tem vazamento do GitHub, tem infecção do repositório npm. A segurança vai ser muito crítica. A gente está entrando numa era nunca antes vista na história da internet em matéria de segurança, invasão e ataque.
Por quê? Porque ficou muito fácil pra qualquer pessoa. Da mesma maneira que ficou fácil pra quem é do bem ganhar dinheiro. A melhor era pra empreender é hoje. Hoje é a melhor data pra empreender da história da humanidade, principalmente pra dev.
Só que está fácil pra todo mundo. Está fácil pra medicina, está fácil pra gente boa e está fácil pra gente ruim. Está fácil pra quem desenvolve e está fácil pra hacker. A arma é usada por policial e é usada por bandido. O equipamento está aí, depende do uso que vai ter.
O meu exemplo é real e aconteceu em 2010. Eu trouxe pra hoje porque, de lá pra cá, esse tipo de coisa acontece todos os dias.
O que eu fui conferir: o caso do npm contado pelo próprio GitHub
Fui buscar um caso documentado de infecção no npm, direto na fonte. O GitHub, que é o dono do npm, publicou em 22 de setembro de 2025 o texto Our plan for a more secure npm supply chain. Lá ele conta que foi notificado, em 14 de setembro de 2025, do ataque Shai-Hulud: um worm que se replicava sozinho e entrou no ecossistema por contas de mantenedores comprometidas, injetando script malicioso de pós-instalação em pacotes populares de JavaScript.
Segundo o mesmo texto, o GitHub removeu mais de 500 pacotes comprometidos do registro. Li em 12 de outubro de 2026, e a tradução é minha.
Em 2010 eu precisei contratar uma empresa pra receber código malicioso. Hoje ele pode chegar numa biblioteca conhecida, que você instala sem ler. Eu mantenho o meu código dentro de casa, e os motivos estão em por que eu não uso GitHub, Supabase ou Firebase em produção.
O que eu recomendo: vistoria no código e um estágio antes do build
Vamos ter cuidado. Vamos vistoriar os nossos códigos. Vamos colocar auditoria nos nossos pipelines.
Antes de rodar o CI/CD, bota um estágio ali pra checar se tem vírus no build. Tem como colocar isso no seu Actions, no seu CI do GitLab: uma checagem de vírus antes de rodar. E dá pra usar os repositórios que já são públicos e divulgam as libs infectadas.
Pode ser um hook. Pode ser simplesmente um estágio novo de checagem antes do build.
Vamos ter essa política, essa prática de segurança. Isso vai salvar muitas cabeças e poupar muito dinheiro. Além do estresse e da dor de cabeça. Como diz a Mastercard, tem coisa que não tem preço, e o estresse de um negócio fora do ar ou infectado é uma delas.
O que eu fui conferir: o que cada checagem pega
Fui ler a documentação das ferramentas que servem pra esse estágio, em 12 de outubro de 2026, pra não te indicar nada de orelhada. A tabela é leitura minha dos documentos.
| Checagem | O que a documentação diz que ela faz | O que ela não vê |
|---|---|---|
| Alguém da casa lendo o código entregue | É a revisão de código que a OWASP põe em primeiro lugar na prevenção do item M2. | Depende de ter gente que saiba ler aquela stack. Era o que me faltava em 2010. |
npm audit | Manda a descrição das suas dependências pro registro e pede o relatório de vulnerabilidades conhecidas. Sai com código diferente de zero se achar alguma, e o parâmetro --audit-level define a partir de qual gravidade o comando falha no CI. | Código que você mesmo, ou o seu fornecedor, escreveu. |
| Dependency scanning do GitLab | Identifica vulnerabilidade conhecida nas dependências, inclusive as aninhadas, e compara com os avisos de malware do próprio GitLab. A página marca o recurso como do plano Ultimate. | O mesmo: ele olha dependência, não a regra de negócio do seu app. |
| Antivírus no build (ClamAV) | O clamscan varre arquivos e diretórios pela linha de comando, procurando o que a base de assinaturas dele conhece. | Código malicioso feito sob medida, que não está em base nenhuma. |
As fontes: a documentação do npm audit, a página de dependency scanning do GitLab e o manual de varredura do ClamAV.
Na prática, pra um projeto em Node, o estágio mínimo é uma linha: um job que roda npm audit --audit-level=high num estágio anterior ao do build. Se a auditoria achar vulnerabilidade de gravidade alta pra cima, o comando falha, e o build nem começa. Esse exemplo eu tirei da documentação do npm. Não é cópia do meu pipeline.
Agora o ponto que eu faço questão de deixar claro: nenhuma dessas checagens automáticas teria pego o meu backdoor de 2010. Aquilo não era vírus conhecido nem biblioteca infectada. Era código escrito pelo próprio fornecedor, chamando a API dele. Isso quem pega é gente lendo o código. Por isso eu falo das duas coisas juntas: vistoriar e auditar.
Sobre pipeline com vários estágios de checagem, eu conto como é o meu em GitHub vai virar gargalo: o que eu aprendi cercando agentes de IA com um CI de 14 estágios.
A lista que eu tiro desse caso antes de terceirizar
Juntando o que eu vivi em 2010 com o que eu conferi agora, esta é a lista que eu tiro pra quem vai contratar de fora:
- Exigir o código-fonte. Foi ter o source que permitiu achar o backdoor.
- Ter alguém do seu lado que leia o que foi entregue. Em 2010 eu não tinha, e o código rodou sem vistoria.
- Vistoriar antes de publicar, não depois, quando o aplicativo já está na mão do usuário.
- Não confundir processo bonito com código limpo. Dashboard com kanban mostra o status do projeto, não o que o código faz.
- Colocar o estágio de checagem antes do build, pra pegar pelo menos o que já é conhecido.
E pra você, vibe coder: a IA também é uma forma de terceirizar. Tem mais desse cuidado em o que todo vibe coder descobre tarde demais ao subir pra produção e em meu WordPress foi hackeado três vezes, que é outra vez em que eu aprendi segurança apanhando.
Segurança não é brincadeira. Espero que isso faça sentido pra você.
Nota de cronologia
Gravei em 1º de junho de 2026 e este texto saiu em 12 de outubro de 2026. O caso é de 2010 e eu contei de cabeça: o ano em que a gente começou com streaming pra rádio é "acho que 2009", e eu não lembro o critério que me levou àquela empresa. Na gravação eu falei em informação estatística saindo pra API do fornecedor, e é só isso que eu afirmo aqui. Não detalhei quais dados eram nem o que aconteceu com o fornecedor depois, então não ponho.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
O que é um backdoor em um aplicativo terceirizado?
É um trecho de código que faz uma coisa que você não pediu e não sabe que existe. No meu caso, o aplicativo que eu mandei fazer fora funcionava direitinho, e por dentro mandava informação estatística pra uma API do próprio fornecedor. Eu só fiquei sabendo quando um dev meu abriu o código-fonte.
Como eu descobri o backdoor no app?
Eu não descobri sozinho. Na época eu não tinha habilidade técnica em mobile e não tinha vistoriado o código. Quando a gente precisou desenvolver recurso próprio, contratei um dev que fazia iOS e Android. Ele abriu o source do aplicativo e levou um susto: tinha um backdoor gigante ali dentro.
Empresa que parece profissional pode entregar código malicioso?
Pode. A empresa que eu contratei tinha site, página no Facebook, pipeline organizado e uma dashboard com kanban onde eu acompanhava o status do projeto. O processo foi bem feito, com esboço de baixa e de alta fidelidade antes do desenvolvimento. Nada disso me mostrou o que estava dentro do código.
Preciso ter um dev interno pra terceirizar desenvolvimento?
Você precisa de alguém do seu lado que consiga ler o que foi entregue. Eu não tinha, e o backdoor ficou rodando até eu contratar um dev mobile. Se você não lê código, ponha alguém de confiança pra vistoriar antes de publicar, e exija o código-fonte. Eu tinha o source, e foi isso que permitiu achar o problema.
Dá pra checar vírus e biblioteca infectada no CI/CD?
Dá. Você coloca um estágio de checagem antes do build, no GitHub Actions ou no CI do GitLab, ou um hook. Esse estágio confere as suas dependências contra as bases públicas que divulgam biblioteca infectada e vulnerável, e pode passar um antivírus no que foi gerado. Se a checagem reprovar, o build não roda.
Antivírus no pipeline pega um backdoor feito pelo fornecedor?
Não conte com isso. Pelo que eu conferi na documentação, essas ferramentas comparam o seu projeto com o que já é conhecido: vulnerabilidade divulgada, pacote marcado como malware, assinatura de vírus. Uma chamada que o próprio fornecedor escreveu pra API dele não está em base nenhuma. Isso quem pega é gente lendo o código, e por isso eu falo em vistoriar e em auditar, as duas coisas.
Quem programa com IA corre o mesmo risco?
Corre. O vibe coder também terceiriza: pra outra pessoa, pra uma biblioteca pública, pra própria IA. A gente está numa era em que ficou fácil pra quem é do bem ganhar dinheiro e ficou fácil pra hacker também. Se você não vistoria o que entra no seu projeto, você está na mesma posição em que eu estava em 2010.
Baseado na gravação do canal @josimarjmv publicada em 01/06/2026 (7min07s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: o alerta pra CEO e pra quem contrata terceirizado e frila (freelancer.com, upwork.com); o enxame de e-mail oferecendo terceirização; a carteirada (empresa de tecnologia de economia real, plataforma de vídeo e rastreamento veicular, engenheiro de infraestrutura, CEO hands-on, ASN, servidor dedicado, data center em São Paulo e em Miami); o streaming ao vivo pra emissoras de rádio desde 2009, dito como "acho que 2009"; o pedido do cliente em 2010 pra pôr a rádio num aplicativo móvel; eu sem dev mobile e sem saber como se fazia aplicativo; a decisão de terceirizar pra não largar o cliente; os mais de 70%, cerca de 80%, dos recursos que nascem de ideia de cliente; empresa parceira contra produto de prateleira; as cotações, as empresas de Macau e a empresa indiana; a página no Facebook, o site, o pipeline e a dashboard com kanban; o esboço de baixa e de alta fidelidade e a definição de back-end e front; a entrega atrasada; o aplicativo rodando relativamente bem e inovador no mercado brasileiro da época; a contratação do dev de iOS e Android; o susto dele ao abrir o código-fonte e o backdoor mandando informação estatística pra uma API do fornecedor; eu não ter vistoriado o código por falta de habilidade técnica em mobile; o aviso pra empresário, CEO, CTO e vibe coder; a era das invasões, o vazamento do GitHub e a infecção do repositório npm; a melhor era pra empreender e a comparação com a arma; o estágio de checagem de vírus antes do build, no Actions ou no CI do GitLab, por hook ou estágio novo, usando os repositórios públicos que divulgam libs infectadas; a frase da Mastercard. Tudo dito de cabeça, direto.
Apuração minha (12/10/2026): a descrição do risco de código malicioso e backdoor inserido no desenvolvimento ou no build de aplicativo móvel, a detecção classificada como difícil e a revisão de código como prevenção estão no item M2: Inadequate Supply Chain Security, do OWASP Mobile Top 10. A notificação do ataque Shai-Hulud em 14/09/2025 e a remoção de mais de 500 pacotes comprometidos estão em Our plan for a more secure npm supply chain, do GitHub, de 22/09/2025. O comportamento do comando e do parâmetro --audit-level está na documentação do npm audit. O alcance do dependency scanning, a comparação com avisos de malware e o plano Ultimate estão na documentação do GitLab. A varredura por linha de comando com clamscan está no manual do ClamAV. As traduções são minhas. O exemplo do estágio com npm audit --audit-level=high foi tirado por mim dessa documentação. A lista de cinco itens e a afirmação de que checagem automática não pegaria o backdoor de 2010 são leitura minha, feita depois da gravação. Na gravação eu não disse qual vazamento do GitHub nem qual infecção do npm eu tinha em mente; o Shai-Hulud entra aqui como um caso documentado, não como o caso citado.