As ferramentas de análise estática (SA) são uma parte amplamente utilizada e rotineira de testes por organizações comerciais e do DoD. Validar e reparar defeitos descobertos pelas ferramentas SA pode exigir mais esforço humano de auditores e codificadores do que as organizações disponíveis. Desde 2016, pesquisadores da Divisão SEI CERT vêm desenvolvendo um método para classificar e priorizar automaticamente alertas (avisos) e meta-alertas (alertas sobre falhas ou condições de código) para ajudar auditores e codificadores a lidar com grandes volumes de informações com menos esforço. O objetivo de nossa pesquisa tem sido permitir classificação automatizada prática, para que todos os meta-alertas possam ser abordados.

Nota: Para obter uma explicação sobre o uso dos termos alerta, condição de alerta e meta-alerta, consulte a barra lateral, uma nota sobre terminologia para alertas.

Até o momento, a pesquisa sobre a classificação de meta-alertas foi restringida pela ausência de um conjunto de dados completo e confiável de dados meta-alerta. Este post no blog descreve um novo repositório de dados rotulados que o CERT está disponibilizando publicamente para muitas condições de falha de código. Os pesquisadores podem usar esse conjunto de dados juntamente com o código e a saída da ferramenta associados para monitorar e testar o desempenho de sua classificação automatizada de meta-alertas.

Além dos dados rotulados, os pesquisadores precisam de dados associados que possam ser usados como características de classificação. Características são tipos de dados que são analisados pelos algoritmos matemáticos para os classificadores. Eles incluem dados coletados por ferramentas de code-metrics e ferramentas gerais de SA sobre o programa, arquivo, função e outras categorias relevantes para cada alerta. Essas características ajudam os pesquisadores a desenvolver classificadores mais precisos.

Ao desenvolver esse repositório público de dados para pesquisa de classificação de meta-alerta, nosso objetivo tem sido ajudar o campo de pesquisa como um todo — outros pesquisadores, bem como nós mesmos. Os pesquisadores do campo precisam desses dados para muitas linguagens de código diferentes, ferramentas de análise estática (e outras) e tipos de projetos de código, e de um conjunto variado de organizações de desenvolvimento. Os classificadores geralmente são melhores se os dados usados para desenvolvê-los (e heurísticas de aprendizagem ativa /adaptativa usadas para atualizá-los) são semelhantes ao tipo de projeto de codificação, organização de desenvolvimento, linguagem de codificação e ferramentas para a base de código cujos meta-alertas de análise estática estão sendo julgados.

Histórico: Usando automação para priorizar alertas a partir de ferramentas de análise estática

Encontramos o problema da insuficiência de dados em nossa pesquisa inicial de classificação, que começamos em 2016. Não tínhamos dados rotulados suficientes para desenvolver classificadores precisos com alto recall para muitas condições de falha de código, ou para código semelhante. Além disso, os dados que tínhamos nem sempre eram de alta qualidade confiável. Abordamos esta questão da precisão do classificador usando várias ferramentas de análise estática como recursos, melhorando assim a precisão dos classificadores.

Iniciamos esse trabalho em 2017, motivado em parte pela constatação de que não havia dados suficientes de qualidade duvidosa para classificadores precisos para algumas condições, como Enumerações comuns de fraqueza (CWEs) e regras de codificação CERT. Desenvolvemos regras de auditoria e um léxico de auditoria e usamos suítes de teste de uma nova maneira para produzir dados rotulados para o desenvolvimento de classificados. A SEI desenvolveu a interface de programação de aplicativos (SCAIFE) de análise de código fonte (API) em 2017. O SCAIFE define uma arquitetura para classificar e priorizar meta-alertas de análise estática usando dados automaticamente rotulados e julgados manualmente que classificam com precisão a maioria dos dados como verdadeiros positivos (e-TP), falsos positivos esperados (e-FP) ou indeterminados (I). Até o final de 2018, tínhamos aproximadamente 38.000 novos alertas rotulados (True/False) de oito ferramentas SA na suíte de teste Juliet, uma melhoria em relação aos 7.000 alertas dos arquivos de auditoria cert nos últimos 10 anos.

