Ferramentas de análise estática para C e C++ embebido (2026)

1. ~70%

   Durante mais de uma década, cerca de 70% das CVE atribuídas anualmente pela Microsoft foram defeitos de segurança de memória. A maior parte desse código era C e C++.

   Fonte: Microsoft Security Response Center, 2019

2. 70% de 912

   Uma amostra reuniu 912 falhas de segurança do Chrome, de gravidade alta e crítica, desde 2015. Cerca de 70% eram falhas de segurança de memória em C e C++. Cerca de metade destas eram casos de uso após libertação.

   Fonte: The Chromium Projects, memory safety

3. 76% → 24%

   As falhas de segurança de memória passaram de 76% das vulnerabilidades do Android em 2019 para 24% em 2024. O valor de 2024 é uma projeção para o ano completo. O código novo passou para linguagens com segurança de memória; o C e C++ existente manteve-se.

   Fonte: Google Online Security Blog, setembro de 2024

4. 7 de 25

   Sete entradas do CWE Top 25 de 2025 são defeitos de memória e de ponteiros. As ferramentas SAST para C e C++ procuram estas sete classes. Incluem escrita fora dos limites (#5), uso após libertação (#7), leitura fora dos limites (#8) e desreferência de ponteiro NULL (#13). As outras três são transbordos de buffer: clássico (#11), na stack (#14) e na heap (#16).

   Fonte: MITRE, 2025 CWE Top 25

5. 143 + 16

   A primeira edição de MISRA C:2012 tem 143 regras e 16 diretivas. As emendas 1 e 2 elevam esse total para 158 regras e 17 diretivas. As ferramentas verificam regras e algumas diretivas, total ou parcialmente. As restantes exigem revisão manual.

   Fonte: Perforce, MISRA C and MISRA C++ guidelines

6. 10 anos de SATE

   Em dez anos de dados da NIST Static Analysis Tool Exposition, as ferramentas procuraram fraquezas diferentes e os volumes de avisos variaram muito. A sobreposição foi grande sobretudo em classes conhecidas, como erros de buffer.

   Fonte: NIST SP 500-326, SATE V report

7. 7 agências

   Em dezembro de 2023, a CISA, a NSA e o FBI pediram aos fabricantes planos para a segurança de memória. Assinaram também agências da Austrália, Canadá, Nova Zelândia e Reino Unido. Descreveram estas falhas como o tipo mais frequente de vulnerabilidade divulgada.

   Fonte: CISA, The Case for Memory Safe Roadmaps

Os dados da Microsoft, Chrome e Android mostram a importância da segurança de memória em grandes bases de código C e C++. As agências esperam agora um plano para esse problema. Os dados do NIST mostram que os analisadores procuram problemas diferentes. Nenhum destes números mede a eficácia de um analisador.

Aplicámos as seguintes regras:

1. Uma capacidade só é marcada como suportada quando a documentação do fornecedor ou do projeto o indica.
2. O suporte a normas de codificação é descrito ao nível da família. A cobertura exata de regras, a edição da norma e o licenciamento podem variar com a versão do produto ou o módulo.
3. Não atribuímos pontuações de precisão, taxa de falsos positivos ou velocidade. Essa comparação exige o mesmo código, configuração, hardware e critérios de aceitação.
4. "Indicado para" descreve o posicionamento do produto e as capacidades documentadas. Não é uma classificação universal.
5. O preço fica de fora, porque a maioria dos fornecedores empresariais faz orçamentos por projeto e agrupa as funcionalidades de formas diferentes.

1. SAST e análise estática: são a mesma coisa?

   SAST significa static application security testing. As equipas de segurança analisam código-fonte ou binários sem os executar, à procura de fraquezas exploráveis. Incluem transbordos de buffer, caminhos de injeção e uso inseguro de memória. Nos sistemas embebidos, a análise estática cobre também normas de codificação, prova de ausência de erros de execução e manutenção.

   A maioria destes produtos é vendida como ferramenta SAST. Uma plataforma para aplicações web pode interpretar C e C++ sem modelar bem um compilador cruzado ou um sistema operativo de tempo real (RTOS). Pode também falhar com código gerado. Em C e C++ embebido, o modelo do build e do ambiente costuma pesar mais do que o número de verificadores.

2. Análise orientada para defeitos

   A maioria dos analisadores estáticos foi desenhada para encontrar defeitos e vulnerabilidades prováveis. Combinam verificações sintáticas e semânticas com análise de fluxo de controlo, de fluxo de dados, de taint, de caminhos e interprocedimental. O resultado é um conjunto de ocorrências para revisão humana.

   Este modelo serve para uso contínuo numa grande base de código. Não prova a ausência de uma classe de erros. Uma análise sem ocorrências significa que o analisador configurado não reportou problemas. Não significa que o programa esteja correto.

3. Análise sound ou orientada para a prova

   Os analisadores sound sobreaproximam de propósito o comportamento possível do programa. Quando a análise prova uma propriedade sob os pressupostos declarados, o resultado pode demonstrar a ausência de uma classe definida de erros. O custo é uma modelação mais rigorosa, mais configuração e possíveis alarmes. Esses alarmes vêm de comportamentos que são possíveis no modelo, mas impossíveis no sistema real.

   O Polyspace Code Prover e o Astrée são os produtos mais claramente orientados para a prova nesta comparação. Não devem ser avaliados com os mesmos critérios de um scanner rápido de pull requests.

4. Conformidade com normas de codificação

   Para suporte a MISRA, AUTOSAR ou CERT, confirme:

   • A edição exata que o projeto exige
   • Que regras são verificadas automaticamente
   • Que diretrizes não são decidíveis estaticamente
   • Como os desvios são documentados e aprovados
   • Se os relatórios de conformidade seguem o formato de auditoria exigido
   • Se um kit de qualificação cobre a versão e a configuração escolhidas da ferramenta

   Uma ferramenta pode encontrar muitas violações MISRA e não oferecer um processo de conformidade. Uma ferramenta de conformidade pode aplicar bem as regras, enquanto outro analisador encontra mais defeitos lógicos ou de segurança.

5. Modelação do compilador e do ambiente

   O código embebido raramente se parece com C++ portável de desktop. Os projetos reais contêm intrínsecos do compilador, modelos de inteiros do alvo, código gerado e compilação condicional. Incluem também APIs de RTOS, alocadores personalizados, registos de hardware e assembly inline.

   Se o analisador não reproduzir o build real, a lista de funcionalidades perde valor. Teste primeiro a modelação do compilador e do ambiente. Compare os painéis depois.

• Se o analisador reproduz o pré-processamento e a configuração de build reais
• Se entende as larguras de inteiros e as extensões de compilador do alvo
• Se as ocorrências atravessam os limites de funções, ficheiros e módulos
• Se o código gerado e o código de terceiros podem ser tratados à parte
• Se um programador consegue entender e reproduzir o caminho reportado
• Se os avisos existentes podem ir para uma linha de base sem esconder riscos novos
• Se as supressões e os desvios continuam rastreáveis
• Se a análise central e a análise de pull requests usam regras comparáveis
• Se os relatórios satisfazem um avaliador, um cliente ou um processo de segurança interno
• Se modelos personalizados conseguem descrever APIs e transições de estado específicas do projeto

Se o analisador reproduz o pré-processamento e a configuração de build reais Se entende as larguras de inteiros e as extensões de compilador do alvo Se as ocorrências atravessam os limites de funções, ficheiros e módulos Se o código gerado e o código de terceiros podem ser tratados à parte Se um programador consegue entender e reproduzir o caminho reportado Se os avisos existentes podem ir para uma linha de base sem esconder riscos novos Se as supressões e os desvios continuam rastreáveis Se a análise central e a análise de pull requests usam regras comparáveis Se os relatórios satisfazem um avaliador, um cliente ou um processo de segurança interno Se modelos personalizados conseguem descrever APIs e transições de estado específicas do projeto Inclua cenários técnicos reais no pedido de proposta. Uma folha de cálculo com alegações dos fornecedores não revela estas diferenças.

1. 01

   Escolha código representativo

   Escolha um componente com os elementos que mais dificultam a análise. Inclua cabeçalhos e intrínsecos do alvo, variantes de build, código gerado, primitivas RTOS e gestão personalizada de memória. Acrescente defeitos conhecidos e uma alteração recente que atravessou vários módulos.

   Evite um pequeno projeto de demonstração. Favorece a configuração rápida e diz pouco sobre a adequação ao código de produção.

2. 02

   Defina o resultado esperado

   Registe o que o piloto vai testar. Os objetivos podem incluir encontrar defeitos, aplicar MISRA ou CERT, provar a ausência de erros de execução e analisar código alterado. Inclua, se necessário, governação entre branches, código de terceiros e detetores personalizados.

   Um piloto pode cobrir vários objetivos, mas cada objetivo precisa de critérios de aceitação próprios.

3. 03

   Meça o sinal útil

   Não ordene ferramentas pelo número de avisos. Mais avisos podem significar melhor deteção, regras duplicadas, má configuração ou ruído. Conte defeitos confirmados de alto impacto e ocorrências novas que exigem correção. Conte também as falsas ou irrelevantes. Meça o tempo para entender cada relatório. Confirme se as ocorrências permanecem estáveis após pequenas alterações no código.

4. 04

   Teste o fluxo completo

   Execute uma análise limpa do projeto e também uma alteração incremental. Ligue a ferramenta ao sistema de CI e ao IDE previstos. Teste a linha de base, a supressão, a atribuição, os quality gates, as exportações e os controlos de acesso. Se o código não pode sair da organização, verifique que dados são processados ou guardados fora do ambiente escolhido.

5. 05

   Verifique as evidências

   Em projetos regulados, pergunte que documentos inclui a licença proposta. Procure material de qualificação, uma matriz de cobertura para a edição da norma e um resumo de conformidade. Verifique também registos de desvios, configuração versionada, exportações para auditoria e política de suporte a longo prazo.

1. 01Avisos do compilador, para diagnósticos imediatos de linguagem e de build
2. 02clang-tidy ou outro linter, para as práticas de codificação locais
3. 03Cppcheck ou Clang Static Analyzer, como camada adicional open source de deteção de defeitos
4. 04Um analisador SAST ou de conformidade comercial, para controlo centralizado, normas e ocorrências entre módulos
5. 05Um analisador orientado para a prova, para componentes selecionados de alta criticidade
6. 06Testes unitários, de integração, hardware-in-the-loop e de sistema
7. 07Fuzzing e testes de segurança, para comportamentos que a análise do código-fonte não consegue estabelecer
8. 08Monitorização em tempo de execução, para falhas que dependem do ambiente onde o software está instalado