Segurança de memória agora é uma questão de segurança nacional — por que EUA e UE querem que desenvolvedores parem de escrever em C

Em fevereiro de 2024, a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) publicou um relatório de 19 páginas intitulado "The Case for Memory Safe Roadmaps". O Gabinete do Diretor Cibernético Nacional da Casa Branca seguiu com um relatório técnico instando os fabricantes de software a eliminar vulnerabilidades de segurança de memória. O Centro Nacional de Segurança Cibernética do Reino Unido, o BSI da Alemanha e a Diretoria de Sinais da Austrália o assinaram em conjunto. A mensagem das cinco agências foi idêntica: parem de escrever software crítico para a segurança em C e C++.

Esta não é uma posição marginal entre acadêmicos que preferem Haskell. É a política de segurança coordenada das principais agências de inteligência e segurança cibernética do mundo, apoiada por duas décadas de dados de vulnerabilidades, e está começando a mudar o que realmente é enviado de software.

O que significa segurança de memória

Segurança de memória é a propriedade de que um programa não pode ler ou escrever memória fora dos limites pretendidos, acessar memória liberada ou usar valores não inicializados. As linguagens impõem segurança de memória seja por meio de garbage collection (Java, Python, Go) ou por regras de ownership estático aplicadas em tempo de compilação (Rust). C e C++ não fornecem nenhuma delas: o programador é responsável por gerenciar a memória corretamente, e o compilador não verifica a correção.

A consequência é uma classe de bugs que persiste desde a criação de C em 1972: estouros de buffer, vulnerabilidades de use-after-free, desreferência de ponteiro nulo, corrupção de heap e confusão de tipo. Não são casos extremos exóticos — são a classe de vulnerabilidade mais explorada na natureza, respondendo consistentemente por 60-70% dos CVEs críticos em grandes projetos de software.

O Centro de Resposta de Segurança da Microsoft relatou em 2019 que aproximadamente 70% de todos os CVEs em produtos Microsoft nos 12 anos anteriores eram problemas de segurança de memória. O Project Zero do Google relatou em 2020 que 67% dos bugs de alta gravidade do Chrome eram relacionados à segurança de memória. Ambos os números permaneceram teimosamente consistentes até 2026, apesar de investimentos significativos em ferramentas (fuzzing, sanitizers, análise estática) — porque o problema subjacente é o próprio modelo da linguagem, não a qualidade insuficiente dos programadores que a utilizam.

A escala do problema herdado

A gravidade da situação atual é uma função de quanto da infraestrutura crítica roda em código C. O kernel Linux — a base da maioria dos servidores, dispositivos Android, hardware IoT e sistemas embarcados — é aproximadamente 97% C. A biblioteca OpenSSL que protege a maior parte do tráfego HTTPS é C. SQLite, o banco de dados mais implantado do mundo, é C. O motor JavaScript V8 que executa metade da navegação web mundial é C++. Os kernels Windows, macOS e iOS contêm dezenas de milhões de linhas de C e C++.

Reescrever qualquer um deles não é um projeto de vários meses. O kernel Linux tem aproximadamente 30 milhões de linhas de código, com contribuidores de milhares de organizações e um processo de mudança que se move a uma velocidade geológica por design. A base de código do Google Chrome tem 40 milhões de linhas. Perguntar "por que não reescrever em Rust?" não entende a escala: a uma taxa de reescrita de 1 milhão de linhas por ano por equipe, uma reescrita completa da base de código leva décadas e introduz novos bugs a cada passo.

A abordagem prática é a substituição incremental: reescrever primeiro os componentes de maior risco (análise sintática, manipulação de entrada de rede, criptografia), usar a interoperabilidade de linguagens para executar módulos Rust junto com C, e aceitar que o substrato C legado existirá por 20-30 anos enquanto é progressivamente isolado.

A trajetória do Rust

Rust, lançado pela primeira vez em 2015 pela Mozilla, é a principal linguagem de sistemas segura em memória sendo adotada para essa transição. Seu sistema de tipos de ownership e borrowing previne toda a classe de bugs de segurança de memória em tempo de compilação, sem overhead de garbage collection e com desempenho próximo ao C. A desvantagem é uma curva de aprendizado íngreme: o compilador Rust rejeita código que um compilador C aceitaria, porque o compilador Rust prova uma correção que C deixa para o programador.