Este número menor de alertas rotulados não foi suficiente para criar classificadores precisos para a maioria dos padrões de codificação CERT. Nossos dados de mais de 10 anos de auditorias CERT tinham muito pouco (ou não) dados rotulados para criar classificadores precisos para a maioria das regras de codificação CERT. O resultado do trabalho de 2018 tem sido de alta precisão para mais condições. Os resultados iniciais de 2018 de uma análise do conjunto de testes julieta são mostrados na Figura 1.

image

Figura 1: Resultados Iniciais de 2018 da Análise do Conjunto de Testes juliet

A Figura 1 fornece métricas iniciais que mostram que a disponibilidade dos dados adicionais resultou em economias significativas. Uma auditoria manual de 37.853 meta-alertas de programas não-test-suite levaria um mínimo irrealista de 1.230 horas (117 segundos por auditoria meta-alerta de acordo com a pesquisa de Ayewah e Pugh), e as primeiras 37.853 auditorias de alerta não cobririam muitas condições e sub-condições cobertas pela suíte de teste Juliet. Tanto os rótulos True quanto False são necessários para desenvolver classificadores precisos para as condições. Realisticamente, seria necessário uma enorme quantidade de tempo de auditoria manual (muito mais de 1.230 horas) para desenvolver tantos dados rotulados usando código natural (não pacote de teste) e julgamentos manuais, para gerar dados rotulados para tantas condições, com rótulos verdadeiros e falsos. Mais dados estarão disponíveis à medida que usarmos mais ferramentas e suítes de teste.

Em 2018-2019, voltamos nossa atenção para conseguir que mais organizações usassem tecnologia automatizada de classificadores meta-alerta. A adoção foi restringida por causa das despesas e da escassez de dados e especialistas na área. Desenvolvemos uma arquitetura extensível com um novo método para gerar dados de pacotes de teste, permitindo um uso mais amplo de classificadores com uma arquitetura extensível, uma interface de programação de aplicativos (API), software para instanciar a arquitetura e pesquisa adaptativa-heurística.

Dados de classificadores rápidos (RC)

Em 2/4/2020, publicamos pela primeira vez o Open Dataset RC_Data for Classifier Research to the SEI CERT Secure Coding page, com v2 publicado em 27/04. Ebonie McNeil, Matthew Sisk, e eu desenvolvemos este conjunto de dados. Ele contém dados estruturados que outros podem usar para testar algoritmos e ferramentas que desenvolvemos, e suporta pesquisas externas e colaborações na classificação automatizada de alertas de análise estática. Esses dados estão agora disponíveis publicamente para download. Um de nossos colaboradores do DoD e também pesquisadores da Universidade da Virgínia — Tim Sherburne, Peter A. Beling, Barry M. Horowitz e Stephen Adams, Do Departamento de Sistemas de Engenharia e Meio Ambiente — trabalharam com os dados já em suas pesquisas sobre classificadores.

“RC” significa “classificadores rápidos”, para a série de projetos (que liderei) destinados a permitir o uso rápido da classificação automatizada por

  • rapidamente obtendo dados rotulados de suítes de teste
  • permitindo o compartilhamento de higienização de dados anteriormente sensível de arquivos de auditoria e, assim, permitindo o crescimento mais rápido de arquivos de dados auditados manualmente
  • desenvolvendo uma arquitetura modular com definições de API para permitir que sistemas e ferramentas existentes comecem a usar tecnologia de classificação automatizada, superando barreiras de custo e experiência.

O arquivo RC_Data pode ser baixado e, em seguida, reconstituído em um banco de dados mongoDB. O banco de dados contém dados para duas suítes de teste: o Juliet Java Test Suite e o Juliet C/C++ Test Suite. As suítes de teste Juliet são de código aberto, criadas pelo Centro de Software Garantido (CAS) da Agência Nacional de Segurança (NSA) e hospedadas pelo site de dados de referência de software (SARD) do Instituto Nacional de Padrões e Tecnologia (NIST).

