Skip to main content

Sobre a correção automática da verificação de código do CodeQL

Saiba como o GitHub usa a IA para sugerir possíveis correções nos alertas de code scanning encontrados pelo CodeQL em sua solicitação de pull.

Who can use this feature?

A correção automática para o code scanning está disponível apenas para usuários do GitHub Enterprise Cloud que têm o GitHub Advanced Security. Para obter mais informações, confira "Sobre a Segurança Avançada do GitHub".

Observação: a correção automática do GitHub para o code scanning está em beta. A funcionalidade e a documentação estão sujeitas a alterações. Durante essa fase, o recurso está restrito a alertas JavaScript e TypeScript identificados pelo CodeQL. Se você tiver uma conta corporativa e usar o GitHub Advanced Security, poderá entrar na lista de espera para recursos de IA do GitHub Advanced Security.

Sobre a correção automática da code scanning do CodeQL

A correção automática é uma expansão da plataforma AI de code scanning que fornece aos usuários recomendações direcionadas para ajudá-los a corrigir alertas do code scanning nas solicitações de pull a fim de que eles possam evitar a introdução de novas vulnerabilidades de segurança. As possíveis correções são geradas automaticamente por modelos de linguagem grande (LLMs) usando dados da base de código, da solicitação de pull e da análise do CodeQL.

A correção automática de Code scanning gera possíveis correções que são relevantes para o código-fonte existente e converte a descrição e o local de um alerta em alterações de código que podem corrigir o alerta. O sistema de correção automática usa o modelo de linguagem grande OpenAI GPT-4, que tem recursos generativos suficientes para produzir correções sugeridas no código e texto explicativo para essas correções.

Experiência do desenvolvedor

Os usuários do GitHub Advanced Security já podem ver quaisquer alertas de segurança detectados pela code scanning usando o CodeQL para analisar suas solicitações de pull. No entanto, os desenvolvedores geralmente têm pouco treinamento em segurança de código, de modo que a correção desses alertas exige um esforço substancial. Eles devem primeiro ler e entender o local e a descrição do alerta e, em seguida, usar esse entendimento para editar o código-fonte para corrigir a vulnerabilidade.

A correção automática da Code scanning reduz a barreira de entrada para os desenvolvedores, combinando informações sobre melhores práticas com detalhes da base de código e do alerta para sugerir uma possível correção para o desenvolvedor. Em vez de começar com uma pesquisa de informações sobre a vulnerabilidade, o desenvolvedor começa com uma sugestão de código que demonstra uma possível solução para sua base de código. O desenvolvedor avalia a possível correção para determinar se é a melhor solução para sua base de código e garantir que ela mantenha o comportamento pretendido.

Depois de confirmar uma correção sugerida ou uma correção modificada, o desenvolvedor deve sempre verificar se o teste de integração contínua (CI) para a base de código continua aprovado e se o alerta é mostrado como resolvido antes de mesclar sua solicitação de pull.

Processo de geração de correção automática

Quando a correção automática está habilitada para um repositório, os alertas da code scanning identificados em uma solicitação de pull pelas consultas do CodeQL com suporte enviam a entrada para o LLM. Se o LLM puder gerar uma correção possível, a correção será mostrada na solicitação de pull como comentário da sugestão.

O GitHub envia ao LLM uma variedade de dados da solicitação de pull e da análise do CodeQL.

  • Dados de alerta do CodeQL em formato SARIF. Para obter mais informações, confira "Suporte SARIF para a varredura de código".
  • Código da versão atual da ramificação de solicitação de pull.
    • Trechos curtos de código em cada local de origem, local de coleta e qualquer local referenciado na mensagem de alerta ou incluído no caminho de fluxo.
    • Primeiras ~10 linhas de cada arquivo envolvido em qualquer um desses locais.
  • Texto de ajuda para a consulta do CodeQL que identificou o problema. Para obter exemplos, confira “Ajuda para consultas do CodeQL.”

