Ataques ao Pix: R$ 15 mil de um lado, R$ 800 milhões do outro

Dois anos, mais de R$ 2 bilhões e nenhum zero-day. Como o crime recruta, planeja e executa, o que o Bacen passou a exigir — e onde o seu código decide o tamanho do rombo.

Leitura densa (~30 min) · Para quem escreve código que move dinheiro

Você tem gateway, rate limit, mTLS e motor antifraude — e ainda assim a distância entre uma credencial vendida num bar e as contas reserva do Banco Central é feita de decisões que passaram pelo seu pull request. Sete tópicos sobre como o ataque funciona de verdade.

Março de 2025. Um homem sai de um bar no Jaraguá, zona norte de São Paulo. Alguém o aborda na rua e faz uma pergunta simples: “você trabalha no TI?”

Ele trabalhava. Era programador júnior terceirizado numa empresa que a maioria dos brasileiros nunca ouviu falar, mas por onde passavam ordens de pagamento de seis instituições financeiras. A oferta inicial foi de R$ 5 mil, entregues em dinheiro por um motoboy. Depois vieram mais R$ 10 mil, e com eles a tarefa de inserir comandos nos sistemas da empresa a mando de gente que ele nunca viu pessoalmente. Ele passou a trocar de chip e de aparelho a cada 15 dias.

Na madrugada de 30 de junho para 1º de julho de 2025, por volta das 4h da manhã, essas credenciais entraram no sistema. Durante aproximadamente três horas, transferências saíram das contas reserva mantidas no Banco Central¹. O prejuízo estimado ficou entre R$ 800 milhões e R$ 1 bilhão. Uma parte virou criptoativo antes que alguém percebesse. E quem percebeu, aliás, não foi a empresa atacada nem a vítima direta: foi uma terceira instituição que estranhou o fluxo e ligou avisando.

Não houve zero-day. Não houve estouro de buffer, injeção de SQL, desserialização insegura, nada que caiba num relatório de pentest. Houve uma credencial legítima usada dentro do horário e do protocolo. A própria empresa afirmou, em nota, que “não houve invasão direta aos sistemas”. Tecnicamente correto. E é exatamente por isso que essa frase é a mais perigosa do setor.

Este artigo é uma tentativa de responder, com honestidade técnica, três perguntas que quase nunca aparecem juntas: como o crime pensa, onde a engenharia falha e o que a regulação passou a cobrar de nós, programadores — não do CISO, não do jurídico, de nós. Porque em todos os casos dos últimos dois anos, quando você desce a pilha o suficiente, encontra uma decisão de design.

O que vem por aí

• O inimigo tem crachá. Anatomia do vetor interno: C&M, Sinqia e o padrão do “não invadiram, logaram”.

• De fora para dentro. Como criminosos selecionam alvo, planejam, executam e sacam — inclusive no celular do seu cliente.

• Onde o código falha. APIs, autenticação, autorização, segredos, assinatura e limites: a parte que é culpa nossa.

• O que o Bacen exige. Do discurso de política à evidência auditável: PSTI, 14 controles mínimos, MFA, isolamento, pentest.

• SSDLC. Onde a norma vira código, teste, pipeline e pull request.

• Como o ataque funciona na prática. RCE, deserialização, SSRF, a mentira do “estou seguro na minha linguagem” e o mito do Kali Linux. Para arquitetos e programadores.

• As próximas brechas. Pix Automático, aproximação offline, parcelado, garantia, internacional, split: cada funcionalidade é uma superfície nova.

Tópico 01: O inimigo tem crachá: anatomia do vetor interno

Vamos começar pelo desconfortável. Os dois maiores ataques ao ecossistema Pix não foram invasões no sentido hollywoodiano. Foram abusos de acesso legítimo.

Caso 1 — C&M Software (julho de 2025)

A C&M é um PSTI: um provedor de tecnologia que funcionava como ponte entre instituições financeiras e o Sistema de Pagamentos Brasileiro, incluindo o ambiente do Pix. Instituições que não têm conexão própria com as infraestruturas do Banco Central contratam alguém assim. É infraestrutura crítica com aparência de fornecedor de TI.

O alvo não foram as contas correntes dos clientes finais. Foram as contas reserva das instituições no Banco Central — o dinheiro institucional, não o do correntista. A BMP sozinha reportou prejuízo de R$ 541 milhões. Credsystem e Banco Paulista também foram atingidos. O Banco Central determinou o desligamento do acesso das instituições às infraestruturas operadas pela C&M.

Meses depois, um grupo criminoso publicou na dark web cerca de 392 GB de dados supostamente obtidos da empresa. A Polícia Federal, segundo seu diretor-geral, mapeou a cadeia criminosa, prendeu 25 pessoas e recuperou mais de R$ 500 milhões.

Repare no custo do ataque para o crime: R$ 15 mil.

Caso 2 — Sinqia / Evertec (agosto de 2025)

Menos de dois meses depois, a mesma classe de vetor. A Sinqia — provedora de tecnologia comprada pela porto-riquenha Evertec — detectou atividade não autorizada no seu ambiente Pix em 29 de agosto. Resultado: R$ 710 milhões em transações B2B não autorizadas, sendo cerca de R$ 669 milhões do HSBC e R$ 41 milhões da SCD Artta. O Banco Central conseguiu bloquear a maior parte — algo em torno de R$ 589 milhões.

O relatório enviado pela Evertec à SEC americana traz a linha que interessa a nós: os resultados preliminares da forense indicaram acesso por meio de credenciais legítimas comprometidas de fornecedores de TI da Sinqia. A empresa informou que “já encerrou o acesso” dessas contas. Depois. Sempre depois.

E não parou aí

Em janeiro de 2026, o Banco do Nordeste suspendeu o Pix após um incidente originado em prestador de serviço de tecnologia, envolvendo uma conta bolsão de empresa terceirizada. O impacto apareceu no balanço do 1º trimestre como item não recorrente: R$ 146,6 milhões. A FictorPay teve recursos desviados após a invasão da Diletta, empresa que desenvolvia seu aplicativo e a camada de comunicação com a instituição autorizada a operar o Pix em seu nome. Em março de 2026, o BTG identificou atividade suspeita e suspendeu operações preventivamente.

O padrão é tão consistente que dá para escrever como uma assinatura:

// Assinatura comum dos incidentes de 2025–2026
alvo        : elo de infraestrutura, não o banco
acesso      : credencial válida (interna, terceirizada ou de fornecedor)
técnica     : uso legítimo de função legítima
janela      : madrugada / fim de semana / baixa observabilidade
alvo do $   : conta reserva ou conta bolsão, não conta de cliente
detecção    : por terceiro, por conciliação, ou tarde demais
saída       : pulverização → contas de passagem → cripto/OTC → fachada

O que ninguém quer admitir

“Não houve invasão direta aos sistemas” é uma frase de defesa jurídica, não de engenharia. Do ponto de vista do sistema, não existe diferença entre uma credencial roubada e uma credencial vendida. As duas produzem requisições perfeitamente válidas. Se a sua arquitetura só sabe se defender de requisições inválidas, ela não sabe se defender.

Existe uma expressão que descreve bem o fenômeno: insider as a service. O crime organizado descobriu que comprar um humano com acesso é ordens de grandeza mais barato, mais rápido e mais confiável do que financiar pesquisa de vulnerabilidade. E ele não precisa comprar um arquiteto sênior. Basta comprar alguém cujo perfil de acesso foi definido por conveniência operacional, e não por necessidade — o que, sejamos honestos, descreve boa parte dos acessos que existem na sua empresa agora.

Aqui é onde a engenharia entra. Uma credencial vendida só vale R$ 800 milhões se, do outro lado dela, existir um caminho em que um único ator consegue originar, aprovar e liquidar uma ordem de pagamento de altíssimo valor, fora de horário, para um destino nunca visto, sem que nada dispare. Cada “e” dessa frase é um controle que faltou. Cada controle que faltou é uma decisão de design que alguém tomou — ou deixou de tomar — num refinamento de sprint.

Pense comigo

Quantas pessoas na sua empresa conseguem, sozinhas, com uma única credencial, fazer o sistema emitir uma mensagem de pagamento válida para o SPI? Não a resposta da política. A resposta real, incluindo terceirizados, contas de serviço herdadas, o acesso de emergência que ninguém revogou e o script que roda com a credencial de alguém que saiu em 2023.

Se você não consegue produzir essa lista em cinco minutos, o atacante vai produzir por você.

Tópico 02: De fora para dentro: como o crime pensa, planeja e executa

Para defender bem, é preciso parar de imaginar o atacante como um gênio de capuz e começar a enxergá-lo como uma operação com orçamento, prazo, divisão de trabalho e análise de retorno. O que descrevo abaixo é a estrutura recorrente nas investigações públicas dos últimos dois anos.

Fase 1 — Seleção do alvo: procurar o elo, não o cofre

Nenhum grupo racional ataca o Itaú de frente. Ele ataca quem se conecta ao Itaú. A lógica é de custo: o banco grande tem SOC 24×7, red team, orçamento de nove dígitos; o fornecedor que faz a ponte tem uma equipe enxuta, um contrato apertado… mas acesso privilegiado. Como resumiu um advogado que acompanhou o caso C&M, o ataque expôs que a empresa prestava serviço de tecnologia a instituições financeiras sem ser ela própria regulada, o que permitiu a um elo não supervisionado comprometer contas reserva de várias instituições ao mesmo tempo.

O número que sustenta essa escolha é constrangedor: entre 606 instituições avaliadas pelo Banco Central, apenas 37,3% faziam avaliação periódica de risco dos seus prestadores de serviço, e menos da metade mantinha inventário atualizado de fornecedores. O criminoso não precisa de sorte para achar um elo fraco. Ele precisa de paciência para escolher qual.

Fase 2 — Reconhecimento: OSINT é barato e legal