Estes conjuntos de teste foram criados para testar a qualidade das ferramentas de análise estática (FFSA) de descoberta de falhas. Nós os usamos de uma maneira diferente do propósito para o qual eles foram originalmente projetados para ajudar a gerar dados para criar e testar ferramentas de classificação automatizadas. O conjunto de dados RC_Data inclui dados estruturados sobre os alertas ffsa a partir de ferramentas de código aberto, informações sobre condições de Enumeração de Fraqueza Comum (CWE) que são mapeadas, veredictos (verdadeiros/falsos/desconhecidos) determinados usando meta-dados de conjunto de testes e métricas de código a partir de ferramentas de métricas de código de código de código aberto.

O conjunto de dados RC_Data é composto apenas por dados de código aberto: ferramentas de análise estática de verificação de falhas de código aberto e code-metrics, bases de código de código aberto, mapeamentos de código aberto entre verificadores e IDs de taxonomia e manifestos de suíte de teste de código aberto. Os fornecedores de ferramentas proprietários que desenvolvem as ferramentas proprietárias mais utilizadas não permitem a publicação de alertas a partir de suas ferramentas e, às vezes, não permitem a publicação de mapeamentos de seus verificadores de ferramentas para condições externas de taxonomia (por exemplo, regras de codificação CWE ou CERT). Temos executado mais ferramentas nas bases de código Juliet e outras, mas podemos compartilhar publicamente apenas dados que são de código aberto em RC_Data.

Os potenciais colaboradores devem entrar em contato conosco se estiverem interessados em contribuir para o conjunto de dados RC_Data, se tiverem (ou poderiam) gerar alertas de ferramenta de código aberto e, opcionalmente, também codificar métricas, para uma base de código de código aberto, juntamente com julgamentos verdadeiros ou falsos. São necessárias decisões; eles podem ser executados manualmente ou podem simplesmente consistir em um manifesto XML estilo SARD para uma suíte de teste.

Recursos de auto-treinamento para auditoria de meta-alertas

Para facilitar a contribuição dos pesquisadores — seja apenas publicamente ou apenas para uso interno — aos dados do conjunto de dados RC_Data, identificamos alguns recursos de auto-treinamento. Até o momento, não agregamos e fornecemos esses recursos publicamente, mas os fornecemos a pedido de vários colaboradores, que os acharam úteis. Aqui está a lista de recursos:

A qualidade dos dados aumentará se a equipe que utilizar as definições de estudos de dados dos tipos de falha de código (ou seja, condições”) para as quais eles inspecionarão meta-alertas de análise estática, conforme definido em uma taxonomia formal de falha de código. Para minha pesquisa, as taxonomias atualmente dos mais juros são

A publicação SCALe GitHub inclui um manual HTML SCAIFE/SCALe com informações extensas sobre como usar os sistemas SCAIFE e SCALe em https://github.com/cmu-sei/SCALe (ramo em escala scaife).

Olhando para o futuro para dados de código aberto para mais bases de código

No futuro, adicionaremos mais dados às versões aumentadas deste conjunto de dados. Eles incluirão dados de código aberto de mais bases de código e dados de mais ferramentas, e adicionaremos mais recursos ao conjunto de dados.