A curva de adoção agora é suficientemente íngreme para representar uma mudança estrutural. O Google reescreveu partes significativas das pilhas Bluetooth e WiFi do Android em Rust; a equipe Android relatou em 2024 que o novo código em linguagens seguras em memória reduziu a taxa de CVEs de segurança de memória para esses componentes a quase zero, enquanto os componentes C legados mantiveram sua taxa histórica de vulnerabilidade. O kernel Linux aceitou formalmente Rust como uma segunda linguagem de implementação em 2022, e os primeiros drivers Rust foram mesclados ao kernel principal.

A equipe Windows da Microsoft está reescrevendo componentes do kernel Windows em Rust, com o objetivo de longo prazo de evitar que novos bugs de segurança de memória entrem na base de código do kernel. O guia da NSA de 2022 nomeou especificamente Rust, Swift, Go, Kotlin e Java como linguagens preferidas para novos desenvolvimentos em contextos de segurança nacional. A Lei de Ciberresiliência da UE, que entrou em vigor em 2025, exige que fabricantes de produtos com elementos digitais demonstrem práticas "seguras por design" — uma linguagem legal que implicitamente penaliza linguagens não seguras em memória em contextos críticos de segurança.

O que "memory safe" não resolve

O impulso político por linguagens seguras em memória é bem fundamentado, mas às vezes é supervalorizado. A segurança de memória previne uma classe específica de bugs — mas não previne erros lógicos, falhas de autenticação, vulnerabilidades de injeção ou erros de implementação criptográfica. Um programa Rust pode ter uma vulnerabilidade de injeção SQL tão facilmente quanto um programa C. Um programa Go pode ter um erro de lógica de negócios que permita escalonamento de privilégios. A segurança de memória é uma condição necessária para a segurança, não suficiente.

Há também uma distinção significativa entre Rust "safe" e "unsafe". A biblioteca padrão do Rust contém blocos unsafe — seções onde o programador desativa explicitamente as verificações de ownership para código crítico de desempenho. Essas regiões unsafe devem ser verificadas manualmente, e vulnerabilidades nelas são possíveis. Por exemplo, a condição de corrida CVE-2022-21658 na biblioteca padrão do Rust existia em uma implementação std::fs cuidadosamente revisada. Rust torna o código unsafe raro e altamente visível, mas não o elimina.

O argumento de desempenho contra linguagens seguras em memória foi amplamente resolvido empiricamente. Na maioria das cargas de trabalho, Rust tem desempenho dentro de 5-15% do código C equivalente, e em alguns benchmarks supera C porque o compilador pode fazer otimizações mais agressivas quando provou garantias de aliasing e tempo de vida. A sobrecarga restante ocorre principalmente em casos patológicos, não no tipo de código de sistema que lida com pacotes de rede, operações de sistema de arquivos ou análise de protocolo.

Os próximos dez anos

A pressão governamental está tendo efeitos mensuráveis. A iniciativa Secure by Design da CISA, lançada em 2023, coletou compromissos de mais de 200 grandes fornecedores de software para criar roadmaps de segurança de memória — planos concretos para migrar bases de código específicas para fora de C e C++ em um cronograma publicado. Os primeiros relatórios anuais de progresso desses fornecedores mostraram um movimento modesto, mas real: novos módulos em Rust, APIs inseguras obsoletas, migração de componentes de análise de alto risco.

O cronograma realista para reduzir significativamente as vulnerabilidades de segurança de memória em infraestruturas críticas é de 15 a 20 anos. O código escrito hoje em Rust estará em produção por décadas; o C legado ainda em execução será a fonte de vulnerabilidades críticas por um período equivalente. A questão política não é se fazer essa transição — as evidências são esmagadoras de que C e C++ criam risco de segurança inaceitável em escala — mas quão agressivamente impulsionar a velocidade da transição dados os custos de engenharia e os riscos de introduzir novos defeitos durante a migração.

O que mudou é que isso agora é uma questão política, não acadêmica. Quando a CISA chama algo de questão de segurança nacional e a Casa Branca assina um relatório técnico, os requisitos de aquisição e as regulamentações seguem. O impulso por trás da adoção de linguagens seguras em memória não é mais impulsionado apenas pela preferência do desenvolvedor — está sendo codificado em contratos governamentais, regras de responsabilidade de produtos da UE e requisitos de seguros. C e C++ continuarão em uso por décadas, mas sua posição como escolha padrão para novos sistemas críticos de segurança acabou.