Antes de qualquer acesso, vem o mapeamento. E ele é feito, em boa medida, com informação que nós mesmos publicamos:

• Vagas de emprego. “Vaga para pessoa desenvolvedora Java/Spring com experiência em SPI, ISO 20022 e integração com Bacen.” Você acabou de entregar a stack, o domínio e a superfície.

• LinkedIn. Quem é o time, quem é júnior, quem é terceiro, quem acabou de entrar (e ainda não sabe o que é estranho), quem está insatisfeito.

• Repositórios e pacotes públicos. Nomes internos de serviços, endpoints, formatos de payload, ocasionalmente um segredo esquecido no histórico do Git.

• Marketplaces de credenciais. Logs de infostealer vendidos aos milhares, com sessões de VPN, cookies e senhas corporativas. Não é ficção: o Banco Central passou a exigir formalmente ações de inteligência cibernética com monitoramento de credenciais e chaves na internet, deep e dark web — justamente porque é ali que a sua senha aparece antes de aparecer no seu SIEM.

• Documentação pública do Pix. As especificações do Bacen são abertas, e isso é bom. Mas significa que o atacante conhece o protocolo tão bem quanto você. A vantagem competitiva dele é conhecer o seu desvio em relação ao protocolo.

Fase 3 — Acesso inicial: quatro portas, todas legítimas

Nos casos recentes, o acesso inicial veio por uma destas rotas:

1. Recrutamento humano. Abordagem direta, valor baixo, alvo de baixa senioridade e alto acesso. O caso C&M é o manual.

2. Credencial de fornecedor comprometida. O caso Sinqia. Você endureceu a sua autenticação; a do seu fornecedor de banco de dados, não.

3. Comprometimento do desenvolvedor do aplicativo. O caso FictorPay/Diletta: quem escreveu a camada de integração vira o ponto de entrada.

4. Conta de serviço e integração esquecida. O acesso que ninguém revogou porque ninguém sabia que existia.

Fase 4 — Aprender o negócio, não o sistema

Este é o ponto que mais me impressiona e o que mais deveria nos assustar. No caso C&M, o funcionário confessou que vinha inserindo comandos desde maio — o ataque só aconteceu no fim de junho. Semanas de permanência silenciosa.

Por quê? Porque o atacante não estava quebrando nada. Ele estava aprendendo o fluxo: qual conta tem saldo, em que horário a conciliação roda, qual valor não dispara alarme, quanto tempo demora até alguém olhar, qual mensagem o SPI aceita sem devolver erro. É reconhecimento de domínio, não de infraestrutura.

A assimetria que define tudo

O atacante não precisa entender o seu domínio inteiro. Ele precisa entender um fluxo melhor do que você entende. E ele tem uma vantagem estrutural: enquanto o seu time divide atenção entre roadmap, incidente de produção, refinamento e a migração daquele legado, ele passa semanas olhando para um único caminho feliz procurando o que acontece quando ele é seguido de um jeito não previsto.

Fase 5 — Execução: a janela

4h da manhã de uma segunda-feira. Três horas de operação. Não é coincidência: é escolha de janela de baixa observabilidade humana. E aqui mora a característica que torna o Pix estruturalmente diferente de qualquer meio de pagamento anterior — a liquidação é final e irreversível em segundos, 24×7. No cartão existe chargeback, no boleto existe compensação, no TED existe horário. No Pix, quando a mensagem é liquidada, o dinheiro é do outro lado.

Isso muda a matemática da defesa de uma forma que muita gente ainda não internalizou: qualquer controle antifraude que rode em lote, no dia seguinte, é arqueologia. Ele documenta o crime; não o impede. O tempo de decisão precisa ser da ordem da própria transação. E, aqui, veja o detalhe cruel do caso C&M apontado pelos especialistas: as instituições identificaram as movimentações fraudulentas quando os recursos já estavam em fase de conversão para criptoativos.

Fase 6 — Saída: o problema mais difícil do crime

Roubar é fácil; sacar é caro. A cadeia de saída usa pulverização em muitas contas, contas de passagem, contas bolsão (que agregam recursos de vários usuários sem identificação individualizada — instrumento historicamente explorado para lavagem), empresas de fachada e conversão em criptoativos. Na Operação Cofre Digital, que desmontou o grupo do caso Sinqia, o Ministério Público de São Paulo e a Polícia Federal descreveram exatamente isso: empresas de fachada convertendo o valor roubado em cripto para simular origem legítima.

É por isso que boa parte da resposta regulatória recente mira o cash-out, e não só o acesso: bloqueio de chaves Pix ligadas a fraudes, rejeição obrigatória de pagamentos destinados a contas usadas em fraude, encerramento compulsório de contas usadas para movimentar recursos de terceiros, regulação das prestadoras de serviços de ativos virtuais. Se você seca o ralo, o roubo perde o sentido econômico.

O outro “de fora para dentro”: o celular do seu cliente

Tudo o que descrevi até aqui é o ataque à infraestrutura. Existe um segundo front, muito maior em volume e muito menor em ticket: a fraude no endpoint do usuário.

O Brasil desenvolveu uma indústria própria de trojans bancários voltados ao Pix. O PixPirate, documentado pela Cleafy e depois pela IBM Trusteer, pertence a uma geração de malware Android capaz de ATS — Automatic Transfer System: ele automatiza a inserção de uma transferência Pix maliciosa a partir do próprio aparelho da vítima. Abusa do serviço de acessibilidade para ganhar capacidade de RAT, monitora a atividade, rouba credenciais e — o detalhe que quebra a premissa de meio mundo — acessa, edita e apaga as mensagens SMS, inclusive as do banco, quando o segundo fator é necessário. E aprendeu a esconder o próprio ícone de um jeito novo depois que o Android 10 fechou a técnica antiga.

Do lado do desktop, o GoPix abusa de um recurso legítimo do navegador para substituir chave Pix, código de boleto ou endereço de carteira no momento da transação, com certificados forjados exibindo o cadeado de conexão segura.

A escala: entre janeiro e setembro de 2025, o Brasil registrou 28 milhões de fraudes envolvendo o Pix, segundo levantamento da ADDP. Relatório da ACI Worldwide com a GlobalData projeta perdas com golpes do Pix chegando a R$ 11 bilhões até 2028. E o Banco Central reportou crescimento de 183% nos ataques cibernéticos em dois anos, com incidentes subindo cerca de 29% entre 2024 e 2025.

A conclusão incômoda do tópico

Fraude de infraestrutura e fraude de endpoint parecem problemas de times diferentes. Não são. As duas exploram a mesma coisa: a transação chega ao seu backend perfeitamente bem formada. Assinada, autenticada, dentro do esquema. Se a sua única linha de defesa é validar a forma da requisição, você já perdeu nos dois cenários. O que separa é a capacidade de julgar comportamento, e comportamento é código que alguém precisa escrever.

Pense comigo

Se um ator com acesso legítimo de um dos seus serviços operasse por três horas às 4h de um domingo, qual seria o teto de dano? Some limites por transação, por conta, por janela, por contraparte, por destino novo. Se você não conseguir chegar a um número, é porque o teto é o saldo.

E a segunda parte da pergunta, mais dura: quem seria acordado, em quantos minutos, por qual alerta — e esse alerta já disparou alguma vez em simulação?

Tópico 03: Onde o código falha: APIs, autenticação, autorização e segredos

Chegamos à parte que é nossa. Não do compliance, não do jurídico: nossa, de quem abre o editor e escreve o método. Vou listar os padrões de falha que, na minha experiência com integrações de core banking e Pix, aparecem com mais frequência — e que explicam tecnicamente como “credencial legítima” vira “R$ 800 milhões”.

1. Autenticar não é autorizar

É a falha número um do OWASP API Security Top 10 (Broken Object Level Authorization) e a número cinco (Broken Function Level Authorization), e continua sendo a campeã em revisão de código no setor financeiro. O serviço valida o token com rigor, confirma assinatura, expiração, emissor — e então usa o identificador de conta que veio no corpo da requisição.

// O padrão que mata
@PostMapping(”/pagamentos”)
ResponseEntity<Void> pagar(@AuthenticationPrincipal Cliente c,
                           @RequestBody OrdemPix ordem) {
    // token válido ✔  cliente autenticado ✔
    // e a conta de origem? veio do payload. de quem?
    pixService.iniciar(ordem);
}

A pergunta que precisa ser feita em toda revisão de PR de endpoint monetário: quem provou que a conta de origem pertence ao principal autenticado? Se a resposta é “o front-end só manda a conta certa”, você tem um controle de segurança implementado em JavaScript rodando no dispositivo do atacante.

A variação institucional do mesmo erro é pior: o serviço de integração aceita o ISPB de origem no payload e não valida contra a identidade do certificado ou do canal mTLS que originou a chamada. Ou seja: um participante consegue emitir em nome de outro.

2. Confiança implícita dentro do perímetro

“Está dentro da VPC², é confiável.” Essa frase construiu a maior parte das arquiteturas de microsserviços que existem hoje em bancos brasileiros, e é exatamente a premissa que o vetor interno destrói. Se o atacante entra com credencial legítima, ele já está dentro da VPC. Toda chamada serviço-a-serviço sem autenticação mútua, sem identidade de carga de trabalho e sem autorização própria é um degrau grátis.

Não à toa, a nova regulação passou a exigir isolamento físico e lógico dos ambientes Pix e STR dos demais sistemas, com instâncias dedicadas e apartadas em nuvem. Traduzindo para arquitetura: o ambiente que fala com o SPI não compartilha rede, credencial, plano de controle nem imagem base com o resto da casa. E, sim, isso quebra a sua conveniência de deploy.

3. Segredos: a chave privada é o sistema

Num arranjo em que mensagens são assinadas digitalmente, quem controla a chave de assinatura controla o dinheiro. Perguntas que doem:

• A chave privada de assinatura de mensagens do SPI está em HSM³ — o hardware dedicado que assina sem nunca deixar a chave sair de dentro dele— ou num arquivo .p12 num volume montado?

• Quantos humanos conseguem extrair essa chave? E quantos fornecedores?

• Existe rotação automatizada de certificados, ou o processo é “abre um chamado 30 dias antes do vencimento”?

• Se um certificado precisar ser revogado às 4h da manhã, quanto tempo leva? Minutos ou o próximo dia útil?

A resolução mais recente do CMN foi cirúrgica aqui: monitoramento de credenciais e certificados digitais, especialmente no SPI/Pix, com vedação de acesso de terceiros às chaves privadas associadas à assinatura de mensagens. Isso não é burocracia: é a descrição literal do que faltou nos incidentes de 2025.

4. A janela entre autorizar e assinar

Este é o ponto mais sutil do tópico, e o que mais gera aquele olhar de “peraí, como assim?” quando explico em revisão de código. Vou por partes, porque a sutileza é justamente onde mora o perigo.

Comece pela pergunta: o que a assinatura digital realmente garante? Ela garante que a mensagem não foi alterada depois de assinada e que veio de quem detém a chave. Repare no “depois de assinada”. A assinatura é uma fotografia: ela congela o conteúdo no exato instante em que é tirada. Tudo o que aconteceu com a mensagem antes desse instante, ela fotografa fielmente — inclusive uma adulteração. A assinatura não sabe distinguir o valor certo do valor trocado; ela só certifica que “este foi o conteúdo no momento da foto”.

Agora o fluxo real de um pagamento no seu sistema, do clique à liquidação. Entre duas etapas específicas existe uma janela que quase ninguém protege:

Fluxo de uma ordem de pagamento — onde mora o risco

  [1] Cliente autentica e pede o Pix
       │
  [2] DOMÍNIO AUTORIZA  ← aqui o valor é R$ 100, chave = padaria@cpf
       │                   (esta é a “verdade” do negócio)
       │
       ▼
  ╔═══ JANELA DE RISCO ═══════════════════════════════╗
  ║  a ordem viaja por: fila, enricher, mapeador ISO,  ║
  ║  interceptador, retry, aquele “ajuste” de última   ║
  ║  hora... cada salto pode tocar no conteúdo         ║
  ╚════════════════════════════════════════════════════╝
       │
       ▼
  [3] MENSAGEM É ASSINADA  ← e se aqui o valor virou R$ 100.000
       │                      e a chave virou conta@laranja?
       │
  [4] Enviada ao SPI → liquidada → irreversível

O ataque é este: entre o passo [2] (o domínio autoriza “R$ 100 para a padaria”) e o passo [3] (a mensagem é assinada), a ordem viaja. Ela passa por uma fila, por um serviço que a enriquece com dados, por um mapeador que a converte para o formato ISO 20022, talvez por um interceptador, talvez por um retry. Cada um desses saltos é código que toca na mensagem. Se qualquer um deles — comprometido por um atacante, ou simplesmente mal escrito — trocar o valor para R$ 100.000 e a chave de destino para uma conta laranja, o que acontece no passo [3]?

A mensagem adulterada é assinada. Com perfeição criptográfica. O SPI recebe uma ordem impecável: assinatura válida, emissor legítimo, formato correto. Ele liquida. E o dinheiro foi. A assinatura fez exatamente o trabalho dela — certificou o conteúdo no instante da foto. O problema é que, naquele instante, o conteúdo já estava errado, e a assinatura não tem como saber disso. Ela protege contra alteração depois de assinar; ninguém a projetou para proteger contra alteração antes.

A frase que resume o buraco

Assinar garante que ninguém mexeu na mensagem depois da assinatura. Não garante que ela chegou íntegra até a assinatura. Se o atacante troca o valor no meio do caminho, você não assina uma fraude por acidente — você assina uma fraude com autoridade, e entrega a ela o seu selo oficial.

É exatamente esse buraco que a nova regra do Bacen fecha ao exigir validação de integridade fim a fim antes da assinatura digital. A implementação, na prática, é mais simples do que parece:

Selo de integridade — a defesa

  [2] DOMÍNIO AUTORIZA
       │  gera um selo: hash(valor + chave_destino + ISPB + ...)
       │  o selo viaja GRUDADO na ordem, calculado na FONTE da verdade
       ▼
  ╔═══ JANELA DE RISCO ═══╗  ← se alguém alterar o valor aqui,
  ╚═══════════════════════╝    o hash não vai mais bater
       │
       ▼
  [3] ANTES DE ASSINAR:
       recalcula hash(valor + chave + ISPB) dos campos atuais
       ┌─ bate com o selo?  → assina e envia  ✔
       └─ divergiu?         → ABORTA. não assina nada.  ✖

No passo [2], o ponto onde o domínio autoriza — a fonte da verdade do negócio —, você calcula um selo: um hash dos campos financeiros que não podem mudar (valor, chave de destino, ISPB, identificador da ordem). Esse selo viaja grudado na ordem por toda a janela de risco. No passo [3], imediatamente antes de assinar, você recalcula o hash dos campos como eles estão agora e compara com o selo original. Se bateu, os campos financeiros são idênticos aos que o domínio autorizou: assina e envia. Se divergiu, alguém mexeu no caminho: aborta, não assina nada, e dispara alerta.

É barato, é determinístico, e transforma a janela de risco de um espaço cego numa zona vigiada. E, mesmo sendo simples de descrever, é raríssimo de encontrar implementado — porque exige que alguém, lá no refinamento, tenha enxergado que o intervalo entre autorizar e assinar era um lugar onde o dinheiro podia ser trocado. Que é, no fim, o assunto do artigo inteiro.

5. Ausência de limites: o cofre sem porta

Antes dos detalhes, o conceito — porque “limite” soa como uma configuração chata de produto, e é na verdade um dos controles de segurança mais poderosos que existem em pagamento.

Todos os outros controles deste tópico tentam impedir que o ataque aconteça: autorização impede o acesso indevido, integridade impede a adulteração, isolamento impede o movimento lateral. Limite é diferente. Limite parte de uma premissa humilde e realista: um dia um deles vai falhar. Alguém vai vender uma credencial, uma dependência vai ter um CVE, um endpoint vai passar sem revisão. Quando isso acontecer, o limite é o que decide se você vai ter um problema ou uma manchete.

Ele não pergunta “esta operação é legítima?”. Ele pergunta “quanto dano esta operação pode causar antes que alguém perceba?”. É contenção, não prevenção. É a porta corta-fogo do prédio: não impede o incêndio, impede que ele consuma tudo.

E é aqui que está o ponto que dá título ao trecho: se você não define um teto explícito, o seu sistema tem um teto implícito — o saldo disponível. Nenhum sistema é ilimitado; ele só descobre o próprio limite quando a conta zera. Foi literalmente o que aconteceu nas contas reserva: não havia nada dizendo “esta instituição não movimenta mais que X por hora de madrugada”, então o teto foi o que havia na conta. Um cofre sem porta não é um cofre com segurança fraca. É uma sala.

O erro de posicionamento: o limite está no lugar errado

Quase todo time responde “claro que temos rate limit” — e tem mesmo, no API gateway, contando requisições por IP ou por token. Isso é throttling de infraestrutura: protege o serviço de cair, evita abuso de força bruta. É útil e não é do que estamos falando.

O atacante dos casos de 2025 não faria dez mil requisições. Ele faria algumas dezenas de operações perfeitamente válidas, dentro de qualquer rate limit de gateway, cada uma com um valor alto, para destinos diferentes, às 4h da manhã. O gateway vê tráfego normalíssimo — porque o gateway conta requisições, e o crime acontece em reais.

Daí a regra de arquitetura: limite de infraestrutura mora no gateway; limite de dano mora no domínio. O gateway não conhece conta, saldo, contraparte, histórico nem perfil de risco — e são exatamente essas as dimensões que importam. Se todo o seu controle de limite está na borda, você tem proteção contra volume e nenhuma contra valor.

O que o Bacen passou a exigir — e por quê

Vale entender que o regulador chegou nessa conclusão pelo caminho mais caro possível: vendo o dano acontecer. Boa parte do pacote de 2025–2026 é, na prática, o Banco Central impondo por norma os limites que os sistemas não tinham por design. Os principais:

• Teto de R$ 15 mil por transação de Pix e TED (Resoluções BCB nº 496, 497 e 498) para instituições de pagamento não autorizadas e para as que se conectam à RSFN via PSTI. Repare no raciocínio: o regulador não conseguia garantir a maturidade de segurança daquele grupo, então limitou o dano possível de cada operação. É contenção pura — e é exatamente o tipo de trava que deveria ter existido no código.

• Limites por transação conforme perfil de risco e comportamento do cliente (Resolução BCB nº 506). Note a mudança de filosofia: não é mais um teto único para todo mundo, é um teto que a instituição precisa calcular com base em quem é o cliente e como ele costuma operar. Isso deixou de ser uma configuração e virou um requisito de sistema — alguém precisa modelar perfil, manter histórico e aplicar a decisão em tempo de transação.

• Limitação de dispositivo não cadastrado, regra mais antiga e ainda válida na sua lógica: transações a partir de aparelho desconhecido têm teto reduzido, justamente para conter fraude de endpoint — aquele malware ATS que descrevi no Tópico 02 opera do dispositivo da vítima.

• Bloqueio e rejeição por destino (Resoluções BCB nº 501 e 506): obrigação de rejeitar pagamentos destinados a contas marcadas como usadas em fraude, e de bloquear chaves de fraudadores. É um limite baseado em para onde o dinheiro vai, não em quanto.

• Sistema de alerta de movimentações atípicas no SPI, desenvolvido pelo próprio BC, e o MED 2.0 (Resolução BCB nº 493) com rastreio e bloqueio em camadas sucessivas de contas — reconhecimento explícito de que o dinheiro precisa ser contido enquanto ainda está em trânsito.