Todas as sugestões de correção automática são geradas e armazenadas no back-end de code scanning. Elas são exibidos como comentários da sugestão na solicitação de pull. Nenhuma interação do usuário é necessária além de habilitar a code scanning na base de código e criar a solicitação de pull.

Qualidade das sugestões de correção automática

O GitHub usa um agente de teste automatizado para monitorar continuamente a qualidade das sugestões de correção automática. Isso nos permite entender como as sugestões de correção automática geradas pelo LLM mudam à medida que o modelo se desenvolve.

O agente de teste inclui um conjunto de mais de 700 alertas JavaScript/TypeScript de um conjunto diversificado de repositórios públicos no qual o código destacado tem cobertura de teste. As sugestões de correção automática para esses alertas são testadas para ver até que ponto elas são boas, ou seja, o quanto um desenvolvedor precisaria editá-las antes de confirmá-las na base de código. Para muitos dos alertas de teste, as correções automáticas geradas pelo LLM podem ser confirmadas no estado em que se encontram para corrigir o alerta enquanto continuam a passar com êxito em todos os testes de CI existentes.

Além disso, o sistema tem teste de estresse para verificar qualquer possível dano (muitas vezes referido como agrupamento vermelho), e um sistema de filtragem no LLM ajuda a evitar que sugestões potencialmente prejudiciais sejam exibidas aos usuários.

Como o GitHub testa sugestões de correção automática

Testamos a eficácia das sugestões de correção automática mesclando todas as alterações sugeridas, não editadas, antes de executar a code scanning e os testes de unidade do repositório no código resultante.

  1. O alerta da code scanning foi corrigido pela sugestão?
  2. A correção introduziu novos alertas de code scanning?
  3. A correção introduziu algum erro de sintaxe que o CodeQL consegue detectar?
  4. A correção alterou a saída de algum dos testes do repositório?

Além disso, verificamos muitas das sugestões bem-sucedidas e confirmamos que elas corrigem o alerta sem introduzir novos problemas. Quando uma ou mais dessas verificações falharam, nossa triagem manual mostrou que, em muitos casos, a correção proposta estava quase correta, mas precisava de algumas pequenas modificações que um usuário poderia identificar e executar manualmente.

Eficácia em outros projetos JavaScript/TypeScript

O conjunto de testes contém uma ampla gama de diferentes tipos de projetos e alertas. Prevemos que as correções automáticas para outros projetos JavaScript/TypeScript devem seguir um padrão semelhante.

  • A correção automática provavelmente adicionará uma sugestão de código à maioria dos alertas para projetos JavaScript/TypeScript.
  • Quando os desenvolvedores avaliam as sugestões de correção automática, esperamos que a maioria das correções possa ser confirmada sem edição ou com pequenas atualizações para refletir o contexto mais amplo do código.
  • Uma pequena porcentagem de correções sugeridas refletirá um mal-entendido significativo da base de código ou da vulnerabilidade.

No entanto, cada projeto e base de código é exclusivo, ou seja, os desenvolvedores podem precisar editar uma porcentagem maior de correções sugeridas antes de confirmá-las. A correção automática fornece informações valiosas para ajudar você a resolver alertas de code scanning, mas, em última análise, continua sendo sua responsabilidade avaliar a alteração proposta e garantir a segurança e a precisão do seu código.

Nota: O sistema não sugere correções para todos os tipos de alertas de code scanning identificados pelo CodeQL. Há suporte para correção automática em um subconjunto das consultas padrão JavaScript/TypeScript do CodeQL e o LLM é limitado em sua capacidade operacional. Além disso, cada correção sugerida é testada antes de ser adicionada a uma solicitação de pull. Se nenhuma sugestão estiver disponível ou se a correção sugerida for reprovada no teste interno, nenhuma sugestão de correção automática será exibida.

Limitações de sugestões de correção automática

Ao revisar uma sugestão de correção automática, você deve sempre considerar as limitações da IA e editar as alterações conforme necessário antes de aceitar as alterações. Considere também a atualização do teste de CI e do gerenciamento de dependências para um repositório antes de habilitar a correção automática para code scanning. Para obter mais informações, confira "Atenuando as limitações das sugestões de correção automática".

