A revolução silenciosa em sistemas embarcados ficou barulhenta. de acordo com um novo relatório de 2025 da RunSafe Security, 80,5% dos engenheiros integrados agora usam ferramentas de IA para escrever código, e impressionantes 83,5% implantaram esse código gerado por IA diretamente em ambientes de produção.
Em qualquer outro setor, esta seria uma vitória para a produtividade. Mas no mundo dos sistemas embarcados (onde o código controla bombas de insulina, armaduras industriais e sistemas de freios automotivos) isso representa uma terrível dissociação entre velocidade e validade.
O relatório, intitulado “IA em sistemas embarcados: a IA está aqui. A segurança não está” pinta o retrato de uma indústria em um perigoso ponto de inflexão. Os engenheiros estão escrevendo códigos mais rápido do que nunca, usando linguagens que nunca foram projetadas para serem seguras e implantando-os em hardware que não pode ser facilmente corrigido.
O aprofundamento técnico: Por que quebras de código ‘boas’
A qualidade do código não é a principal preocupação. LLMs geram sintaxe válida.
O problema é que C e C++ são linguagens inerentemente inseguras que exigem vigilância perfeita do desenvolvedor – algo que os modelos de IA, que são preditores probabilísticos de tokens, não podem garantir estruturalmente.
A lacuna de segurança da memória
Em um aplicativo moderno de alto nível (escrito em Python, Rust ou Go), o executor de linguagem lida com a alocação de memória. Você cria um objeto; o sistema encontra espaço. Você para de usar; o coletor de lixo o libera.
No C/C++ incorporado, você é o coletor de lixo. Você aloca memória manualmente (malloc) e a libera manualmente (free). Se você cometer um erro, não receberá apenas um erro; você cria uma vulnerabilidade.
O relatório RunSafe destaca que esta abordagem de “transmissão manual” está colidindo com a velocidade da IA. Quando uma IA gera um analisador de 50 linhas para um fluxo JSON, ela geralmente usa padrões C padrão e eficientes. Mas raramente considera o contexto do layout da memória.
- Buffer Overflows: A IA grava dados em um buffer sem verificar rigorosamente se os dados cabem. Em um aplicativo de desktop, isso trava o programa. Em um controlador incorporado sem uma MMU (Unidade de Gerenciamento de Memória), isso substitui o ponteiro de instrução e dá ao invasor o controle do dispositivo.
- Use-After-Free (UAF): A IA libera corretamente um ponteiro, mas deixa uma referência pendente para ele em outro lugar no código. Posteriormente, a lógica tenta acessar a memória liberada. Se um invasor pulverizou o heap com dados maliciosos, ele agora possui a execução.
O Multiplicador de Superfície de Ataque
As estatísticas do relatório são alarmantes por causa da área de superfície. 53% dos entrevistados citaram a segurança como sua principal preocupação, mas 91% estão aumentando o investimento em segurança integrada. Eles sabem que a onda está chegando.
O desenvolvimento tradicional atua como um regulador natural do volume de código. Um engenheiro humano só pode escrever algumas linhas de C++ por dia, e boas equipes revisam esse código. AI remove o acelerador. A indústria agora está inundando bases de código legadas com grandes quantidades de lógica nova e não verificada.
Se 1 em cada 10.000 linhas de código humano apresenta uma falha crítica de memória e a IA permite que os engenheiros escrevam 100.000 linhas no tempo que levavam para escrever 10.000, a indústria não apenas aumentou a produtividade; aumentou a densidade de vulnerabilidades latentes em uma ordem de grandeza.
História Contextual: O Padrão de Negligência
A indústria já viu esse filme antes, apenas em telas diferentes.
No início dos anos 2000, a fase “Conectar tudo” do boom da IoT levou ao botnet Mirai. Os fabricantes correram para colocar pilhas de IP em câmeras e DVRs sem pensar em senhas padrão ou portas telnet abertas. O resultado foi uma enorme infraestrutura DDoS construída a partir de torradeiras e webcams comprometidas.
Na década de 2010, a indústria automotiva correu para adicionar infoentretenimento e conectividade aos carros. O resultado foi o hack do Jeep Cherokee, onde os pesquisadores interromperam remotamente a transmissão de um veículo em uma rodovia porque o sistema de entretenimento poderia se comunicar com o barramento CAN.
Agora, em 2025, isso acontece novamente com a geração de código. O relatório RunSafe observa que 73% dos engenheiros classificam o risco do código de IA como “moderado ou superior”, mas os números de implantação (83,5%) mostram que eles estão procedendo independentemente.
A pressão económica para fornecer funcionalidades “inteligentes” (manutenção preditiva, processamento de IA de ponta, interfaces de voz) está a sobrepor-se à disciplina de engenharia necessária para assegurá-las.
A contramedida: Randomização da função em tempo de carregamento (LFR)
Se a confiança no código é impossível (porque há muito código) e reescrever 30 anos de C++ em Rust da noite para o dia é inviável, qual é a defesa?
O relatório aponta para Resiliência em tempo de execução. Se você presumir que o bug existe, você deve torná-lo inexplorável.
Uma das técnicas mais eficazes para isso no espaço incorporado é Load-time Function Randomization (LFR).
Como funciona
Em uma compilação de firmware padrão, cada função reside em um endereço estático e conhecido. calculate_voltage() pode estar sempre em 0x08001234.
Os invasores adoram isso. Para construir uma exploração (como Programação Orientada a Retorno, ou ROP), eles precisam saber exatamente para onde pular para executar o código que desejam. Eles encadeiam pequenos trechos de código existente (gadgets) para construir um programa malicioso.
LFR quebra essa cadeia.
- Tempo de compilação: O compilador emite código que não salta para endereços absolutos. Em vez disso, ele salta para um “esboço” ou tabela de pesquisa.
- Tempo de carregamento: quando o dispositivo é inicializado, o carregador seguro embaralha o baralho. Ele atribui aleatoriamente endereços de memória reais a todas as funções.
- Patching: O carregador atualiza a tabela de pesquisa ou corrige o binário na memória para que as chamadas ainda funcionem.
O resultado? Cada vez que o dispositivo é reinicializado (ou sempre que o firmware é atualizado, dependendo da implementação), o mapa de memória muda. Uma exploração que funciona no Dispositivo A irá travar o Dispositivo B. Uma exploração que funcionou ontem não funcionará após uma reinicialização.
A implementação proprietária dessa tecnologia pela RunSafe está ganhando força porque não requer a reescrita do código-fonte. Você o aplica no nível binário. Isso é crucial para 60% dos entrevistados que já estão tentando usar proteções de tempo de execução.
Análise prospectiva: a perspectiva de 5 anos
O relatório de 2025 é um retrato instantâneo de um período de transição. O setor está atualmente na fase de “Velho Oeste” de geração de código de IA.
Nos próximos cinco anos, são esperadas três grandes mudanças:
- A ascensão da segurança baseada em silício: Mitigações de software como LFR se tornarão efetivamente obrigatórias. Os regulamentos (semelhantes à Lei de Resiliência Cibernética da UE) provavelmente exigirão que os dispositivos de infraestrutura crítica possuam capacidades de randomização binária.
- A Transição Rust: Embora a IA escreva C++ facilmente, ela também escreve Rust facilmente. O atrito para mudar para linguagens seguras de memória diminuirá à medida que a IA lidar com o padrão. No entanto, isso protege apenas o novo código. Os bilhões de linhas do legado C/C++ permanecem.
- Mudança de responsabilidade: À medida que o código gerado por IA causa falhas físicas (por exemplo, um braço robótico balançando muito rápido, um sistema de gerenciamento de bateria falhando), a conversa jurídica mudará de “bugs de software” para “responsabilidade do produto”. Se um fabricante usou IA para gerar código crítico de segurança sem revisão humana ou proteção de tempo de execução, isso é negligência.
O resultado final
O relatório RunSafe Security 2025 não é apenas uma coleção de pesquisas; é um sinalizador de alerta. A indústria abriu a garrafa à produtividade da IA e não há como voltar atrás.
O grande volume de código produzido significa que a revisão manual é matematicamente impossível em grande escala. Não é mais possível fingir que todos os bugs podem ser detectados. O único caminho viável a seguir é assumir que o código está quebrado e construir sistemas que se recusem a deixá-lo quebrar a máquina.
Para o engenheiro embarcado em 2025, o trabalho não é mais apenas escrever C. É arquitetar os campos de contenção que impedem que C prejudique alguém.
Apêndice Matemático: A Probabilidade de Exploração
Modelar o valor do LFR requer o cálculo da probabilidade P de uma exploração bem-sucedida da cadeia ROP. Uma cadeia padrão requer k gadgets. Em um mapa de memória estática, a probabilidade de encontrar o gadget i em um local conhecido é 1.
A probabilidade de uma exploração estática é efetivamente de 100%.
Com LFR, se houver N locais possíveis (slots) para uma função e o invasor tiver 1 em N chance de adivinhar o deslocamento correto para cada gadget independente (modelo simplificado), a probabilidade cai aproximadamente para 1 dividido por N elevado à potência de k.
A probabilidade é efetivamente zero.
Mesmo com uma entropia modesta (N=256) e uma cadeia curta (k=3), a dificuldade dispara da certeza para uma em 16 milhões.
Fontes (6)
- runsafesecurity.com RunSafe Security Blog
- themanufacturingconnection.com The Manufacturing Connection
- vmblog.com VMblog 2025 Predictions
- runsafesecurity.com Medical Device Cybersecurity Index 2025
- news.mit.edu MIT News: Memory Safety Tipping Point
- appsecengineer.com Defending Memory Corruption
🦋 Discussão no Bluesky
Discutir no Bluesky