Smartmatic e urnas no Brasil: guia técnico de validação e auditoria

Quando Flávio Bolsonaro citou a Smartmatic como origem das urnas eletrônicas brasileiras e ainda jogou uma narrativa envolvendo um “relatório da CIA”, muita gente no Brasil interpretou isso como “prova técnica”. Na prática, não é. Segundo o BBC News, o TSE já desmentiu: a Smartmatic não forneceu urnas nem softwares usados nas eleições no país. E, como programador, eu olho para esse tipo de alegação com uma lente bem específica: quem controla o código, qual a cadeia de fornecimento, como a auditoria funciona e o que é verificável.

O ponto aqui não é “politizar tecnologia”. É entender como se constrói (e como se desmonta) uma história falsa quando ela tenta se apoiar em termos que soam técnicos: origem, software, empresa, relatório, fraude. E mais: quais implicações práticas isso tem para devs, engenheiros e designers de sistemas que precisam lidar com confiança, integridade e auditoria.

O que a Smartmatic é (e por que esse nome aparece em conversas sobre eleições)

A Smartmatic é uma empresa venezuelana que, em alguns países, foi associada ao fornecimento de componentes, serviços ou suporte para processos eleitorais — especialmente em contextos latino-americanos com histórico de disputas e contestação pública. Ou seja: o nome existe no ecossistema eleitoral, mas “ter algo a ver em um lugar” não significa automaticamente “ser a origem de todo o sistema em outro país”.

Segundo o BBC News, Flávio Bolsonaro afirmou que “muitas dessas máquinas” usadas no Brasil seriam da mesma empresa venezuelana, e complementou com a ideia de um relatório da CIA ligando a Smartmatic a um suposto plano de fraude nas eleições de 2012. O TSE, por sua vez, tratou isso como incorreto e publicou nota esclarecendo que a Smartmatic nunca forneceu urnas eletrônicas ou softwares usados em eleições no Brasil.

Por que devs devem se preocupar com “cadeia de fornecimento” (supply chain) e não só com nomes de empresas

Em engenharia de software, uma das armadilhas clássicas é tratar “quem vendeu” como “quem controla”. Para sistemas críticos, a pergunta real é:

Quem desenhou a arquitetura?
Quem implementou o software?
Quem mantém o repositório (ou a configuração) ao longo do tempo?
Quem audita?
Como se valida integridade do que foi produzido?
Como se garante independência entre fornecedor e verificação?

Se essas respostas não estão claras, a discussão vira teatro. E é exatamente isso que eu vejo acontecer: usa-se o termo “empresa” como se isso, por si só, indicasse comprometimento. Em tecnologia, isso não cola.

O que o TSE desmentiu (e o que esse desmentido significa tecnicamente)

Conforme destacado pelo BBC News, o TSE esclareceu em nota (publicada originalmente em 2020 e republicada/retomada) que:

A Smartmatic nunca forneceu urnas eletrônicas para o Brasil
Também não forneceu softwares utilizados nas eleições brasileiras
O projeto e o sistema são concebidos e geridos integralmente pela Justiça Eleitoral

Na minha experiência (e em ambientes regulados), esse tipo de nota importa porque tenta fixar o perímetro de responsabilidade. Se a “origem do sistema” é gerida pelo próprio órgão, então a hipótese “é tudo da Smartmatic” deixa de ser uma inferência e vira uma afirmação desmentida por autoridade responsável.

Mas atenção: isso não elimina a necessidade de auditoria. Só muda o foco: o que você audita não é “a empresa X”, e sim o processo de desenvolvimento, homologação, validação e operação.

Comparando com alternativas reais: o que seria “software de votação comprometido” na prática?

Quando alguém fala em fraude por “software”, normalmente está insinuando algo como:

alteração de código para manipular registro de votos;
troca de comportamento apenas sob condições específicas;
inserção de backdoor em cadeia de build/deploy;
falsificação de logs/auditoria;
manipulação de integridade na compilação ou no carregamento.

Agora compare isso com sistemas reais de alta criticidade. Para um ataque desses funcionar, você precisa superar múltiplas barreiras:

controle do pipeline de build;
comprometimento de chaves/assinaturas;
capacidade de manter consistência de verificações independentes;
evitar detecção por auditorias externas;
persistência sem criar sinais estatísticos ou operacionais.

O motivo de eu insistir nisso: narrativas “CIA + empresa X + fraude” costumam pular do “alguém pode ter feito algo em algum lugar” para “logo está acontecendo aqui”, sem passar pelos mecanismos técnicos que tornariam isso verificável e sustentável.

Onde a história tende a enganar (e como devs caem na armadilha)

Alguns erros comuns que eu já vi devs cometendo em discussões desse tipo:

Confundir presença de tecnologia com identidade de software: “tem componente do mesmo fornecedor” não implica “mesmo código”.
Ignorar ciclo de vida: até que ponto o hardware e o software são os mesmos ao longo do tempo?
Assumir que auditoria inexistente: muitas vezes existe algum nível de validação pública/externa, mesmo que não seja “aberta” no sentido de código no GitHub.
Tratar “relatório” como “prova local”: mesmo que um documento exista, ele precisa se conectar ao sistema específico, versão específica, processo específico.

Na Prática: como eu validaria (do ponto de vista de engenharia) uma alegação dessas

Mesmo sem acesso ao código-fonte do TSE, eu consigo desenhar um roteiro técnico para avaliar plausibilidade e reduzir achismo. Esse é o tipo de abordagem que eu uso quando leio alegações com cara de “infotécnico” e quero verificar consistência.