Limitações das sugestões de correção automática

  • Linguagens de programação: Há suporte para um subconjunto de linguagens de programação, inicialmente, apenas JavaScript e TypeScript. O suporte para linguagens adicionais será adicionado, mas não há intenção de fornecer suporte para todas as linguagens do CodeQL.
  • Linguagens humanas: O sistema usa principalmente dados em inglês, incluindo os prompts enviados ao sistema, o código visto pelos LLMs em seus conjuntos de dados e os casos de teste usados para avaliação interna. As sugestões geradas pelo LLM podem ter uma taxa de sucesso menor para código-fonte e comentários escritos em outras linguagens e usando outros conjuntos de caracteres.
  • Erros de sintaxe: O sistema pode sugerir correções que não são alterações de código sintaticamente corretas; por isso, é importante executar verificações de sintaxe nas solicitações de pull.
  • Erros de local: O sistema pode sugerir correções que são código sintaticamente correto, mas são sugeridas no local incorreto, o que significa que, se um usuário aceitar uma correção sem editar o local, ele introduzirá um erro de sintaxe.
  • Erros semânticos: O sistema pode sugerir correções que são sintaticamente válidas, mas que alteram a semântica do programa. O sistema não tem compreensão da intenção do programador ou da base de código em como o código deve se comportar. Ter uma boa cobertura de teste ajuda os desenvolvedores a verificar se uma correção não altera o comportamento da base de código.
  • Vulnerabilidades de segurança e enganos: O sistema pode sugerir correções que não conseguem corrigir a vulnerabilidade de segurança subjacente e/ou introduzem novas vulnerabilidades.
  • Correções parciais: O sistema pode sugerir correções que resolvam apenas parcialmente a vulnerabilidade de segurança ou preservem apenas parcialmente a funcionalidade de código pretendida. O sistema vê apenas um pequeno subconjunto do código na base de código e nem sempre produz soluções globalmente ideais ou corretas.

Limitações das sugestões de dependência de correção automática

Às vezes, uma correção sugerida inclui uma alteração nas dependências da base de código. Se você usar um sistema de gerenciamento de dependências, todas as alterações serão realçadas automaticamente para que o desenvolvedor revise. Antes de mesclar uma solicitação de pull, sempre verifique se as alterações de dependência são seguras e mantêm o comportamento pretendido da base de código.

  • Dependências novas ou atualizadas: O sistema pode sugerir a adição ou atualização de dependências de software como parte de uma correção sugerida. Por exemplo, sugerindo alterar o arquivo package.json para projetos JavaScript para adicionar dependências do npm.
  • Dependências sem suporte ou inseguras: O sistema não sabe quais versões de uma dependência existente são suportadas ou seguras.
  • Dependências fabricadas: O sistema tem conhecimento incompleto das dependências publicadas no ecossistema mais amplo. Isso pode levar a sugestões que adicionam uma nova dependência de software mal-intencionado que os invasores publicaram sob um nome de dependência estatisticamente provável.

Atenuando as limitações das sugestões de correção automática

A melhor maneira de atenuar as limitações das sugestões de correção automática é seguir as melhores práticas. Por exemplo, usando o teste de CI de solicitações de pull para verificar se os requisitos funcionais não são afetados e usando soluções de gerenciamento de dependência, como a API e a ação de revisão de dependência. Para obter mais informações, confira "Sobre a análise de dependência".

É importante lembrar que o autor de uma solicitação de pull mantém a responsabilidade sobre como responder aos comentários de revisão e às alterações de código sugeridas, sejam propostas por colegas ou por ferramentas automatizadas. Os desenvolvedores devem sempre analisar criticamente as sugestões de alterações de código. Se necessário, eles devem editar as alterações sugeridas para garantir que o código resultante e o aplicativo estejam corretos, seguros, atendam aos critérios de desempenho e satisfaçam todos os outros requisitos funcionais e não funcionais do aplicativo.

Próximas etapas