Atualmente, estamos trabalhando com pesquisadores da Universidade da Virgínia em uma atualização para o RC_Data inicial, ao qual eles adicionarão seus próprios dados sobre análises dinâmicas e testes de regressão. Tenho trabalhado com eles para adicionar campos e coleções — um agrupamento de documentos do MongoDB que equivale a uma tabela RDBMS (Sistema de Gerenciamento de Banco de Dados Relacional), semelhante conceitualmente a uma tabela de banco de dados SQL (Structured Query Language, linguagem de consulta” estruturada — para manter esses campos. Também estou trabalhando com eles para atualizar o formato de banco de dados em que eles organizarão seus dados para usar estruturas de projeto, pacote e adicionais que meus projetos usam internamente em nossos bancos de dados SCAIFE DataHub.

Em nossos projetos de pesquisa em andamento no SEI, atualizamos muito o formato de banco de dados SCAIFE DataHub nos últimos três anos, mas o formato v1 de banco de dados RC_Data é um formato muito mais antigo usado pelo nosso antigo código que evoluiu para SCAIFE em uma filial separada. Usamos o ramo antigo para produzir o RC_Data inicial, mas o formato mais novo do banco de dados DataHub tem mais campos e coleções que serão úteis para pesquisas sobre classificadores, mesmo antes de adicionar os novos campos para os dados da Universidade da Virgínia. Esperamos continuar a melhorar o formato de banco de dados RC_Data à medida que trabalhamos com colaboradores adicionais que geram recursos adicionais para dados que contribuem para RC_Data, e esses novos recursos precisarão ser incluídos no banco de RC_Data banco de dados.

Uma nota sobre terminologia para alertas

Em nosso trabalho mais recente, começamos a diferenciar três conceitos:

  • Alerta: Um aviso de uma ferramenta FFSA, específica para (1) um determinado local de código (número de linha e filepath); (2) um ID do verificador (um tipo de falha de código que a ferramenta procura, onde a combinação de todos os IDs do verificador em uma ferramenta define a taxonomia interna da ferramenta para falhas de código); (3) uma mensagem de aviso primária única; e (4) um conjunto único de mensagens de aviso secundárias, se houver alguma. Algumas ferramentas fornecem mensagens de aviso secundárias que permitem aos usuários rastrear o controle ou o fluxo de dados no código que leva ao alerta principal.
  • alertaSE condição: Uma condição é uma restrição ou propriedade de validade com a qual o código deve cumprir. As ferramentas FFSA detectam se o código viola as condições. Taxonomias externas de falhas de código, como MITRE CWE, As regras da Associação de Confiabilidade de Software da Indústria do Motor (MISRA) e as Regras de Codificação Segura SEI CERT são definidas externas a uma única ferramenta de análise estática.) Um alertaOcondition é um único alerta combinado com informações sobre apenas uma das condições de taxonomia de falha de código definida externamente para as quais o verificador da ferramenta SA mapeia. Um exemplo de uma condição de taxonomia definida externamente: CWE-190 é uma condição da taxonomia da CWE, e os CWEs são definidos externamente para qualquer ferramenta SA. Em nossa ferramenta SEI SCALe (versões de pesquisa 3.0 e mais recentes, e no GitHub todas as publicações do ramo de escala scaife do SCALe), em exibição sem aconseção, cada linha da Lista de Condições de alerta mostra uma condição de alerta, e a contagem total mostrada é a contagem de alertas.
  • Meta-alerta: Um construto que alertaAs condições mapeiam, que todos alertam Condições que compartilham a mesma linha, filepath e condição. Nossos classificadores fazem uma previsão para um meta-alerta, e um analista faz um julgamento manual de um meta-alerta. O projeto meta-alerta é usado no SEI SCALe (versões de pesquisa 3.0 e mais recentes) para vincular alertas mapeados para o mesmo (1) local de código (número de linha e filepath); e (2) condição de falha de código (especificamente, uma condição de uma taxonomia externa a qualquer ferramenta de análise estática específica). Por exemplo, cwe-190 é uma condição da taxonomia CWE. Nas versões SCALe 3.0 e mais recentes, as determinações (por exemplo, True e False) são feitas em um nível de meta-alerta. Observe que cada alerta nas versões SCALe 3.0 e mais recente tem um meta-alerta, mesmo quando apenas um alerta mapeia para esse local de código e condição de falha de código. Na visão fundida, a contagem total mostrada é a contagem de meta-alertas.

Autor: LORI FLYNN

Artiho Original