Delimitar o alvo: qual afirmação exatamente? “Urnas” (hardware), “software” (aplicação), “infra” (servidores), “captação” (atualização/armazenamento) — tudo isso muda a superfície de ataque.
Mapear cadeia de fornecimento: quem concebeu, quem implementou, quem opera, quem audita. Se o órgão responsável afirma controle integral, o ônus da prova da alegação externa aumenta.
Verificar compatibilidade: “mesma empresa” pode significar muitas coisas (licença, assistência, fornecimento parcial). Sem especificar contrato, versão e escopo, vira slogan.
Checar existência de verificações: sistemas críticos normalmente têm mecanismos de validação de integridade e procedimentos de auditoria.
Buscar sinais públicos: documentos oficiais, notas técnicas, publicações sobre arquitetura, detalhes operacionais que permitam confronto com a alegação.
Aplicar raciocínio de custo do ataque: um backdoor persistente tende a deixar rastros; “ataque milagroso” quase sempre é retórica.

Exemplo prático de mentalidade de dev: quando alguém diz “o software foi alterado”, eu não aceito “ah, foi possível” como evidência. Eu procuro evidência de mudança verificável: versão, assinatura, hash, reprodutibilidade. Em sistemas de software, a diferença entre “suspeita” e “prova” muitas vezes é um artefato verificável.

Um mini-exemplo de verificação por hash (para ilustrar integridade)

Em projetos reais, integridade costuma ser checada por hashes/assinaturas. Em auditorias (inclusive de artefatos), um padrão é comparar hash esperado vs hash observado. Por exemplo:

import { createHash } from "node:crypto";
import { readFileSync } from "node:fs";

function sha256(filePath) {
  const data = readFileSync(filePath);
  return createHash("sha256").update(data).digest("hex");
}

const expected = process.env.EXPECTED_SHA256; // valor de referência
const actual = sha256("./build/artifact.bin");

if (!expected) {
  throw new Error("Defina EXPECTED_SHA256 para comparar.");
}

if (actual !== expected) {
  throw new Error(`Integridade falhou. expected=${expected} actual=${actual}`);
}

console.log("Integridade OK");

O motivo desse “porquê” é simples: sem mecanismo verificável de integridade, você fica refém de narrativas. E em sistemas críticos, qualquer alegação séria deveria apontar qual controle foi burlado e como isso seria detectável/confirmável.

Erros Comuns: o que evitar quando você lê (ou publica) alegações tecnológicas

Se você é dev e quer sair da conversa rasa (ou evitar propagar desinformação), aqui vai um checklist bem objetivo.

O que evitar

Repetir “origem” sem escopo: origem de quê? hardware? firmware? software de aplicação? sistema de backend?
Confundir analogia com evidência: “em outro país ocorreu fraude” não prova que “aqui ocorre”.
Tratar fonte não verificável como verdade: relatórios mencionados sem contexto local viram “fumaça”.
Ignorar desmentido institucional: se o órgão responsável negou, você precisa trazer informação adicional que contradiga com precisão.
Ficar no “quem” e esquecer o “como”: ataques reais precisam de caminho técnico. Sem isso, é só narrativa.

O efeito prático disso no seu dia a dia

Quando esse tipo de conteúdo entra na sua timeline, ele tende a afetar decisões erradas:

pessoas pressionam por mudanças “por causa do fornecedor” em vez de exigir auditoria do processo;
equipas de produto/segurança perdem tempo discutindo culpados, não controles;
decisões de engenharia são tomadas com base em “parece que” em vez de em evidência técnica.

Como dev sênior, eu prefiro sempre voltar ao que é verificável: controles de integridade, isolamento de responsabilidades, auditoria, e rastreabilidade de artefatos.

FAQ

Smartmatic fornecer “algo” para eleições em outros países significa que forneceu para o Brasil?

Não necessariamente. Segundo o TSE citado pelo BBC News, a Smartmatic não forneceu urnas nem softwares usados nas eleições do Brasil. Mesmo que a empresa tenha presença em outros contextos, o escopo importa.

Se alguém cita “relatório da CIA”, isso é prova automática?

Não. Para ser relevante, o relatório teria que conectar claramente o conteúdo alegado ao sistema brasileiro específico (versão, cadeia de fornecimento, controles que seriam burlados e como isso foi detectado/confirmado).

Como dev eu posso avaliar esse tipo de alegação sem acesso ao código?

Você avalia por escopo (hardware x software x infra), cadeia de responsabilidade, existência de auditorias e presença de artefatos verificáveis. Quando não há “como” técnico, costuma sobrar só retórica.

O desmentido do TSE elimina qualquer debate sobre segurança?

Não. Ele elimina a afirmação específica de fornecimento por parte da Smartmatic. O debate válido passa a ser sobre como o sistema é auditado, quais controles existem e como a integridade é garantida.

Conclusão

Na minha experiência com sistemas críticos, o que define confiança não é o nome de uma empresa repetido em um discurso. É a cadeia de desenvolvimento, os controles de integridade, o desenho de auditoria e a responsabilidade técnica. Segundo o BBC News, o TSE já afirmou que a Smartmatic não forneceu urnas nem softwares usados nas eleições brasileiras, então a alegação de “mesma origem” do sistema não se sustenta.

Se você quiser ir além do tiroteio político, trate isso como um exercício de engenharia: peça escopo, peça evidência verificável e peça o “como”. É assim que a gente protege tecnologia de virar só combustível para narrativa.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.