A intenção do padrão de codificação C da Motor Industry Software Trustedability Association (MISRA) C era definir um subconjunto da linguagem C que minimiza as possibilidades de erros. Embora originalmente destinado a aplicações críticas de segurança no mercado automotivo, ele está sendo usado em outras áreas, como médico e aeroespacial. Há também equipes de software usando o padrão como uma maneira de melhorar a qualidade e a segurança de seu código, mas não necessariamente exigem o padrão de conformidade com um padrão de segurança ou segurança. MISRA C é um padrão bem conhecido e respeitado e está se aproximando em outros mercados.

O objetivo da MISRA é entregar um código melhor durante o processo de desenvolvimento. Aplicar as regras DO MISRA ao código que já foi escrito, testado e/ou implantado não é uma tarefa fácil. A questão é se faz sentido para os negócios fazer mudanças em uma base de código existente que se provou ser confiável, com o risco de introduzir novos problemas ao fazer as mudanças. Este post considera algumas abordagens pragmáticas para adotar o MISRA gradualmente com a ajuda de ferramentas de teste de segurança de aplicações estáticas (SAST) como o CodeSonar da GrammaTech.

Qual é o objetivo?

A abordagem para a adoção de um novo padrão de codificação depende da exigência do novo sistema.

  1. Se o requisito for para alcançar a compliância misra completa, então a base de código existente terá que ser feita em conformidade. CodeSonar certamente pode ajudar nesta situação, mas não é o foco deste post no blog.
  2. Se, em vez disso, o MISRA é usado para entregar um código melhor daqui para frente, então este post fornece uma abordagem interessante.

Diretrizes do MISRA C

É importante perceber que nem todas as diretrizes do MISRA C são criadas iguais. As diretrizes são regras ou diretrizes, a diferença é que as regras são completamente descritas na norma e o cumprimento de uma regra pode ser verificado, geralmente automaticamente com analisadores de código estáticos. Uma diretiva é menos definida e precisa de informações adicionais, geralmente fornecidas durante uma auditoria, para garantir a conformidade. Para o bem deste post, falaremos sobre as diretrizes do MISRA C como regras padrão de codificação.

As normas de codificação geralmente classificam as regras por gravidade e o MISRA C não é diferente. As regras do MISRA C se enquadram em três categorias, obrigatórias, exigidas e consultivas. Previsivelmente, as regras obrigatórias são as mais críticas e menos críticas. Se o plano é usar o MISRA C para evitar os erros mais flagrantes, sua equipe pode decidir ignorar as regras de aconselhamento, pelo menos inicialmente.

O primeiro passo para adotar o MISRA C é rever o conjunto de regras e selecionar quais regras consultivas são mais aplicáveis ao aplicativo em questão, criando assim seu próprio subconjunto MISRA. Esta é uma abordagem completamente legítima que os recém-chegados ignoram a sensação de que é um conjunto de regras “tudo ou nada” e, consequentemente, esmagadora. Se sua organização está planejando usar o MSRA C como base para o seu próprio padrão de codificação personalizado, sem a necessidade de conformidade totalmente COM MISRA C, então uma nova seleção é possível.

“Pare o Sangramento”

É claro que aplicar o MISRA C a uma base de código existente pode ser um grande investimento, você pode ter milhares de violações para avaliar, o que nem sempre é útil, pois seu código já é testado e enviado. Alterar o código de trabalho para torná-lo compatível com um padrão de codificação nem sempre é um bom investimento. O que pode ser mais viável financeiramente é começar certificando-se de que seu novo código esteja em conformidade com o MISRA C.

A maneira de conseguir isso com o CodeSonar é executar uma análise em toda a sua base de código fonte e destacar as violações. Em seguida, você pode usar esses resultados como uma linha de base para comparar. Entramos em mais detalhes sobre a adoção do SAST em um código existente neste post. Esta comparação agora só destaca as violações MISRA em novo código desenvolvido após a linha de base. Este novo código pode estar em novos arquivos ou até mesmo adicionado aos arquivos existentes. Violações de regras da MISRA podem ser alimentadas ao desenvolvedor em seu IDE, efetivamente, “parando o sangramento”.

Uma abordagem pragmática para adotar o MISRA C

Uma maneira de os desenvolvedores facilitarem seu caminho para usar um novo padrão de codificação significa alguma preparação antes do tempo, a fim de diminuir a chance da equipe ser sobrecarregada com relatórios. As etapas a seguir fornecem um resumo rápido das etapas necessárias:

  1. Defina uma regra definida para o projeto: É possível que você já tenha um padrão de codificação e, como tal, você pode estar olhando para o MISRA C como uma maneira de estender o que você tem. Se não, e o cumprimento total não é o objetivo final, é uma boa ideia decidir quais regras a equipe planeja adotar.
  2. Configure o CodeSonar para apoiar o regulamento definido pela equipe. Faz sentido, é claro, manter várias regras de vulnerabilidade de bugs e segurança ativadas também.
  3. Use a filtragem para se concentrar nas violações mais críticas. Uma vez que um relatório de linha de base tenha sido gerado, o CodeSonar tem poderosos recursos de filtragem e salvamento de pesquisa para ajudar os desenvolvedores a se concentrarem nas violações mais críticas primeiro. Também é possível filtrar apenas as alterações na última compilação, avaliar violações por tipo, gravidade ou por arquivo.
  4. Concentre-se em um novo código primeiro. Dependendo da abordagem preferida, o relatório de linhas de base pode ser filtrado definindo o estado das violações existentes para “adiar” ou simplesmente filtrar novas bases de relatórios nos deltas entre as compilações. Em ambos os casos, o foco da avaliação está nas alterações no código ou no novo código escrito.
  5. Avaliar e priorizar violações. É importante avaliar as violações em novo código à medida que surgem e, com isso, queremos dizer analisar se a violação é real, decidir se ela precisa ser corrigida e atribuir uma prioridade à correção. Isso não deve ser muito oneroso quando se concentra em um novo código. No entanto, a equipe pode ficar sobrecarregada se as violações não forem gerenciadas com cada iteração.
  6. Avalie o código existente, como o tempo permite, em ordem de gravidade. Se a equipe decidir olhar para o estado do código existente (antes da linha de base e antes de “pararmos o sangramento”) então faz sentido considerar as violações de maior gravidade primeiro. É aqui que os poderosos recursos de pesquisa, classificação e filtragem do CodeSonar são úteis. As avaliações podem ser feitas primeiro nas regras obrigatórias, por exemplo, e as correções podem ser atribuídas e priorizadas.

Resumo

Adotar o MISRA C para um projeto existente que não exija conformidade oficial ainda pode ser um empreendimento assustador sem uma abordagem pensativa. Esta abordagem pragmática concentra-se em novo código, inicialmente, e na avaliação de violações padrão de codificação na ordem de gravidade. O CodeSonar fornece o suporte tanto para OPÇÕES DE MISRA C quanto para opções de configuração, filtragem e pesquisa que torna essa abordagem pragmática uma realidade para desenvolvedores de software.

Autor: Christian Simko

Artigo Original