🆚 🐳 🤱🏻 Razões para introduzir o analisador de código estático PVS-Studio no processo de desenvolvimento 👵🏿 💐 👨🏽‍🍳

Razões para reproduzir ou analisar o código estático PVS-Studio no processo de desenvolvimento

O PVS-Studio é uma ferramenta para encontrar erros e possíveis vulnerabilidades no código fonte de programas escritos em C, C ++, C # ou Java. O PVS-Studio pertence à classe de ferramentas para testes de segurança de aplicativos estáticos (Static Application Security Testing, SAST). O analisador está focado na prática de integração contínua (IC) e permite identificar erros nos estágios iniciais ao corrigi-los.

Análise de código estático

Os projetos de software no processo de seu desenvolvimento estão se tornando cada vez mais. Exemplos:

Linux kernel 1.0.0: 176.000 linhas de código
Linux kernel 5.0: 26.000.000 linhas de código
Photoshop 1.0: 128.000 linhas de código
Photoshop CS 6: 10.000.000 de linhas de código

À medida que um projeto cresce em tamanho, sua complexidade aumenta mais rapidamente do que linearmente. Por esse motivo, à medida que o tamanho da base de código aumenta, aumenta também a densidade de erros. Uma maneira de compensar a crescente complexidade é usar ferramentas de análise de código estático.

Um analisador estático é um programa assistente do programador que executa uma revisão preliminar do código e indica fragmentos de código com maior probabilidade de conter um erro. Graças a isso, muitos erros podem ser corrigidos em um estágio inicial quando o custo para corrigi-los é mínimo.

A análise estática não substitui, mas complementa outras metodologias de detecção de defeitos, como revisões de código, testes de unidade, análise dinâmica de código, testes de regressão, teste manual e assim por diante.

Por exemplo, se estamos falando sobre revisões de código , é muito melhor se o programa detectar erros simples. Em seguida, os programadores que revisam o código poderão se concentrar em verificações de alto nível mais úteis do algoritmo e não serão forçados a ler as funções de comparação . Além disso, como mostra a prática , muitos erros são muito difíceis de procurar "com seus olhos" e são muito prováveis de passar despercebidos na fase de revisão de código.

Outra vantagem das ferramentas de análise estática é a presença de um rico banco de dados de padrões de erro. Eles podem encontrar problemas cuja existência o programador pode nem estar ciente. Alguns exemplos: V698 , V718 , V1023 .

PVS-Studio

Recomendamos a implementação do analisador de código estático PVS-Studio que desenvolvemos no processo de desenvolvimento. O produto é executado em sistemas de 64 bits no Windows, Linux e macOS e pode analisar o código destinado às plataformas ARM de 32 bits, 64 bits e incorporadas.

No momento da publicação deste artigo, o analisador suporta os seguintes idiomas e compiladores:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, Compilador C / C ++ para ARM C, C ++
Windows Momentics QNX, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, Compilador ARM 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Ferramentas de geração de código ARM C, C ++
Windows / Linux / macOS. GNU Arm Embedded Toolchain, compilador Arm Embedded GCC, C, C ++
Windows / Linux / macOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / macOS. Java

O analisador possui documentação detalhada em inglês e russo. As descrições das regras de diagnóstico contêm exemplos de código correto e incorreto, além de links para exemplos de erros reais encontrados em projetos de código aberto.

Para conveniência dos especialistas que usarão o PVS-Studio como ferramenta SAST , o analisador exibirá seus avisos sobre Enumeração de Fraqueza Comum, Padrões de Codificação SEI CERT e o padrão MISRA. Tabelas de conformidade dos diagnósticos do PVS-Studio para vários padrões:

O analisador pode ser usado de forma independente e integrar-se ao Visual Studio e IntelliJ IDEA. Além disso, recentemente alguns de nossos clientes estão usando o PVS-Studio como parte do SonarQube. O PVS-Studio, sendo conectado como um plug-in ao SonarQube, é uma fonte adicional de mensagens de diagnóstico.

Vários cenários de integração no IC foram elaborados. A consideração de todos os cenários está além do escopo deste artigo e é melhor consultar a documentação. Aqui estão apenas alguns links para que o leitor possa causar uma impressão geral:

O analisador PVS-Studio detecta efetivamente uma ampla gama de erros, desde erros de digitação até vazamentos de memória . Isso é possível graças à análise do fluxo de dados, execução simbólica, correspondência de padrões, anotação de método (inclusive automática). Você pode aprender mais sobre os princípios operacionais do artigo " Tecnologias usadas no analisador de código do PVS-Studio para encontrar erros e possíveis vulnerabilidades ".

