The EVerest Dataset for Secure Software Engineering
O artigo apresenta o conjunto de dados EVerest, um recurso multi-artefato único que compreende requisitos de segurança, modelos arquiteturais e código-fonte de uma pilha de carregamento de veículos elétricos, o qual possibilita a pesquisa de verificação de segurança de ponta a ponta e facilitou a descoberta e remediação de uma vulnerabilidade de segurança do mundo real.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você está construindo uma estação de carregamento de veículos elétricos de alta tecnologia. Para garantir que ela esteja segura contra hackers, você precisa verificar três camadas diferentes do seu projeto:
- A Lista de Desejos: O que os desenvolvedores dizem que querem (ex: "Deve ser seguro").
- O Projeto: Os desenhos arquitetônicos mostrando como as partes se conectam.
- Os Tijolos: O código de computador real que faz a máquina funcionar.
O problema é que a maioria das ferramentas de pesquisa olha apenas para uma dessas camadas. Elas podem ter uma lista de desejos, ou um monte de código, mas nunca têm as três conectadas entre si. É como tentar consertar um telhado com vazamento olhando apenas para os projetos, sem nunca verificar as telhas reais ou a lista de reclamações do proprietário.
O Conjunto de Dados EVerest é um novo e gigante kit de ferramentas "tudo em um" criado por pesquisadores do Instituto de Tecnologia de Karlsruhe para resolver isso. Ele conecta a Lista de Desejos, o Projeto e os Tijolos para um projeto de software real e de código aberto chamado EVerest (que controla carregadores de VE)
Aqui está como eles construíram isso, usando uma analogia simples:
1. Reunindo a "Lista de Desejos" (Requisitos)
Primeiro, os pesquisadores precisavam saber quais regras de segurança o projeto realmente precisava.
- A Pesquisa: Eles enviaram um questionário à comunidade de desenvolvedores, perguntando: "Quais são os objetivos de segurança?" (Como perguntar: "Você quer que a porta seja trancada?"). Isso lhes deu uma lista bruta de 6 de 67 ideias.
- A Entrevista: A lista bruta era muito vaga. Por isso, eles se sentaram com quatro desenvolvedores especialistas para conversas profundas. Eles pegaram essas ideias brutas e as refinaram em instruções específicas, como mudar "Trancar a porta" para "O módulo OCPP deve rejeitar entradas malformadas do CSMS".
- O Resultado: Eles terminaram com 84 requisitos de segurança precisos.
2. Desenhando o "Projeto" (Arquitetura)
O projeto EVerest não tinha um mapa arquitetônico formal; ele apenas tinha código.
- A Tradução: Três estudantes, supervisionados por especialistas, analisaram o código-fonte e construíram manualmente um modelo de componentes Palladio. Pense nisso como pegar um monte de peças de Lego e desenhar um diagrama detalhado mostrando exatamente como cada peça se conecta, como os dados fluem entre elas e como elas conversam entre si.
- O Resultado: Um projeto digital com 29 componentes e 144 descrições de serviços detalhadas.
3. Rotulando os "Tijolos" (Código e Elementos)
Agora, eles precisavam conectar os pontos entre a Lista de Desejos e o Projeto.
- O Jogo de Etiquetagem: Três pessoas percorreram os 84 requisitos e destacaram palavras específicas. Elas etiquetaram coisas como "componentes", "dados", "estados" e "fluxos de dados".
- O Rastro: Eles desenharam linhas digitais (links de rastreamento) conectando uma frase específica no requisito (ex: "O provedor de pagamento deve ser seguro") diretamente à parte específica do projeto e ao código que lida com o pagamento.
- O Resultado: Eles rotularam 1.445 pequenos elementos de segurança, criando uma enorme teia de conexões.
O Teste do Mundo Real
A melhor parte deste conjunto de dados não é apenas o fato de ele existir; é que ele realmente encontrou um erro real.
Enquanto construíam o conjunto de dados, os pesquisadores notaram uma incompatibilidade. Um dos requisitos dizia: "Tokens de autenticação não devem ser armazenados em texto simples". No entanto, quando olharam para o código real (os "tijolos"), encontraram uma linha onde o código estava armazenando tokens em texto simples.
- A Correção: Eles reportaram isso aos mantenedores do projeto. Os desenvolvedores confirmaram que era uma fraqueza real (conhecida como CWE-1295) e a corrigiram imediatamente.
Por Que Isso Importa
Antes disso, pesquisadores tentando construir ferramentas para verificar automaticamente a segurança do software tinham que adivinhar como os requisitos, o design e o código se relacionavam, pois nenhum conjunto de dados fornecia as três coisas.
O conjunto de dados EVerest é como um manual de treinamento completo e rotulado para IA e pesquisadores. Ele permite que eles pratiquem:
- Ensinar computadores a entender requisitos de segurança.
- Encontrar automaticamente onde um requisito é implementado no código.
- Verificar se o software final realmente corresponde às promessas de segurança originais.
Em resumo, o artigo apresenta um recurso único e de múltiplas camadas que preenche a lacuna entre o que o software deveria fazer, como ele é projetado e como ele é construído, provando seu valor ao detectar uma falha de segurança real durante o processo.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.