• Exclusão do Pix em casos de maior potencial lesivo e reincidência (Resolução BCB nº 507): o limite último, aplicado ao participante inteiro.

Traduzindo o recado regulatório em uma frase: o Bacen deixou de confiar que cada instituição calibraria sozinha o próprio raio de dano. Quem já tinha limites bem desenhados sentiu pouco. Quem não tinha, descobriu os seus por decreto — e com números escolhidos por outra pessoa.

Como a engenharia implementa isso de verdade

Agora a parte prática. Um sistema de limites maduro trabalha em camadas cumulativas — cada uma respondendo a uma pergunta diferente sobre a mesma operação:

As camadas de contenção — todas avaliadas ANTES de autorizar

 valor      → esta transação sozinha passa do teto da conta/perfil?
 acúmulo    → somada às últimas 1h / 24h, passa do teto da janela?
 velocidade → quantas operações esta conta fez nos últimos N minutos?
 destino    → chave criada há minutos? contraparte nunca vista?
 contexto   → horário atípico p/ este cliente? dispositivo novo?
 agregado   → e o PARTICIPANTE? quanto saiu da instituição nesta hora?
                └── a camada que faltou nas contas reserva

Alguns pontos de implementação que fazem diferença entre um limite decorativo e um limite real:

• Janela deslizante, não janela de calendário. Um limite “por dia” que zera à meia-noite entrega ao atacante uma janela dobrada: ele opera das 23h às 01h e usa dois dias de cota em duas horas. Janela deslizante (as últimas 24 horas corridas) elimina essa brecha. E vale ter janelas noturnas mais apertadas: o comportamento legítimo às 4h da manhã é raro, e foi exatamente esse horário que os atacantes escolheram.

• O limite agregado do participante é o que ninguém implementa. Todo mundo limita o cliente. Quase ninguém limita a instituição — quanto pode sair, no total, por hora, daquele ambiente. É a camada que teria transformado R$ 800 milhões em um alerta na primeira dezena de milhões. Se você opera contas reserva ou conta bolsão, esse é provavelmente o item mais valioso desta lista inteira.

• Falha fechada, não aberta. Se o serviço que avalia limites estiver indisponível, o que o seu código faz? Se a resposta for “deixa passar para não derrubar o produto”, você tem um bypass de segurança que o atacante pode induzir derrubando aquele serviço. Operação de alto valor com motor de limite fora do ar deve ser recusada, não liberada.

• Contador com estado consistente. Limite avaliado sobre dado desatualizado (réplica com atraso, cache velho) é limite que autoriza duas vezes o mesmo teto quando as requisições chegam em paralelo. Contador atômico e transacional, com a mesma disciplina que você aplica a saldo.

• Alçada e segunda pessoa. Acima de certos valores, o controle não deveria ser “bloqueia ou libera”, mas “exige aprovação adicional”. Dupla custódia é o controle bancário mais antigo que existe, e continua sendo o mais eficaz contra ator único — inclusive contra credencial comprada.

• Limite ultrapassado é evento de segurança. Recusar não basta: precisa gerar alerta correlacionado. Uma conta batendo no teto repetidamente às 4h não é um cliente frustrado, é um sinal. Se o seu sistema recusa em silêncio, você jogou fora a informação mais valiosa que tinha.

O menor commit de maior impacto do setor

A diferença entre um incidente de R$ 2 milhões e um de R$ 800 milhões não está numa tecnologia sofisticada de detecção, num modelo de IA ou num fornecedor caro. Está, muitas vezes, em uma comparação com um número, avaliada no lugar certo do domínio, com o contador certo por trás. É provavelmente o melhor retorno por linha de código que existe em sistemas de pagamento — e continua sendo tratado como configuração de produto, não como arquitetura de segurança.

6. Logs que não servem para nada

Quase todo mundo loga. Quase ninguém consegue responder, em quinze minutos, a pergunta “o que essa credencial fez nas últimas seis horas, ponta a ponta?”. Os defeitos clássicos:

• Log sem identificador de correlação que atravesse todos os saltos (o endToEndId existe exatamente para isso — use como chave de correlação e não só como campo de negócio).

• Log de aplicação separado de log de acesso, separado de log de infraestrutura, sem tempo sincronizado nem consulta unificada.

• Retenção curta demais para uma forense que descobre o incidente semanas depois. A norma agora manda guardar resultados de teste de intrusão e planos de ação por cinco anos; a sua trilha de auditoria precisa ter a mesma ambição.

• Detecção baseada em relatório, não em fluxo. Se o alerta nasce de um job das 6h, você tem um sistema de história, não de defesa.

7. A porta dos fundos operacional

Todo sistema financeiro tem endpoints administrativos: reprocessar, estornar manualmente, forçar conciliação, ajustar saldo, liberar bloqueio. Eles nascem no calor de um incidente, entram sem revisão de segurança, ficam para sempre e frequentemente não têm MFA, não têm dupla aprovação, não têm limite e não têm trilha. É o presente perfeito para uma credencial comprada.

Por isso a exigência de autenticação multifatorial para acessos administrativos aos ambientes Pix e STR não é detalhe operacional: é reconhecimento regulatório de que a porta dos fundos é a porta preferida.

8. O domínio como controle de segurança

Fecho o tópico com a parte que costuma ser tratada como “modelagem” e que, na verdade, é defesa. Os estados são a sua rede de proteção. Estados terminais precisam ser de fato terminais e imutáveis; transições precisam ser explícitas e verificáveis; a fonte da verdade do que foi liquidado é o extrato do SPI, não a sua tabela.

Um número de exemplo: conciliação contínua contra a infraestrutura oficial detecta divergência em minutos. Conciliação em D+1 detecta em horas — depois da conversão em cripto. A escolha entre as duas parece uma decisão de eficiência. É uma decisão de segurança.

Para colar no monitor

Toda API que origina dinheiro é uma superfície de ataque com CNPJ. Ela não precisa estar exposta na internet para ser explorada — precisa apenas ser alcançável por alguém que conseguiu um crachá.

Pense comigo

Abra agora o endpoint de iniciação de pagamento do seu serviço. Percorra o caminho de cima para baixo e marque, linha por linha, onde estão: (a) a validação de que a origem pertence ao autenticado; (b) o teto de valor; (c) o selo de integridade que sobrevive até a assinatura; (d) o identificador de correlação; (e) o ponto onde uma anomalia dispararia alerta em tempo real.

Se faltar mais de dois desses cinco, você pode ter sérios problemas no futuro!

Tópico 04: Governança fraca é dívida técnica com juros: o que o Bacen passou a exigir

Até 2024, o arcabouço de segurança cibernética do sistema financeiro brasileiro girava em torno de duas normas de 2021 — a Resolução CMN nº 4.893 (para instituições financeiras) e a Resolução BCB nº 85 (para instituições de pagamento). Eram normas principiológicas: exigiam política, governança, plano de resposta a incidentes, gestão de terceiros. Boas normas. Auditáveis por documento.

Depois de 2025, o regulador mudou de idioma. Saiu do “você tem política?” e entrou no “me mostre o controle funcionando”. Vale a pena entender o pacote, porque cada item dele vira, mais cedo ou mais tarde, um card no seu board.

A resposta ao ponto cego: os PSTIs entram no radar

A lição mais dura do caso C&M foi que uma empresa não regulada podia comprometer contas reserva de várias instituições simultaneamente. A resposta veio na Resolução BCB nº 498/2025, endurecida pela Resolução BCB nº 547/2026, que disciplina o credenciamento dos Provedores de Serviços de Tecnologia da Informação para acesso à Rede do Sistema Financeiro Nacional. O que ela trouxe:

• Capital mínimo de R$ 15 milhões e exigências ampliadas de governança e gestão de riscos.

• Comprovação de capacidade técnico-operacional segundo padrões do Deinf/BCB.

• Certificação técnica das soluções usadas por instituições para integrar, por interfaces eletrônicas, aos serviços do provedor.

• Ações de inteligência cibernética, incluindo monitoramento de informações de interesse — clientes, chaves, credenciais, vulnerabilidades — na internet aberta e fechada.

• Sujeição a medidas cautelares e ao descredenciamento em caso de descumprimento.

O efeito de mercado foi imediato e vale registrar sem romantismo: o segmento encolheu. Stark Infra e Topaz (Stefanini) oficializaram a saída; ABBC, C&M Software e a própria Sinqia/Evertec entraram em processo de saída ordenada. A barreira de entrada subiu, e com ela a concentração. Segurança tem custo, e o custo aparece em algum lugar.

Em paralelo, as Resoluções BCB nº 496, 497 e 498 impuseram limite de R$ 15 mil por transação de Pix e TED para instituições de pagamento não autorizadas e para aquelas conectadas à RSFN via PSTI — uma trava de dano aplicada por regulação, exatamente do tipo que o código deveria ter e não tinha. E a Resolução BCB nº 494 antecipou de dezembro de 2029 para maio de 2026 o prazo para que IPs não autorizadas peçam autorização de funcionamento.

Os controles mínimos: o que virou obrigatório para todos nós

Em 18 de dezembro de 2025, a Resolução CMN nº 5.274/2025 (alterando a 4.893) e a Resolução BCB nº 538/2025 (alterando a 85) reescreveram a política de segurança cibernética com prazo de adequação em 1º de março de 2026. Elas detalham controles mínimos mandatórios: autenticação; criptografia; prevenção e detecção de intrusão; prevenção de vazamento de informações; proteção contra software malicioso; rastreabilidade; gestão de backup; avaliação e correção de vulnerabilidades; controles de acesso; perfis de configuração segura (hardening); proteção de rede; gestão de certificados digitais; requisitos de segurança para integração por interfaces eletrônicas (APIs); e ações de inteligência no ambiente cibernético.