Por que você deve usar o PVS-Studio

Ao introduzir o analisador de código estático PVS-Studio no processo de desenvolvimento, você reduzirá o custo de correção de muitos erros. Isso libera tempo para a implementação de novas funcionalidades ou para testes de alto nível mais detalhados.

Com o uso regular do analisador, o código ficará gradualmente melhor, o que facilitará sua manutenção. A correção sistemática de erros e a prática de escrever código de alta qualidade reduzirão a probabilidade de detectar vulnerabilidades de dia zero no projeto. Este tópico é discutido em mais detalhes no artigo " Como o PVS-Studio pode ajudar na busca de vulnerabilidades? "

O uso da ferramenta PVS-Studio é benéfico para equipes de cinco ou mais pessoas. Você pode se familiarizar com o método de cálculo da eficiência de uso do analisador no artigo " PVS-Studio ROI ".

Para projetos desenvolvidos por um ou dois entusiastas, o analisador PVS-Studio provavelmente será redundante. No entanto, também pode ser usado em projetos tão pequenos, especialmente porque fornecemos várias opções de licenciamento gratuitas para estudantes, projetos de código aberto, etc.

Geralmente, no início, nossos clientes adquirem uma licença por um ano. Após um ano, quando estão convencidos de que os recursos do analisador e seu suporte estão completamente satisfeitos, eles renovam a licença por dois ou três anos ao mesmo tempo. Isso lhes permite obter um desconto substancial. Você pode solicitar preços e consultar sobre questões de licenciamento aqui .

Seja nosso cliente. Usando o PVS-Studio, você aumentará a maturidade do processo de desenvolvimento, economizará dinheiro na luta contra bugs e criará um software melhor.

Forneceremos suporte rápido e de qualidade. As perguntas são respondidas diretamente pelos programadores que desenvolvem os módulos nos quais a pergunta surgiu. Isso ajuda a obter respostas mesmo em situações difíceis. Um exemplo dessa comunicação é " Falsos positivos no PVS-Studio: quão profunda é a toca do coelho ".

Respostas de objeção

Às vezes, os programadores percebem negativamente a idéia de introduzir a análise de código estático no processo de desenvolvimento, criticando a metodologia da análise estática como um todo ou especificamente a ferramenta PVS-Studio. Quando a discussão começa, verifica-se que a crítica não é fundamentada e decorre simplesmente da falta de vontade de mudar alguma coisa no processo de desenvolvimento estabelecido. Considere os argumentos típicos para não mudar nada e em que consiste a fraqueza deles.

“A análise estática fará parte do tempo de trabalho”

A afirmação "a análise estática ocupará parte do tempo de trabalho" isoladamente do contexto é verdadeira. A revisão regular de avisos do analisador estático emitidos para código novo ou alterado realmente leva tempo. No entanto, o pensamento deve ser continuado: mas o tempo gasto com isso é muito menor que o custo de identificar erros por outros métodos.

De onde vem a opinião sobre a necessidade de gastar tempo avisando os analisadores de código estático?

Os programadores ainda não familiarizados com a metodologia de análise de código confundem as execuções de teste e o uso regular. No início, qualquer analisador fornece uma lista enorme de avisos, muitos dos quais são falsos. O motivo é que o analisador ainda não está configurado. Um analisador ajustado gera um pequeno número de falsos positivos durante lançamentos regulares. Em outras palavras, com o uso regular, a maioria dos avisos detectará defeitos reais ou um código de odor. É importante apenas fazer essa configuração.

Este tópico é descrito em mais detalhes no artigo “ Trabalhando com objeções: a análise estática fará parte do tempo de trabalho ”.

“O analisador estático é muito barulhento (produz muitos falsos positivos)”

Como mencionado acima, esta conclusão é feita usando um analisador de código não configurado. Depois de configurar o PVS-Studio, você pode esperar que a porcentagem de falsos positivos seja de 10 a 20%. Ou seja, com cinco avisos emitidos, quatro indicarão erros reais ou um código que provavelmente causará erros no futuro. Um exemplo dessa configuração pode ser visto no artigo " Especificações do analisador PVS-Studio usando o exemplo das bibliotecas principais do EFL, 10 a 15% dos falsos positivos ".

