Quando se fala em violações de segurança cibernética, a maior parte da atenção do público se concentra nos hackers — e não nos engenheiros de software. No entanto, a história tem mostrado que as violações mais devastadoras muitas vezes se originam justamente do código em que confiamos para proteger nossos sistemas mais sensíveis. A verdade incômoda é esta: se você não pode ver o código-fonte e não pode verificar a integridade e a origem das pessoas que o criaram, não pode ter certeza de que ele está livre de backdoors.
O software de código fechado, por sua própria natureza, exige confiança — não apenas no fornecedor, mas em cada pessoa que já contribuiu para sua base de código. Em setores como defesa, inteligência, finanças e outras indústrias regulamentadas, a confiança cega não é mais aceitável. Precisamos de uma política rígida: qualquer fornecedor de software de código fechado que venda para infraestruturas críticas deve ser obrigatório para atestar que nenhum de seus desenvolvedores jamais trabalhou para um serviço de inteligência ou de defesa estrangeiro, especialmente na área de segurança cibernética, o que poderia permitir que implantassem vulnerabilidades ocultas.
Isso não é paranóia — é reconhecimento de padrões. A história da espionagem cibernética de alto impacto está repleta de exemplos em que agentes sofisticados introduziram backdoors de maneiras praticamente indetectáveis até que o dano já estivesse feito.
Estudo de caso 1: A porta dos fundos do NetScreen / ScreenOS (Juniper Networks)
No final de 2015, a Juniper Networks revelou que um código não autorizado havia sido inserido em seu sistema operacional de firewall ScreenOS — o software responsável pela segurança das redes do governo dos EUA, de empresas contratadas pelo setor de defesa e de empresas da Fortune 500. Não se tratava de um bug causado por negligência. Trata-se de uma modificação implantada com precisão cirúrgica no gerador de números aleatórios Dual_EC_DRBG, o que efetivamente deu ao invasor a capacidade de descriptografar o tráfego de VPN à vontade.
Posteriormente, pesquisadores de segurança concluíram que a explicação mais plausível era que o backdoor tivesse sido adicionado intencionalmente por um serviço de inteligência altamente capacitado. O código era de código fechado, e sua invasão passou despercebida por anos.
Conclusão principal: O código-fonte fechado permitiu que um funcionário com acesso privilegiado (ou ex-funcionário) alterasse funções criptográficas essenciais, o que era praticamente impossível de ser detectado pelos clientes.
Estudo de caso 2: Solarigate / Violação do SolarWinds Orion
O ataque à cadeia de suprimentos da SolarWinds em 2020 — apelidado de “Solarigate” — foi uma obra-prima de discrição. Os invasores comprometeram o sistema de compilação da plataforma de monitoramento de rede Orion, injetando um backdoor que foi assinado digitalmente e distribuído como parte de atualizações legítimas de software. Milhares de clientes instalaram o software, incluindo o Departamento de Segurança Interna dos EUA, várias agências federais e empresas contratadas pelo setor de defesa.
Não se tratava de uma operação amadora; era um ataque patrocinado pelo Estado, com recursos consideráveis, projetado para se misturar ao comportamento normal do software. A base de código do Orion era fechada, o processo de compilação era opaco e o ponto de inserção era controlado por pessoas de confiança dentro da organização.
Conclusão principal: Na ausência de auditoria aberta, a integridade do software de código fechado depende inteiramente da confiabilidade e do histórico das pessoas envolvidas na cadeia de desenvolvimento e compilação.
Estudo de caso 3: Incidente com rootkit no JPMorgan Chase
Em 2014, o JPMorgan Chase sofreu uma das maiores violações de segurança da história do setor bancário dos EUA, com o roubo de dados pessoais de mais de 83 milhões de clientes. As investigações revelaram que os invasores haviam alcançado um alto nível de persistência, utilizando acesso do tipo rootkit para manter o controle e evitar a detecção. Embora o ataque tenha envolvido várias etapas e participantes, ele destacou que, uma vez que os invasores consigam implantar ganchos de baixo nível, eles podem manipular dados, interceptar transações e contornar os controles de segurança padrão.
Embora o JPMorgan não tenha confirmado publicamente se o rootkit teve origem em uma infiltração na cadeia de suprimentos ou em um vazamento por parte de alguém de dentro da empresa, o incidente ressalta que os componentes de código fechado na infraestrutura bancária são alvos principais para modificações furtivas e persistentes.
Conclusão principal: No setor financeiro e em setores regulamentados, uma única porta dos fundos oculta em um módulo de código fechado pode comprometer bilhões de dólares investidos em defesas de segurança e anos de trabalho de conformidade.
Padrões revelados:
Atrasos na detecção ao longo de vários anos são comuns — mesmo em organizações com SOCs avançados.
Configurar ambientes de compilação e atualizar servidores são pontos-chave de inserção para atores estatais.
O código-fonte fechado oculta alterações maliciosas de forma muito mais eficaz do que os equivalentes de código aberto.
Sistemas financeiros e de segurança nacional de alto valor são alvo constante de ataques.
A lacuna nas políticas: a origem dos desenvolvedores é uma questão de segurança nacional
Temos controles rigorosos de exportação no setor de criptografia, restrições à importação de equipamentos de telecomunicações provenientes de nações adversárias e regimes de certificação para as cadeias de suprimentos de hardware. No entanto, temos nenhuma medida de salvaguarda equivalente para garantir que as pessoas que escrevem e compilam código-fonte fechado para infraestruturas críticas não tenham sido treinadas por — ou trabalhado para — serviços de inteligência estrangeiros conhecidos por operações cibernéticas ofensivas.
A Unidade 8200 em Israel, as unidades cibernéticas do GRU e do SVR na Rússia, a Unidade 61398 do Exército Popular de Libertação (PLA) na China e outras divisões cibernéticas ofensivas em todo o mundo possuem históricos bem documentados de desenvolvimento e implantação de backdoors tanto em sistemas abertos quanto fechados. Se um fornecedor contratar um desenvolvedor com esse histórico — sem divulgar ou mitigar o risco —, os clientes não terão como saber que estão potencialmente confiando em código escrito por alguém que foi explicitamente treinado para inserir vulnerabilidades indetectáveis.
A afirmação ousada: sem certificação, não há implantação
As infraestruturas críticas nos setores de defesa, inteligência e setores regulamentados devem recusar-se a implantar qualquer software de código fechado, a menos que o fornecedor apresente uma certificação vinculativa que:
Nenhum código do produto foi desenvolvido, compilado ou revisado por qualquer pessoa que já tenha trabalhado para uma organização estrangeira de inteligência ou defesa em funções relacionadas à segurança cibernética, inteligência de sinais ou exploração de redes.
O fornecedor mantém uma verificação contínua de antecedentes de todos os colaboradores da base de código fechada.
O software é submetido a verificações periódicas de integridade no nível binário por um laboratório de segurança independente, sediado nos Estados Unidos e com autorização governamental.
Não se trata de xenofobia ou protecionismo — trata-se da realidade operacional. Os incidentes envolvendo backdoors na Juniper, na SolarWinds e em inúmeras outras empresas demonstraram que a cadeia de desenvolvimento é uma superfície de ataque à segurança nacional. Já restringimos o acesso físico a locais críticos e às cadeias de suprimentos de hardware; é hora de aplicar o mesmo rigor às pessoas que escrevem e compilam o código que executa esses sistemas.
Conclusão: Confie, mas exija a proveniência
No campo de batalha cibernético moderno, a linha que separa a defesa do ataque é tênue, e muitos dos melhores engenheiros do mundo já atuaram em ambas as funções. No caso de aplicativos de consumo não regulamentados, talvez esse seja um risco aceitável. Mas e no caso do software que controla sistemas de comando nuclear, satélites de defesa, câmaras de compensação financeira e controle de tráfego aéreo? Não é.
O software de código fechado é uma caixa preta — e a história já mostrou que as caixas pretas podem esconder facas bem afiadas. Até que exijamos garantias verificáveis sobre quem desenvolveu o código, toda implantação é um ato de fé cega. Para infraestruturas críticas, a fé cega não é uma estratégia de segurança.