Repare que dois desses itens são explicitamente sobre o que fazemos no editor: hardening e segurança de APIs. E há um detalhe que muda o escopo de forma decisiva: os controles se aplicam também a sistemas de terceiros executados com recursos computacionais da própria instituição. Aquele componente do fornecedor que roda no seu cluster agora é problema seu, formalmente.

Os reforços específicos de Pix e STR

Esta é a parte que qualquer pessoa que escreve código de pagamento deveria saber de cor:

• MFA obrigatório para acessos administrativos aos ambientes Pix e STR.

• Isolamento físico e lógico dos ambientes Pix e STR dos demais sistemas; em nuvem, instâncias dedicadas e apartadas.

• Monitoramento de credenciais e certificados digitais, especialmente no SPI, com vedação de acesso de terceiros às chaves privadas de assinatura de mensagens.

• Validação de integridade fim a fim antes da assinatura digital das transações.

• Comunicação eletrônica na RSFN qualificada como “serviço relevante” para fins de contratação, elevando o nível de gestão de risco e supervisão.

• Teste de intrusão anual por profissionais independentes, com documentação de resultados e planos de ação mantidos à disposição do BC por cinco anos.

• Cyber Threat Intelligence como controle mínimo — não mais “apoio técnico”, mas requisito formal conectado ao SOC/CSIRT e à gestão de credenciais.

E do lado do dinheiro: fechar o ralo do cash-out

O outro eixo do pacote, apresentado pelo presidente do Banco Central ao Senado em maio de 2026, ataca a saída dos recursos: sistema de alerta de movimentações atípicas no SPI; MED 2.0 (Resolução BCB nº 493), que amplia a identificação de contas usadas em fraude e a devolução às vítimas; botão de contestação do MED (Instrução Normativa BCB nº 589), para acelerar o bloqueio na conta do fraudador; bloqueio de chaves Pix de fraudadores e rejeição obrigatória de pagamentos destinados a contas usadas em fraude (Resoluções BCB nº 506 e 501); limites por transação conforme perfil e comportamento do cliente; encerramento compulsório de contas usadas para movimentar recursos de terceiros — o cerco às contas bolsão; BC Protege+ (Resolução BCB nº 475), que impede abertura de conta ou inclusão de titular sem autorização prévia; e multas dosadas por capacidade econômica, com exclusão do Pix em casos de maior potencial lesivo e reincidência.

O alerta que fecha o círculo

Em novembro de 2025, o Comitê de Estabilidade Financeira do Banco Central colocou na ata algo que soa como um code review do setor inteiro: preocupação com a “crescente dependência” de serviços de terceiros e com o “uso disseminado” de APIs, em muitos casos sem avaliação periódica de riscos nem monitoramento operacional adequado.

Os números que sustentam o alerta: 72,6% das instituições usam integrações por API, mas apenas cerca de 29% revisam regularmente os riscos associadas a essas conexões. É a distância entre construir e sustentar, expressa em percentual.

A tradução para quem escreve código

Não existe mais “requisito de segurança” como categoria separada de “requisito funcional”. MFA em rota administrativa, isolamento de ambiente, integridade antes da assinatura, rastreabilidade ponta a ponta e limite por perfil de risco são comportamentos do sistema — com dono, teste automatizado, evidência e data. Se um deles não tem um teste que falha quando alguém o remove, ele não existe: existe uma frase num documento.

Pense comigo

Pegue a última funcionalidade de Pix que o seu time entregou. Quais dos 14 controles mínimos ela tocou? Consegue apontar o pull request em que cada um foi endereçado, ou o teste que o cobre?

E a versão executiva da mesma pergunta, que é a que o Bacen faz: se o supervisor pedir a evidência amanhã, você entrega um log ou uma apresentação?

Tópico 05: SSDLC: onde a norma vira código

Chegamos ao ponto do artigo em que preciso ser direto sobre uma coisa: SSDLC não teria impedido que aquele funcionário vendesse a credencial. Nenhum ciclo de desenvolvimento seguro impede a fraqueza humana, o aliciamento, a necessidade financeira.

O que o SSDLC faz é diferente e mais importante: ele determina quanto vale a credencial vendida. Num sistema com privilégio mínimo, segregação real, limites explícitos, integridade fim a fim e detecção em tempo de transação, aquela mesma credencial valeria uma consulta a extrato e um alerta imediato. Num sistema sem isso, valeu R$ 800 milhões. O ataque é o mesmo. O design é que decide o resultado.

Vamos por fase, com o que dá para começar na segunda-feira.

Requisitos: escreva o caso de abuso junto com a história de usuário

Para cada “como pagador, quero iniciar um Pix por chave”, escreva a irmã gêmea maligna: “como fraudador com credencial válida, quero iniciar um Pix por chave a partir da conta de outro cliente”, “…de madrugada, para uma chave criada há dois minutos”, “…mil vezes em sessenta segundos”.

Caso de abuso não é paranoia: é requisito. E ele tem uma propriedade excelente — vira teste automatizado quase sem tradução. Uma história de usuário produz um teste de caminho feliz; um caso de abuso produz um teste que precisa falhar com 403.

No mesmo movimento, amarre requisito regulatório ao backlog com identificador. “RN-Pix-014: integridade fim a fim antes da assinatura (CMN 5.274)”. Assim a rastreabilidade regulatória não é um exercício arqueológico de auditoria: ela nasce no seu backlog.

Design: modelagem de ameaças no fluxo, não no diagrama bonito

Aplique STRIDE⁴ ao fluxo real de iniciação e liquidação, com as fronteiras de confiança desenhadas explicitamente — incluindo a fronteira com o PSTI, com o BaaS, com o app desenvolvido por terceiro. Nos casos de 2025, era exatamente essa fronteira que estava implícita.

// Modelagem de ameaças aplicada ao fluxo Pix
S  Spoofing        → serviço A se passa por serviço B?  mTLS + identidade de carga
T  Tampering       → alguém altera valor/destino entre autorizar e assinar?  selo de integridade
R  Repudiation     → dá para reconstruir quem fez o quê?  endToEndId como correlação
I  Info disclosure → chave privada / chaves Pix / dados cadastrais expostos?
D  Denial          → esgotamento de conexão com o SPI derruba o produto?
E  Elevation       → operador vira originador? conta de serviço vira admin?

Duas perguntas de design que valem mais que uma semana de ferramenta:

• Onde está o ponto único em que um ator consegue fechar o ciclo sozinho?

• E o que acontece se este componente for hostil?

Faça a segunda pergunta apontando para o seu próprio serviço de integração. É desconfortável, e é o exercício certo.

Codificação: autorização centralizada, tudo mais é detalhe

• Autorização como componente, não como if espalhado. Um ponto de decisão, testável isoladamente, chamado por todos os fluxos monetários. Espalhar autorização por controllers é garantir que um deles ficará para trás.

• Negar por padrão. Rota nova nasce fechada. Perfil novo nasce sem permissão. Campo novo no payload nasce rejeitado por validação de esquema estrita — nada de schema permissivo aceitando propriedades desconhecidas em mensagem financeira.

• Idempotência de verdade. Chave de idempotência com escopo, TTL e persistência; reenvio devolve o mesmo resultado, não um segundo pagamento. Em sistema irreversível, idempotência é controle de segurança.

• Segredos fora do código e fora do humano. Cofre com credencial dinâmica, chave de assinatura em HSM, nenhum segredo estático em variável de ambiente de longa duração.

• Dependências são superfície. SCA e SBOM no pipeline. A cadeia de suprimentos do software merece o mesmo rigor que passamos a exigir da cadeia de fornecedores — e é o mesmo tipo de risco.

Revisão de código: alguém precisa olhar com a lente errada

Revisão de código no Brasil, na média, verifica legibilidade, cobertura e regra de negócio. Quase nunca verifica autorização. Uma mudança pequena e barata: em repositórios que tocam dinheiro, exija revisor de segurança designado (via CODEOWNERS) para qualquer alteração em rota monetária, em autorização, em assinatura ou em limites. E dê ao revisor uma lista curta, do tipo: “esta mudança altera quem pode fazer o quê? altera um teto? altera o que é assinado? altera o que é logado?”.

Pipeline: onde o discurso encontra o bloqueio

• SAST, DAST, SCA⁵ e secret scanning bloqueantes nas rotas críticas — não informativos, não “corrige depois”.

• Segregação de função no deploy: quem faz o merge não é quem aprova a promoção para o ambiente Pix. Isso é o equivalente, na engenharia, à dupla custódia que os bancos exigem no caixa há um século.

• Acesso a produção efêmero e sob demanda, com justificativa e trilha. Acesso permanente de desenvolvedor a produção de pagamento é a versão institucional da credencial vendida no bar.

• Assinatura e proveniência de artefatos, para que o binário que roda seja comprovadamente o que saiu do repositório revisado.

Testes: os que quase ninguém escreve

Além de unidade e integração, três famílias que deveriam ser obrigatórias em qualquer sistema Pix:

1. Teste de autorização negativa — o “teste do vizinho”: o token do cliente A tentando operar a conta do cliente B precisa retornar 403, e isso precisa ser um teste automatizado que roda em toda build. Cada objeto sensível, cada função administrativa.

2. Teste de limite e velocidade — o sistema precisa recusar a operação 101 na janela, o valor acima do teto, o destino recém-criado acima do valor de alçada. Se não existe teste, o limite vai ser removido por alguém, em produção, num incidente, e ninguém vai notar.

3. Teste de detecção — este é o mais esquecido. Injete um padrão anômalo em ambiente controlado e verifique que o alerta dispara, chega ao destino certo e aciona quem deve. Alerta que nunca foi testado é alerta que não existe.

Observabilidade e contenção: detecção é requisito funcional

Se há uma lição operacional dos casos recentes, é esta: a detecção chegou tarde e veio de fora. Na C&M, o aviso partiu de uma terceira instituição. Em vários casos, a percepção veio quando o dinheiro já virava cripto.