Outro motivo que distorce a ideia do analisador é o desejo de incluir o maior número possível de avisos, sem entender seu objetivo. Por exemplo, se você ativar o conjunto de regras MISRA focado em sistemas incorporados para um aplicativo clássico do Windows, o analisador gerará centenas de milhares de avisos. Não haverá significado prático neles. Diagnósticos especialmente desnecessários interferem no estágio de conhecimento da ferramenta e formam um equívoco sobre suas capacidades de diagnóstico. O artigo “ Como ver rapidamente avisos interessantes de que o analisador PVS-Studio para código C e C ++? ” Ajuda a evitar isso.

“Introduzir a análise estática no processo de desenvolvimento é muito difícil, longo e caro”

Muito bem, essas preocupações são refletidas neste comentário:

Infelizmente, os próprios analisadores estáticos nada mais são do que brinquedos. Introduzi-los no fluxo de trabalho é um trabalho e tanto, você precisa selecionar indivíduos para processar e filtrar os resultados. As tentativas de transferir essas tarefas para os ombros dos desenvolvedores comuns geralmente terminam em nada.

Não é tão assustador. Há pelo menos três abordagens que permitem implementar minuciosamente a análise estática, mesmo em grandes projetos antigos.

Primeira abordagem. "Ratchet Method", que Ivan Ponomarev fala bem em seu relatório " Continuous Static Code Analysis ".

Segunda abordagem. Para começar a usar rapidamente a análise estática, oferecemos aos clientes do PVS-Studio o uso da " base de marcação ". A ideia geral é a seguinte. O usuário iniciou o analisador e recebeu muitos avisos. Como um projeto desenvolvido por muitos anos está vivo, desenvolve e gera dinheiro, provavelmente não haverá muitos avisos no relatório indicando defeitos críticos. Em outras palavras, os bugs críticos já foram corrigidos de uma maneira ou de outra de maneiras mais caras ou graças ao feedback dos clientes. Assim, tudo o que o analisador encontra agora pode ser considerado uma dívida técnica, o que é impraticável tentar eliminar imediatamente.

Você pode dizer ao PVS-Studio para considerar esses avisos irrelevantes (adiar a dívida técnica para mais tarde) e não mostrá-los novamente. O analisador cria um arquivo especial onde armazena informações sobre erros desinteressantes até o momento. E agora o PVS-Studio emitirá avisos apenas em código novo ou alterado. Além disso, tudo isso é implementado de maneira inteligente. Se, por exemplo, uma linha vazia for adicionada ao início de um determinado arquivo .cpp, o analisador entenderá que, de fato, nada mudou e permanecerá silencioso. Esse arquivo de marcação pode ser incorporado no sistema de controle de versão. O arquivo é grande, mas não é assustador, porque geralmente não faz sentido colocá-lo.

Agora todos os programadores verão avisos relacionados apenas ao código novo ou alterado. Assim, o analisador pode começar a usar o que é chamado no dia seguinte. E será possível retornar à dívida técnica posteriormente, corrigir gradualmente os erros e configurar o analisador.

A terceira abordagem. Você pode concluir um contrato conosco e delegar à nossa equipe o trabalho de configurar e integrar a análise estática. Um exemplo dessa prática: " Como a equipe do PVS-Studio aprimorou o código do Unreal Engine ".

“Lançamos o analisador e não encontramos nada de interessante”

Isso é inteiramente possível, mas isso não significa que o analisador não será útil. O problema é que os erros foram corrigidos por métodos mais caros. Veja como pegar o texto de um livro, já lido por vários revisores, e ver o que o verificador ortográfico incorporado no Microsoft Word pode encontrar. Pequenos erros serão encontrados, mas não se segue que a função de verificação no Word não será útil ao escrever novos textos.

Este tópico é discutido em mais detalhes no artigo " Filosofia da análise de código estático: temos 100 programadores, o analisador encontrou poucos erros, é inútil? ".

"Um analisador estático é caro, é melhor contratar outro programador / testador"

De fato, isso significa que você não deseja alterar nada. De fato, antes da equipe crescer e reabastecer com novos programadores e testadores. No entanto, isso não levou a um aumento significativo na maturidade do processo de desenvolvimento. No entanto, vamos examinar essa objeção com mais detalhes.

Primeiro, levar uma pessoa extra para procurar erros é muito mais caro do que começar a usar um analisador de código. Calcule o fundo de salário de uma pessoa para o ano. Adicione impostos e organização do local de trabalho. O argumento de que uma licença é cara não é mais um argumento. E, ainda assim, o analisador estático, diferentemente da pessoa, não sai de férias, não está doente e não sai. Se estamos falando de equipes grandes, por exemplo, 100 pessoas, então, para obter algum efeito, você precisará contratar várias pessoas. A diferença a favor do analisador estático está aumentando.

