Poucos engenheiros de segurança: automação, IA e SOP limpo

Não há gente suficiente para fazer esse trabalho. Esse é o fato desconfortável por trás da cibersegurança automotiva, e ele está piorando, não melhorando.

A conta não fecha

Os estudos de força de trabalho da ISC2 colocam o déficit global de cibersegurança na casa dos milhões, cerca de 4,8 milhões pela estimativa de 2026, com a área precisando crescer aproximadamente 87% para atender à demanda. Cerca de 90% das equipes de segurança relatam uma lacuna de competências.

Agora restrinja isso ao setor automotivo. Testar uma ECU não é segurança de TI genérica. Exige pessoas que conhecem CAN e CAN FD, UDS e DoIP, SecurityAccess, sessões de diagnóstico e as restrições de tempo real de um alvo embarcado, e que consigam mapear tudo isso para a ISO/SAE 21434. É um subconjunto minúsculo e sobrecarregado de uma área que já é escassa. Enquanto isso, o mercado de cibersegurança automotiva cresce rápido, de cerca de quatro bilhões de dólares em 2026 rumo a doze bilhões ou mais no início da década de 2030. A demanda sobe um penhasco enquanto o grupo de pessoas que realmente consegue testar uma unidade de controle mal se move.

Depois conte o trabalho. Um programa de veículo moderno tem dezenas de ECUs. Cada uma tem muitas releases no caminho até a produção, e mais depois dela. Se o teste de segurança aprofundado depende de reservar um de um punhado de especialistas para cada release de cada ECU, a fila é mais longa que o programa. Alguma coisa cede, e geralmente é o teste.

O SOP é um muro em que você só bate uma vez

O início de produção não se move. Quando um veículo chega ao SOP, o custo de um defeito de segurança muda por completo: o que antes do início da linha era um comentário de code review vira, depois, uma campanha de campo ou um recall. E sob a UN R155 e a ISO/SAE 21434 você não pode simplesmente entregar e torcer. Você precisa demonstrar que as mitigações foram testadas e que os problemas conhecidos foram tratados.

Então o alvo real é específico: chegar ao SOP sem achados fáceis conhecidos. Não uma ECU perfeita, que ninguém pode prometer, mas uma em que os achados óbvios, de alto impacto e de primeira hora sumiram e estão documentados. Serviços de diagnóstico acessíveis sem autenticação. SecurityAccess fraco ou padrão. XCP ou CCP expostos. Identificadores graváveis que deveriam estar bloqueados. Eles são comuns, são devastadores e são completamente evitáveis, se alguém testar cada release em busca deles.

Essa última condição é o problema inteiro. Um único pentest antes do SOP é um instantâneo do software que você tinha naquela semana. A ECU continua mudando. Uma funcionalidade adicionada dois sprints depois reabre silenciosamente um serviço, e ninguém testa de novo até a próxima auditoria, quando ele já está no carro.

Você não consegue contratar para sair disso. Você consegue multiplicar

O instinto é contratar mais especialistas. É o instinto certo e não é suficiente, porque as pessoas não estão lá para serem contratadas, e nem mesmo uma equipe dobrada consegue retestar manualmente cada release de cada ECU.

É aqui que IA e automação mudam a economia unitária, e vale ser preciso sobre como. A IA não vai fechar a lacuna de competências sozinha, e quem disser que ela substitui os seus engenheiros de segurança está vendendo alguma coisa. O que ela faz, e faz bem, é elevar o nível da equipe que você já tem: codificar o que um bom testador faz à mão em motores que rodam sem ele, para que os humanos escassos sejam gastos no trabalho que só humanos conseguem fazer.

Concretamente, o conhecimento de como enumerar uma pilha UDS, sondar o SecurityAccess, fazer fuzzing de uma interface com segurança ou percorrer um gateway DoIP é estável e repetível. Ele não precisa de um especialista presente toda vez. Precisa de um especialista uma vez, para construir o teste, e depois de uma máquina para rodá-lo em cada release para sempre. O especialista fica então livre para o caminho de ataque novo, a TARA, aquilo que a automação não consegue imaginar.

Como isso funciona em um programa real

É exatamente para isso que o AutoST foi construído. Seus motores carregam o conhecimento de teste: enumeração UDS, análise de SecurityAccess (0x27), fuzzing UDS e CAN, DoIP e SOME/IP, Android IVI. Você conecta a ECU a uma bancada uma vez e, a partir daí, o AutoST roda pela API e no CI.

Assim o teste sai de “um especialista, se houver um livre, antes da auditoria” para “automaticamente, em cada release principal”. Cada build de cada ECU recebe a mesma passagem básica de segurança. Os achados fáceis são capturados no momento em que são introduzidos, não descobertos no carro. No SOP você tem um rastro datado mostrando que cada release foi testada e que os problemas conhecidos foram fechados, que é também exatamente o que um avaliador ISO/SAE 21434 quer ver.

E o punhado de engenheiros de segurança que você tem para de gastar suas horas escassas reencontrando o mesmo SecurityAccess fraco na quadragésima ECU. Eles as gastam nos ataques que realmente precisam de um humano.

A versão honesta

A automação não torna os engenheiros de segurança desnecessários. Ela faz com que os que você tem contem. O AutoST cuida da amplitude e da regressão para que uma equipe pequena cubra um programa de veículo inteiro e chegue ao SOP sem achados fáceis conhecidos. A profundidade, a criatividade, a TARA e a auditoria ainda precisam de pessoas, e a Zyberum traz isso também, como uma equipe que já conduziu programas de Tier 1, Tier 2 e OEM exatamente por isso. Referências disponíveis mediante solicitação.

Se o seu programa tem mais ECUs do que engenheiros de segurança, o que vale para quase todos, essa lacuna é o problema que o AutoST foi feito para fechar. Agende uma demo e nós mostraremos como é, na prática, testar cada release.