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

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

A correção automática Code scanning é uma expansão habilitada de GitHub Copilot de code scanning que fornece aos usuários recomendações direcionadas para ajudá-los a corrigir alertas do code scanning nas pull requests 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. A correção automática usa APIs internas de GitHub Copilot e instâncias privadas de modelos de linguagem grande do OpenAI, como GPT-4, que têm capacidades generativas suficientes para produzir correções sugeridas no código e no texto explicativo para essas correções.

No painel de visão geral de segurança de uma organização, você pode exibir o número total de sugestões de correção automática geradas em pull requests abertas e fechadas na organização por um determinado período. Para obter mais informações, confira a "Exibir insights de segurança" na documentação do GitHub Enterprise Cloud.

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 pull requests. 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.

Idiomas com suporte

A correção automática Code scanning oferece suporte à geração de correções para um subconjunto de consultas incluídas no conjunto de consultas padrão para JavaScript, TypeScript, Python, Java e C#. Para obter mais informações sobre o conjunto de consulta padrão, consulte "Conjuntos de consultas CodeQL".

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 de branch da 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.

O processo de geração de correções não coleta ou utiliza dados do cliente além do escopo descrito acima. Portanto, o uso desse recurso é regido pelos termos e condições existentes associados a GitHub Advanced Security. Além disso, os dados tratados pela correção automática code scanning não são estritamente empregados para fins de treinamento de LLM. Para obter mais informações sobre os termos e condições de GitHub Advanced Security, consulte "Termos do GitHub para produtos e recursos adicionais."

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 1.870 alertas 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

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 que usam idiomas com suporte pela correção automática devem seguir um padrão semelhante.

• A correção automática provavelmente adicionará uma sugestão de código à maioria dos alertas.
• 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.

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. 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 pull requests.
• 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 pull requests 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

• "Sobre alertas de digitalização de códigos"
• Alertas de varredura de código de triagem em pull requests na documentação do GitHub Enterprise Cloud.