O que precisa existir, e ser código:

• Correlação por endToEndId atravessando todos os serviços e chegando ao painel.

• Detecção em tempo quase real de anomalia de volume, horário, contraparte, destino novo e concentração — no domínio, não só no gateway.

• Kill switch por produto, por participante, por tipo de operação — implementado, documentado e ensaiado. O Banco Central desligou o acesso da C&M à infraestrutura em horas. A pergunta é: quanto tempo o seu desligamento leva?

• Conciliação contínua contra a fonte oficial, com alarme por divergência.

• Revogação de credencial e certificado em minutos, automatizada. “Já encerramos o acesso” precisa ser um botão, não um projeto.

E o pedaço cultural, que é o mais difícil

O programador júnior terceirizado da C&M tinha aquele acesso porque, em algum momento, foi mais fácil conceder do que desenhar. Ninguém acordou querendo criar um risco de R$ 1 bilhão; alguém só precisava destravar um chamado numa sexta-feira à noite.

Privilégio mínimo não é uma decisão de arquitetura que alguém precisa tomar no refinamento, defender no planning e sustentar quando o prazo apertar. E é aí, exatamente aí, que a mentalidade de conformidade que o Bacen exige deixa de ser burocracia e vira ofício: entender que o requisito regulatório é a codificação de um dano real que já aconteceu com alguém, escrito por quem teve que pagar a conta.

A tese do tópico, em uma frase:

O SSDLC não impede que vendam uma credencial. Ele impede que uma credencial vendida valha oitocentos milhões de reais.

Pense comigo

Quando foi a última vez que uma build do seu repositório falhou por motivo de segurança — um teste de autorização quebrado, um segredo detectado, um limite removido, uma dependência vulnerável barrando o merge?

Se a resposta for “nunca”, existem duas explicações possíveis: o seu código é perfeito, ou o seu pipeline não está olhando. Uma delas é muito mais provável que a outra.

Tópico 06 · “Mas o que isso tem a ver comigo?” Como o ataque funciona na prática…

Se você chegou até aqui trabalhando diretamente com sistemas que operam Pix, é bem provável que uma objeção esteja formada na sua cabeça: “tá, mas eu não tenho o problema da C&M. Meu ecossistema tem camadas. API gateway na borda, rate limit, WAF, motor antifraude, mTLS entre serviços. Um atacante que não trabalha aqui dentro simplesmente não passa.”

É uma objeção legítima, e é exatamente a que eu quero desmontar — não com retórica, mas mostrando o mecanismo. Porque o Pix, você sabe melhor que ninguém, não é uma simples transferência instantânea. É um sistema distribuído, com integração síncrona a uma infraestrutura crítica, assinatura de mensagens, custódia de chaves e liquidação irreversível. Cada uma dessas propriedades é uma camada de proteção — e cada camada é software, e software tem defeito.

A pergunta honesta não é “minhas camadas me protegem?”. É “o que acontece quando uma delas tem uma falha crítica, e o atacante encontra essa falha antes de mim?”. Vou responder isso de forma transparente. O objetivo aqui é 100% defensivo: você não consegue defender um sistema contra um ataque que não entende.

Primeiro, mate uma ilusão: o gateway não é uma parede

API gateway, WAF e rate limit são redutores de ruído, não paredes. Eles filtram o óbvio: a injeção de SQL trivial, o scanner barulhento, o pico de requisições. O que eles não fazem — porque não conseguem — é entender a semântica do seu domínio. Um WAF não sabe que a conta de origem daquela ordem de pagamento não pertence ao token que a enviou. Para o WAF, é uma requisição HTTPS bem formada, com um JSON válido, dentro do rate limit. Ela passa.

Pior: WAF é regra, e regra se contorna. A própria comunidade de segurança documenta abertamente como ofuscar payloads para passar por WAF em vulnerabilidades famosas. Trate o gateway como o que ele é: um quebra-molas que reduz a velocidade do tráfego hostil. Não como o portão do cofre.

O frontend mobile não é seu. É do atacante.

Aqui mora um erro conceitual que sustenta metade das vulnerabilidades que vejo. O time trata o app como “nosso cliente confiável”. Não é. Assim que o APK é publicado, ele está na mão do adversário, para ser desmontado com calma.

O que um atacante extrai de um app mobile em uma tarde, com ferramentas públicas e gratuitas:

• Todos os endpoints que o app chama — a sua superfície de API, documentada de graça pelo seu próprio binário.

• Segredos hardcoded: API keys, tokens estáticos, credenciais de serviços de terceiros que alguém “só deixou aqui pra testar”.

• A lógica de negócio embutida — inclusive as validações que você achou que eram “de segurança” e que rodam no dispositivo dele.

E o certificate pinning, que muitos tratam como a defesa definitiva? É bypassável. Com o dispositivo sob controle do atacante (root/jailbreak, emulador, instrumentação dinâmica), o pinning cai. A lição de arquitetura é dura e inegociável: toda decisão de segurança que importa acontece no servidor. O app é uma sugestão de interface, não um guardião. Se a sua autorização depende de o cliente “se comportar”, ela não existe.

Regra de ouro do cliente hostil

Assuma que o atacante fala com a sua API sem passar pelo seu app. Direto, com uma ferramenta de linha de comando, montando os pacotes na mão, com o token que ele extraiu ou capturou. Se a sua API só está segura porque “o app não deixaria fazer isso”, a sua API não está segura.

Agora o coração: o que é “acesso remoto por vulnerabilidade” (RCE)

Remote Code Execution é o santo graal do atacante: fazer o seu servidor executar código dele. Não roubar um dado, não burlar uma tela — rodar comandos dentro do seu processo, com os privilégios do seu processo. E o mecanismo, por trás de toda a mística, é quase sempre o mesmo princípio:

o sistema confunde dado com instrução.

Você espera receber um dado (um nome, um valor, um cabeçalho, um objeto serializado). Mas em algum ponto do caminho, aquele dado é interpretado como código, ou usado para decidir qual código carregar. Toda a família RCE é variação disso. Vamos aos vetores reais, com o que você deve procurar no seu código — o sink, o ponto onde o dado perigoso é consumido.

Deserialização insegura. Um objeto serializado carrega, junto, o tipo dele. Se você desserializa dado que veio de fora e existe, no seu classpath, uma sequência de classes que pode ser encadeada (o que a comunidade chama de gadget chain), o simples ato de desserializar dispara execução. Você não chamou nenhum método malicioso; a máquina de desserialização chamou por você. O sink⁶ a caçar: qualquer readObject, ObjectInputStream, ou binder de JSON/XML configurado para instanciar tipos arbitrários a partir do payload.

Injeção de expressão / template. Frameworks modernos avaliam expressões (SpEL no Spring, OGNL no Struts, template engines em qualquer linguagem). Se entrada do usuário chega a um avaliador de expressão, ela deixa de ser texto e vira programa. Foi essa a natureza do Spring4Shell (CVE-2022-22965): manipulação de data binding alcançava o carregador de classes e permitia carregar código malicioso. O sink: parseExpression com string do usuário, template renderizado com input não confiável, Runtime.exec/ProcessBuilder alimentado por parâmetro.

Uma linha de log. O Log4Shell (CVE-2021-44228, CVSS 10.0) é o exemplo mais didático e mais assustador da história recente. A biblioteca de log processava strings controladas pelo usuário de forma insegura: uma expressão de lookup dentro de uma mensagem logada fazia o Log4j buscar e executar código de um servidor remoto. Como quase toda aplicação loga entrada do usuário — um cabeçalho HTTP, um User-Agent, um campo de formulário —, bastava enviar a string certa num header para comprometer o servidor. A vítima nem precisava clicar. E o ponto que importa para nós: ninguém escreveu código inseguro. A insegurança estava numa dependência transitiva que a maioria dos times nem sabia que tinha. Anos depois, em 2025, ainda há serviços vulneráveis por dependência oculta e remediação incompleta.

SSRF — o vetor que ama a nuvem. Server-Side Request Forgery: você faz o servidor da vítima realizar uma requisição para um destino escolhido pelo atacante. Parece inofensivo até você lembrar onde o seu serviço roda. Numa nuvem, existe um endpoint de metadados interno que entrega credenciais temporárias da identidade da máquina. Um SSRF bem posicionado transforma “meu serviço busca uma imagem nessa URL” em “meu serviço acabou de entregar as credenciais de nuvem dele para o atacante”. Dali, o adversário se move lateralmente — e é por isso que o isolamento de ambiente Pix que o Bacen passou a exigir não é firula: é a diferença entre um serviço comprometido e o ambiente de assinatura comprometido.

Como o “acesso remoto” realmente se estabelece

Suponha que o atacante conseguiu executar um comando via um desses vetores. Como isso vira uma sessão interativa, um “controle” do servidor? Vamos para o conceito — e, dentro dele, a sua melhor defesa.

Seu firewall provavelmente bloqueia conexões de entrada não autorizadas. Então o atacante inverte o fluxo: faz o seu servidor iniciar uma conexão de saída para uma máquina que ele controla, e usa esse canal para enviar comandos e receber respostas. É o conceito de reverse shell: o servidor comprometido “liga de volta” para o atacante. Ele funciona porque, na esmagadora maioria das arquiteturas, ninguém filtra o tráfego de saída. Entrada é paranoia; saída é festa aberta.

O controle que quebra a corrente inteira

Egress filtering. Se o seu ambiente de pagamento só pode abrir conexões de saída para uma lista curtíssima e explícita de destinos (o SPI, o seu banco de dados, o seu cofre), então: a RCE não consegue “ligar de volta” para o atacante; o Log4Shell não consegue buscar o código remoto; o SSRF não consegue exfiltrar; o dado roubado não consegue sair. Um único controle de rede neutraliza metade da cadeia. É de longe o item de melhor custo-benefício desta lista, e é o mais negligenciado — porque bloquear a saída dá trabalho e quebra conveniências. De novo: é o ponto.