Em segundo lugar, o maior efeito é alcançado devido à sinergia do uso de várias técnicas de busca de erros. Alguns erros são bem detectados por testes de unidade, outros por testes manuais e assim por diante. Imagine a situação. O projeto tem 10 programadores, muitos testes de unidade são escritos, mas não há testadores. A qualidade do projeto não se adequa aos usuários e a idéia é abrir um trabalho como testador. Mas isso não é feito sob o pretexto de que “é melhor contratar outro programador”, que haja ainda mais testes de unidade! Concordo, esta é a decisão errada. Obviamente, o processo de garantia de qualidade é unilateral e a adição de testes manuais trará benefícios muito maiores. A mesma situação é com análise estática.

"A análise dinâmica é mais eficiente que a estática."

Os analisadores estáticos encontram bem alguns erros. Alguns são analisadores dinâmicos. Essas ferramentas se complementam e não faz sentido escolher uma coisa.

Por exemplo, os analisadores dinâmicos não podem encontrar muitos erros de digitação ou detectar códigos inacessíveis. No artigo " Validando o código do Valgrind Dynamic Analyzer usando um analisador estático ", você pode encontrar alguns desses erros.

“Os testes de unidade são mais eficientes que a análise de código estática”

Se você escolher entre escrever testes de unidade e análise estática, talvez os testes sejam mais importantes e úteis. Mas nenhuma escolha precisa ser feita. É necessário usar testes de unidade e análise de código estático. Essas metodologias de busca de erros se complementam perfeitamente.

A análise estática complementará os testes de unidade pelos seguintes motivos:

Ninguém testa os próprios testes e eles geralmente contêm erros. Em nossos artigos, citamos repetidamente exemplos de erros no código de teste de unidade. Assim, a análise estática pode encontrar erros nos testes, os quais, por sua vez, podem encontrar erros no código principal do aplicativo.
Os testes são muito difíceis de cobrir todo o código. Especialmente quando se trata de código para lidar com situações de emergência. Os analisadores estáticos verificam todo o código.
Alguns erros são impossíveis ou extremamente difíceis de detectar com testes de unidade. Exemplo: V597 (CWE-14) .
Alguns erros se manifestam apenas ao processar grandes quantidades de dados, e os testes de unidade são impraticáveis para modelar essas situações. Um exemplo é o estouro de uma variável de 32 bits em um programa de 64 bits ( V108 , V127 ).
É mais fácil e rápido encontrar um erro executando uma análise estática do que depurando o código quando ocorre que ele não funciona no teste de unidade. Obviamente, os testes de unidade encontrarão mais erros, mas se alguns deles puderem ser encontrados de maneira mais barata (análise estática), por que não usá-lo?
Encontramos um grande número de erros em vários projetos. Muitos desses projetos são bem cobertos por testes, mas como você pode ver, isso não ajuda. Portanto, não há razão para não iniciar, além dos testes de unidade, usando também a análise de código estático, melhorando assim sua qualidade e segurança.

“Compiladores gratuitos modernos podem fazer o mesmo que o PVS-Studio”

Sim, de fato, os compiladores estão evoluindo e novos avisos estão sendo implementados para ajudá-los a encontrar erros no código. No entanto, você não deve esperar muito dos compiladores, em comparação com soluções pagas profissionais, como o PVS-Studio.

Vantagens do PVS-Studio:

Suporte ao usuário.
Infra-estrutura rica (integração com outros produtos).
Recursos de diagnóstico desenvolvidos.

Os dois primeiros pontos já são suficientes para superar as escalas em favor do PVS-Studio. No entanto, vamos falar sobre diagnóstico. Estamos constantemente desenvolvendo o analisador para ficar à frente de outras ferramentas. Por exemplo, podemos encontrar aqui um erro tão interessante " 31 de fevereiro ".

Isso não é suficiente para convencer os leitores céticos. Portanto, periodicamente, verificamos outros compiladores e mostramos que o PVS-Studio é capaz de encontrar erros neles:

PS

Se você ainda duvida de usar o PVS-Studio, verifique quais erros e em quais projetos conseguimos detectar .

Links úteis

Se você deseja compartilhar este artigo com um público que fala inglês, use o link para a tradução: Andrey Karpov. Por que você deve escolher o estático analisador PVS-Studio para integrar no seu processo de desenvolvimento .

Razões para introduzir o analisador de código estático PVS-Studio no processo de desenvolvimento