A pergunta que todo mundo faz: “no .NET/Node/Go estou livre?”

Não. E preciso ser direto sobre isso porque é uma crença perigosa. A vulnerabilidade não mora na linguagem; mora no padrão — na fronteira onde dado não confiável vira instrução, decisão ou requisição. Toda linguagem cruza essa fronteira. O que muda é o nome da falha, não a existência dela.

• Java / Spring. Deserialização (a família de gadgets é vasta), SpEL/OGNL, e a exposição gigantesca a dependências do ecossistema JVM — Log4Shell e Spring4Shell foram eventos de escala planetária. Uma análise da Veracode apontou que a maioria esmagadora das empresas com muitas aplicações usa Java, e uma fatia enorme rodava versões vulneráveis. Não porque programam mal; porque a superfície é imensa.

• .NET. “É Microsoft, é seguro.” A mesma família existe com outros nomes: desserialização perigosa (BinaryFormatter, TypeNameHandling permissivo no serializador JSON instanciando tipos do payload), abuso de view state quando a proteção de integridade está mal configurada, injeção de comando via Process.Start. Mesmo princípio, sotaque diferente.

• Node.js. A ausência de tipagem forte abre vetores próprios: prototype pollution — o atacante injeta propriedades no protótipo base dos objetos e altera o comportamento da aplicação inteira, às vezes escalando para RCE; eval e o módulo vm alimentados por input; injeção de comando via child_process. E o npm é o maior tapete vermelho de supply chain que existe: milhares de dependências transitivas, e ataques reais de pacote malicioso injetado numa biblioteca popular.

• Go. Este é o mais interessante porque carrega a fama de “seguro por design”. E é verdade em uma dimensão: por ser memory-safe, Go elimina classes inteiras de vulnerabilidade de corrupção de memória (buffer overflow e afins) que assombram C/C++. Mas segurança de memória não é segurança de lógica. Em Go você continua vulnerável a SSRF, path traversal, injeção de comando via os/exec, e a um clássico específico: usar text/template onde deveria usar html/template, abrindo injeção. E a cadeia de suprimentos morde igual — um módulo comprometido é um módulo comprometido, não importa a elegância da linguagem.

A conclusão que dói

Nenhuma linguagem te salva. Go reduz uma família de bugs; não reduz a família que mais importa em pagamento, que é a lógica de autorização e a confusão dado/instrução. Trocar de stack para “ficar seguro” é como trocar de fechadura numa porta que ninguém tranca. O trabalho é o mesmo em todas: identidade de carga de trabalho, entrada tratada como hostil, dependências vigiadas, saída filtrada, privilégio mínimo.

Então o atacante precisa de um Kali Linux?

Essa pergunta merece uma resposta honesta porque a mitologia atrapalha a defesa. Kali Linux é só uma distribuição Linux com um monte de ferramenta de segurança pré-instalada. Não é uma arma mágica; é conveniência. As mesmas ferramentas rodam em qualquer sistema. O que importa entender é a economia real do ataque em 2026, e ela é bem menos glamurosa que o imaginário do gênio de capuz:

• A maior parte é automatizada. Scanners de vulnerabilidade conhecida (os chamados n-days) varrem a internet inteira procurando serviços não corrigidos. Quando um CVE crítico sai, existe proof of concept público, em média, em duas semanas — e a exploração em massa começa antes de a maioria das empresas ter corrigido. O atacante não descobriu a falha; ele baixou o exploit e apontou para o seu IP.

• Descobrir o alvo é trivial. Existem motores de busca que indexam dispositivos e serviços expostos na internet. O atacante pesquisa “serviços rodando a versão X do framework Y” e recebe uma lista. O reconhecimento que antes levava semanas hoje é uma query.

• A barreira de entrada despencou. Ferramentas de interceptação e teste de API, frameworks de exploração e catálogos de templates de vulnerabilidade são gratuitos, documentados e cheios de tutorial. E a IA generativa reduziu ainda mais o custo de adaptar um exploit ou escrever o script de saída.

Ou seja: o atacante não precisa ser um especialista de sistemas — que era exatamente a sua intuição no começo deste tópico, e ela está certa pela razão oposta à que você imaginava. Ele não precisa ser gênio porque a genialidade foi commoditizada. O especialista descobre a falha uma vez e publica; mil operadores medianos a exploram em escala. O seu adversário mais provável não é um hacker brilhante mirando você especificamente. É um scanner automatizado que encontrou a sua dependência desatualizada às 3h da manhã, no meio de uma varredura de milhões de IPs, e um humano que, ao ver o alvo financeiro, resolveu olhar com atenção.

Fechando o circuito: por que isso é problema seu, e não do CISO

Junte as peças e veja como um caminho “de fora para dentro” alcança o mesmo lugar que a credencial comprada da C&M alcançou por dentro:

// A corrente — cada elo é uma decisão de engenharia
1. app mobile revela endpoint de integração (cliente não é confiável)
2. endpoint roda dependência com CVE crítico não corrigido
3. requisição forjada dispara RCE (dado vira instrução)
4. servidor abre conexão de saída — ninguém filtra egress
5. atacante lê identidade da carga de trabalho / material de chave
6. ambiente NÃO isolado → move lateral até o ponto de assinatura
7. agora ele emite mensagem VÁLIDA para o SPI
   → e você voltou ao Tópico 01: “não houve invasão”, só uso legítimo

Repare que o passo 7 é idêntico ao resultado do insider. Por isso os dois capítulos deste artigo — o de dentro e o de fora — convergem: ambos terminam com uma mensagem perfeitamente válida sendo assinada e liquidada. A diferença é só o caminho até a chave. E cada elo dessa corrente — do 1 ao 6 — é algo que você, arquiteto ou programador, tem o poder de cortar: tratar o mobile como hostil, corrigir dependência com SLA de horas, procurar os sinks no code review, filtrar a saída, dar identidade mínima à carga de trabalho, isolar o ambiente Pix.

O CISO define a política. Quem quebra a corrente é quem escreve a linha. É por isso que “o que isso tem a ver comigo?” tem uma única resposta honesta: tudo. A distância entre uma vulnerabilidade num pacote e uma mensagem fraudulenta no SPI é feita, elo por elo, das decisões que você toma antes do merge.

Pense comigo

Três perguntas concretas, para responder hoje:

(1) Você tem inventário das suas dependências — inclusive as transitivas — e um alerta que dispara quando uma delas ganha um CVE crítico? Se um novo Log4Shell sair amanhã, quanto tempo até você saber se está exposto?

(2) O seu ambiente de pagamento pode abrir conexão de saída para qualquer lugar, ou só para uma lista explícita?

(3) Se a sua aplicação for comprometida por RCE, a identidade que ela carrega alcança a chave de assinatura e o SPI — ou o raio de dano para na borda do serviço?

Se você não gostou de nenhuma das três respostas, boas notícias: as três são código e configuração. Nenhuma delas é sorte.

Tópico 07: Cada funcionalidade nova é uma superfície nova

O Pix não é um produto pronto. É uma plataforma em agenda evolutiva permanente, e cada item dessa agenda muda o modelo de ameaças de quem se integra a ele. O padrão histórico é implacável: toda funcionalidade que remove atrito para o usuário transfere a decisão para uma camada automática — e onde você tira um humano, precisa colocar um controle.

Vamos olhar o que vem e onde, na minha leitura, mora o risco.

Pix Automático: o consentimento vira a nova credencial

Pagamentos recorrentes com autorização única e débitos subsequentes sem autenticação transação a transação. É débito automático democratizado — e é, tecnicamente, a criação de um mandato de longa duração. Já é obrigatório nos casos em que o recebedor de autorização de débito interbancário é pessoa jurídica ou entidade não autorizada pelo BC, e a partir de outubro de 2026 alcança contas salário.

O risco muda de lugar: deixa de ser “roubar uma transação” e passa a ser “obter ou adulterar um mandato”. As perguntas de design que o seu time precisa responder antes de subir isso:

• Qual o escopo do consentimento — valor máximo, periodicidade, prazo, contraparte fixa? Um mandato sem teto é um cheque em branco recorrente.

• Quem pode alterar um mandato existente, e isso exige nova autenticação forte? Alterar é mais perigoso que criar.

• Como se revoga, em quanto tempo, e o que acontece com a cobrança em voo?

• Existe proteção contra replay de autorização e contra reuso de consentimento em contexto diferente do original?

• O consentimento é auditável ponta a ponta — quem, quando, de qual dispositivo, com qual evidência?

Pix por aproximação e o modelo offline: a premissa síncrona quebra

O Pix por aproximação (NFC, via carteiras digitais) já está disponível. O que vem depois é mais interessante do ponto de vista de risco: o QR pagador / Pix offline, previsto de 2027 em diante, em que o pagador consegue concluir a operação sem conexão com a internet no momento.

Isso quebra a premissa que sustenta boa parte da defesa atual: a validação síncrona contra a infraestrutura antes da liquidação. Numa operação offline, alguma coisa é gerada e apresentada localmente, e a reconciliação acontece depois. As perguntas ficam evidentes: como se previne duplicidade e replay de um token gerado no dispositivo? Qual a janela de validade? Quem assume o risco de saldo insuficiente entre a apresentação e a liquidação? Como se detecta um dispositivo comprometido gerando tokens em série — lembrando que já existe malware brasileiro fazendo fraude no próprio aparelho da vítima?

Pix Parcelado padronizado: pagamento vira crédito

Quando o Bacen padronizar o Pix Parcelado, o instrumento deixa de ser só liquidação e passa a carregar originação de crédito. Isso importa muito para o modelo de ameaças: entra fraude de originação, entra KYC como superfície de ataque, entra o golpe de engenharia social que convence a vítima a “parcelar” um valor que ela não deve. Times que hoje tratam Pix como transporte vão precisar herdar controles de crédito — análise, alçada, política, contestação.

Pix em garantia: recebíveis futuros como colateral

Usar recebíveis futuros de Pix como garantia de empréstimo cria uma nova classe de objeto sensível: o vínculo entre o fluxo futuro e o credor. Integridade e imutabilidade desse registro passam a ter valor econômico direto, e todo novo intermediário na cadeia de registro e trava é um novo elo — com tudo o que aprendemos sobre elos nos últimos dois anos.

Pix Internacional: dois modelos de confiança se encontrando

A ambição para 2027 é interligar o Pix a sistemas de pagamentos instantâneos de outros países. Toda ponte entre esquemas com modelos de confiança, requisitos de identidade e regimes de sanção diferentes é, historicamente, o lugar onde a fraude se instala — porque a diferença de premissas entre os dois lados vira ambiguidade, e ambiguidade vira exploração. Some a isso jurisdição, prevenção à lavagem, listas restritivas e resolução de disputa transfronteiriça.

Intermediários, split e duplicata: dinheiro sendo dividido dentro da mensagem

A agenda prevê especificações para identificar múltiplos recebedores numa mesma transação (o caso dos marketplaces), o split tributário separando automaticamente a parcela de tributos no momento do pagamento, a cobrança híbrida com QR obrigatório em boletos digitais e a duplicata liquidada via Pix.

Traduzindo para risco: lógica de divisão de valores passa a viver dentro da mensagem de pagamento. Todo lugar em que o sistema calcula percentuais, arredonda centavos e decide quem recebe o quê é um lugar onde manipulação de um único campo desvia dinheiro sem parecer uma fraude — parece um erro de cálculo. E erro de cálculo é a fraude que menos dispara alarme.

O campo de descrição, que ninguém trata como entrada não confiável

O Bacen já sinalizou que criará regras para inibir o uso do campo “Descrição” do Pix para ameaças e mensagens ofensivas. Do nosso lado, esse campo é o que sempre foi: entrada controlada pelo atacante que trafega entre instituições e chega a interfaces de terceiros. Injeção, XSS armazenado em painéis internos, phishing por conteúdo, abuso de canal. Se o seu extrato renderiza descrição sem sanitização, você tem um vetor.

IA nos dois lados do balcão

O Banco Central trabalha em ferramentas antifraude com inteligência artificial, indicador de probabilidade de fraude no Pix, alerta de golpe e melhorias no bloqueio cautelar. Do outro lado, deepfake já aparece em golpes de identidade e a automação reduz o custo marginal do ataque a quase zero. A corrida vai ser entre modelos, e o lado que perder será o que tiver pior telemetria — porque modelo bom com dado ruim é chute com sotaque estatístico.

O gráfico que ninguém desenha

Coloque num mesmo eixo duas curvas: a velocidade com que a superfície do Pix cresce (agenda evolutiva do Bacen, trimestre a trimestre) e a velocidade com que a maturidade de segurança do seu time cresce (sprints com item de segurança entregue). Se a primeira sobe mais rápido que a segunda, você não está estagnado — está regredindo em termos relativos, que é o único termo que importa quando existe um adversário.

Pense comigo

Quando o Pix Automático entrou no roadmap da sua empresa, quem escreveu o modelo de ameaças do mandato de consentimento? Quem definiu escopo, revogação, proteção contra replay e trilha de auditoria da autorização?

Se a resposta for “ninguém, a gente implementou a especificação”, esse é o próximo ticket. Especificação define o que o sistema deve fazer. Modelo de ameaças define o que ele não pode permitir — e é sempre a segunda lista que o atacante lê.

Para fechar: o ataque não começou num terminal

Volto ao bar no Jaraguá, porque é ali que está a lição.

O maior ataque cibernético da história do sistema financeiro brasileiro começou com uma conversa de calçada e R$ 5 mil em espécie entregues por um motoboy. Não começou com um exploit. Começou com uma pergunta — “você trabalha no TI?” — feita a uma pessoa cujo nível de acesso tinha sido definido por conveniência.

Entre aquela conversa e as contas reserva no Banco Central havia uma distância inteira de sistema: autenticação, autorização, segregação, limites, integridade, trilha, detecção, contenção. Cada uma dessas camadas era uma chance de transformar R$ 800 milhões em um alerta de madrugada. Cada uma delas foi, em algum momento, um card que alguém priorizou ou despriorizou.

É por isso que insisto: segurança em pagamentos não é um departamento, é uma propriedade emergente do jeito como o sistema foi construído. Ela emerge de decisões pequenas, tomadas por gente como nós, em reuniões que ninguém lembra, sobre coisas que pareciam detalhes de implementação.

Três perguntas para levar para a segunda-feira:

1. Qual é o teto de dano de uma credencial legítima comprometida no seu sistema, expresso em reais? Se você não sabe o número, esse é o primeiro trabalho.

2. Quanto tempo entre o primeiro comportamento anômalo e o primeiro humano acionado? Se a resposta depende de um relatório matinal, você está fazendo arqueologia.

3. Onde está o ponto único em que um ator fecha o ciclo sozinho — originar, aprovar, liquidar? Ele existe. Ele sempre existe. A questão é se você o encontrou antes.

O Bacen fez a parte dele: transformou dano real em norma verificável, e norma verificável em prazo. Os criminosos fizeram a parte deles: profissionalizaram o recrutamento, mapearam a cadeia de fornecedores e descobriram que o elo mais fraco quase nunca é apenas o banco. Mas sim humano.

Fico por aqui neste artigo e até o próximo! ❤️

---

Fontes e leituras

• Banco Central do Brasil — Resoluções BCB nº 493, 494, 495, 496, 497, 498, 501, 505, 506, 507, 517, 518, 538 e 547; Resoluções CMN nº 4.893, 5.251, 5.261 e 5.274; Instruções Normativas BCB nº 589 e 661.

• Banco Central do Brasil — 63ª Ata do Comitê de Estabilidade Financeira (Comef), novembro de 2025, sobre dependência de terceiros e uso disseminado de APIs.

• Finsiders Brasil — “Um ano após ataque à C&M: o que mudou na segurança do setor financeiro?” e “BC alerta para uso disseminado de APIs no setor financeiro”.

• Grant Thornton Brasil — análise dos controles mínimos da Resolução CMN nº 5.274/2025 e da Resolução BCB nº 538/2025.

• Evertec — comunicado à SEC sobre o incidente no ambiente Pix da Sinqia (agosto de 2025).

• CNN Brasil, Estadão/IstoÉ Dinheiro, Seu Dinheiro, InfoMoney, Exame e Agência Brasil — cobertura dos casos C&M Software, Sinqia, Banco do Nordeste e Operação Cofre Digital.

• IBM Trusteer e Cleafy — análises técnicas do PixPirate e da geração de trojans Android com capacidade ATS.

• Kaspersky — relatório sobre o trojan GoPix e substituição de chaves Pix e códigos de boleto no navegador.

• ACI Worldwide e GlobalData — Relatório Scamscope, projeções de perdas com fraudes em pagamentos em tempo real.

• OWASP — API Security Top 10 e Application Security Verification Standard (ASVS).

1. As contas reservas Pix são mantidas por instituições financeiras diretamente no Banco Central (BC). Seu propósito principal é a compensação e liquidação de operações dentro do Sistema de Pagamentos Brasileiro (SPB). Pense nelas como um grande “caixa” central onde os bancos depositam recursos para garantir que todas as transações, incluindo aquelas feitas via Pix, sejam processadas de forma eficiente e segura.

2. Virtual Private Cloud

3. De onde vem o HSM

A analogia mais fiel é a de um cartório com um carimbo oficial trancado num cofre que não abre. Você nunca pega o carimbo emprestado: entrega o documento pela portinhola, alguém carimba lá dentro e devolve o documento carimbado. Se um ladrão invade a sala, ele até consegue carimbar alguns documentos enquanto está lá — mas não leva o carimbo embora para carimbar o que quiser, para sempre. É essa a diferença entre uma chave em HSM e uma chave num arquivo: com o arquivo, o atacante copia o carimbo e vai embora; com o HSM, ele perde tudo no instante em que você fecha a porta.

A origem é apropriada à história deste artigo. O HSM nasceu em 1972, das mãos do engenheiro egípcio-americano Mohamed Atalla — o mesmo que coinventou o transistor MOSFET, base de toda a eletrônica moderna. O aparelho, apelidado de “Atalla Box”, foi criado para um problema idêntico ao que discutimos aqui: proteger o segredo que move dinheiro. Ele cifrava as senhas (PINs) e as mensagens dos primeiros caixas eletrônicos, isolando as chaves do sistema operacional que as usava. Atalla ficou conhecido como “o pai do PIN”, e suas caixas chegaram a proteger a maioria das transações de ATM do mundo. Meio século depois, o princípio é o mesmo — a chave nasce no hardware e nunca sai. O que mudou foi o tamanho do rombo quando alguém ignora isso.

4. O acrônimo STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS) e Elevation of Privilege) é uma abordagem sistemática à segurança que ajuda as equipes de desenvolvimento a pensar como invasores para proteger seus sistemas antes que ocorram violações.

5. A principal diferença entre SAST e SCA reside no foco: o SAST analisa o código-fonte de uma aplicação em busca de vulnerabilidades de segurança no código proprietário, enquanto o SCA (Software Composition Analysis) busca vulnerabilidades em bibliotecas de terceiros e componentes de código aberto. O SAST ajuda a identificar falhas de codificação, enquanto o SCA visa os riscos provenientes de dependências, garantindo a segurança tanto do código personalizado quanto do código externo.

6. Sink é o ponto onde um dado que veio de fora é consumido por uma operação com poder de causar dano — executar código, avaliar expressão, instanciar objeto, fazer requisição, acessar arquivo ou montar consulta.