Em outubro de 2024, o GitHub anunciou a disponibilidade geral do Copilot secret scanning, uma ferramenta que utiliza inteligência artificial para detectar senhas genéricas em bases de código de usuários. Este artigo explica como o Copilot secret scanning funciona nos bastidores, os desafios enfrentados durante o desenvolvimento e a estrutura utilizada para testes e iterações. Acompanhe para descobrir como essa tecnologia protege seus repositórios de forma inteligente e eficiente.
O que é o Copilot secret scanning?
O Copilot secret scanning é uma funcionalidade do GitHub Secret Protection, que protege milhões de repositórios no GitHub, detectando centenas de tipos de padrões através do programa de parcerias. A precisão dessas detecções é fundamental para equipes de segurança e desenvolvedores ao lidarem com alertas de segurança.
Historicamente, a abordagem de detecção dependia de expressões regulares, um método eficaz para identificar segredos com formatos estritos e definidos por provedores. No entanto, esse método enfrenta dificuldades com as estruturas sutis e variadas de senhas genéricas, frequentemente gerando ruídos excessivos para as equipes de segurança e desenvolvedores.
Agora, o GitHub detecta senhas genéricas com o GitHub Copilot, usando inteligência artificial para analisar o contexto, como o uso e a localização de um possível segredo, para limitar o ruído e entregar alertas relevantes que são críticos para a saúde e a segurança dos seus repositórios. Essa análise contextual aprimorada garante que os alertas sejam mais precisos e acionáveis.
Atingir um nível de confiança na precisão das senhas foi uma jornada que envolveu muitos casos de teste, iterações de prompts e mudanças de modelos. Vamos explorar o que foi aprendido ao longo do caminho e descobrir os próximos passos. A precisão e a relevância dos alertas são cruciais para a eficiência das equipes de segurança.
Desafios Iniciais na Detecção de Senhas Genéricas com o Copilot secret scanning
No cerne do Copilot secret scanning está uma requisição para um modelo de linguagem grande (LLM), expressa através de um prompt LLM, consistindo em:
- Informações gerais sobre o tipo de vulnerabilidade, neste caso, senhas.
- O local do código fonte e o conteúdo do arquivo onde se acredita que a vulnerabilidade possa existir.
- Uma especificação de formato JSON estrita para a saída do modelo, para permitir o processamento automatizado.
A primeira iteração do prompt usou a técnica de few-shot prompting, que fornece ao LLM exemplos de entradas e saídas para demonstrar como realizar a tarefa. O objetivo era ter um modelo eficiente em termos de recursos para executar as detecções em escala, e a escolha recaiu sobre o GPT-3.5-Turbo. Paralelamente, foi desenvolvido um framework de avaliação offline básico, incluindo casos de teste com curadoria manual, com resultados positivos e negativos, para validar se a abordagem era sólida antes de ser implementada para os clientes.
Essa primeira iteração foi implementada para participantes de uma prévia privada e um problema foi notado de imediato. Embora funcionasse razoavelmente bem na identificação de credenciais na avaliação offline, falhava espetacularmente em alguns repositórios de clientes. O modelo tinha dificuldade em interpretar tipos de arquivos e estruturas não tipicamente encontradas nas linguagens de programação convencionais e nos padrões com os quais os LLMs são treinados.
Essa experiência revelou a complexidade do problema e a natureza limitante dos LLMs, forçando uma reavaliação da abordagem. A diversidade de estruturas de arquivos representou um desafio significativo para o modelo inicial.
Aprimorando a Detecção: Avaliação Offline e Prompting
Em resposta aos resultados iniciais, o framework de avaliação offline foi aprimorado de algumas maneiras importantes. Primeiramente, foram adicionados relatórios de participantes da prévia privada para aumentar a diversidade dos casos de teste. Em seguida, o framework foi aprimorado para que fosse possível identificar visualmente e analisar desvios resultantes de mudanças no modelo ou no prompt. Isso permitiu ver melhor o impacto da personalização de diferentes etapas na estratégia de prompting.
Finalmente, a equipe de segurança de código do GitHub aproveitou os processos de avaliação para criar um pipeline de coleta de dados e usou o GPT-4 para criar casos de teste próprios, baseados em aprendizados de alertas de varredura secreta existentes em repositórios de código aberto. Uma das melhores maneiras de aprender é com inteligência artificial.
Essa avaliação offline aprimorada forneceu a amplitude necessária para medir tanto a precisão quanto a revocação. Precisão é a capacidade de encontrar segredos com mais exatidão, com preocupações com a taxa de falsos positivos, enquanto revocação é a capacidade de encontrar segredos de forma mais confiável, com preocupações com a taxa de falsos negativos.
A partir daqui, uma série de experimentos foi executada para avaliar a qualidade da detecção:
- E se fosse testado um modelo diferente?
- E se o prompt fosse executado várias vezes e as respostas fossem combinadas de alguma forma?
- E se dois prompts diferentes fossem executados em dois modelos diferentes em sequência?
- Como lidar melhor com a natureza não determinística das respostas do LLM?
Mais especificamente, começaram a ser testados alguns mecanismos diferentes para melhorar a detecção com o LLM. Foram testadas diferentes estratégias para aprimorar a precisão e a confiabilidade das detecções.
Foi tentada a votação (fazendo a mesma pergunta ao modelo várias vezes), o que permitiu respostas mais determinísticas, mas não teve impacto significativo na precisão. A votação, embora previsível, não aumentou a precisão das detecções.
Também foi testado o uso de um modelo maior (GPT-4) treinado em um conjunto maior de parâmetros como um scanner de confirmação, para validar a precisão de candidatos encontrados pelo GPT-3.5-Turbo. Isso ajudou a melhorar a precisão sem reduzir a revocação, mas também foi mais intensivo em recursos. Utilizar um modelo maior como confirmador aumentou a precisão, mas exigiu mais recursos computacionais.
Além disso, algumas estratégias de prompting diferentes foram experimentadas, como Fill-in-the-Middle, Zero-Shot e Chain-of-Thought. A equipe colaborou com colegas da Microsoft e usou a técnica MetaReflection, uma nova técnica de aprendizado por reforço offline que permite que aprendizados experienciais de testes anteriores criem um prompt híbrido de Chain of Thought (CoT) e few-shot que melhora a precisão com uma pequena penalidade na revocação. Essa colaboração permitiu aprimorar a precisão com um pequeno impacto na revocação.
No fim, uma combinação de todas essas técnicas foi utilizada e o Copilot secret scanning foi movido para a prévia pública, abrindo-o amplamente para todos os clientes do GitHub Secret Protection. Isso leva ao próximo obstáculo: escala. A combinação de técnicas resultou na abertura do serviço para todos os clientes, mas trouxe novos desafios de escalabilidade.
Escalando a Capacidade para a Prévia Pública
A varredura secreta não só varre os pushes Git recebidos, mas também todo o histórico Git em todos os branches. Com cada novo cliente, os recursos necessários aumentam linearmente. Em vez de simplesmente expandir a capacidade do LLM, o foco foi encontrar o equilíbrio mais eficaz entre valor e custo para garantir o desempenho e a eficiência ideais. Antes de abordar como os recursos foram gerenciados, foram encontradas maneiras de reduzir o uso de recursos, como:
- Identificar e excluir uma classe de alterações da varredura (como arquivos de mídia ou arquivos de idioma que contêm “teste”, “mock” ou “spec” no caminho do arquivo), porque se esperava que nunca contivessem credenciais ou seriam incompreensíveis para o modelo.
- Testar modelos mais recentes, como GPT-4-Turbo e GPT-4o-mini, que deveriam ser menos intensivos em recursos sem comprometer o desempenho e a latência.
- Testar diferentes janelas de contexto para encontrar uma que reduzisse os recursos sem aumentar significativamente a latência para o LLM responder às consultas.
- Fazer melhorias em como o conteúdo que se deseja varrer é tokenizado, incluindo reter alguma memória de tokenizações anteriores ao processar novas partes de um arquivo.
Embora alguns desses esforços tenham sido frutíferos, como limitar o conteúdo que era varrido, outros foram menos eficazes. Por exemplo, dividir o conteúdo em pedaços menores não teve muito impacto, enquanto usar um modelo mais poderoso teve. A limitação do conteúdo varrido se mostrou eficaz, enquanto a divisão em pedaços menores não teve impacto significativo.
No fim, a mudança mais impactante veio da criação de um sistema de gerenciamento de requisições ciente da carga de trabalho, que permitiu maximizar e compartilhar equitativamente a capacidade do LLM contra a variedade de diferentes cargas de trabalho executadas durante as varreduras. Um sistema de gerenciamento de requisições otimizou o uso da capacidade do LLM.
Ao construir o sistema, foi notado um problema fundamental que precisava ser abordado no gerenciamento de capacidade: atribuir limites de taxa específicos a cargas de trabalho individuais (como varrer commits Git recebidos ou varrer o histórico completo) era subótimo. Como cada carga de trabalho estava vinculada a padrões de tráfego específicos (commits Git, por exemplo, tendem a se correlacionar com o horário de trabalho, enquanto a varredura de histórico completo se correlaciona com eventos discretos, como um gerente de segurança ou administrador habilitando o recurso em uma nova organização), era fácil cair em uma situação em que uma carga de trabalho individual poderia atingir os limites de taxa dentro de seu contexto operacional, deixando recursos adicionais disponíveis em outros lugares não utilizados.
Foi tirada grande inspiração de soluções existentes neste espaço, como Doorman, o Freno do próprio GitHub e vários outros algoritmos ponderados, de prioridade justa e relacionados a filas. Foi criado um algoritmo que permite definir uma gama de limites para cada carga de trabalho, impedindo que a carga de trabalho sobrecarregue completamente o LLM, ao mesmo tempo em que permite que ele utilize recursos de outras cargas de trabalho que não estão sendo usados no momento. Essa estratégia foi tão eficaz em maximizar a utilização que acabou sendo usada também no Copilot Autofix e em campanhas de segurança. O algoritmo permitiu um uso mais eficiente dos recursos do LLM, evitando sobrecargas e otimizando a utilização.
Testes Espelhados para a Disponibilidade Geral
Alcançar confiança na qualidade da detecção foi crucial para mover o Copilot secret scanning para a disponibilidade geral. Foi implementado um framework de testes espelhados que executava as mudanças de prompt e filtragem contra um subconjunto de repositórios que participaram da prévia pública. Rescanear esses repositórios com as últimas melhorias permitiu avaliar a mudança nos volumes de alertas reais e nas resoluções de falsos positivos, sem impactar os usuários. Através de ferramentas, a equipe realizou testes para garantir a qualidade na detecção.
Foi encontrada uma enorme queda nas detecções e nos falsos positivos, com pouquíssimas senhas reais faltando. Em alguns casos, foi vista uma redução de 94% nos falsos positivos em todas as organizações! Essa comparação de antes e depois indicou que todas as diferentes mudanças feitas durante a prévia privada e pública levaram a uma maior precisão sem sacrificar a revocação, e que se estava pronto para fornecer um mecanismo de detecção confiável e eficiente para todos os clientes do GitHub Secret Protection.
Lições Aprendidas e Próximos Passos
O Copilot secret scanning está agora detectando senhas em quase 35% de todos os repositórios do GitHub Secret Protection. O monitoramento do desempenho continua e as lições aprendidas são aplicadas à medida que as ferramentas criadas ao longo do caminho são aproveitadas:
- Foco na precisão: Equipes de segurança e desenvolvimento precisam de alertas precisos e acionáveis sem o ruído — este é sempre o objetivo principal.
- Inclusão de casos de teste diversos: A incorporação de exemplos baseados em aprendizados do feedback do cliente no banco de testes continua à medida que as capacidades de detecção são refinadas.
- Gerenciamento eficaz de recursos: Sempre é necessário equilibrar a escalabilidade com o desempenho.
- Inovação colaborativa: A parceria com outras equipes do GitHub e da Microsoft ajuda a ultrapassar os limites do que o Copilot pode alcançar.
Esses aprendizados também são compartilhados no Copilot Autofix, que continua a expandir a cobertura para alertas de varredura de código e ajuda as equipes de desenvolvimento a corrigir alertas de varredura de código rapidamente.
Desde o lançamento da disponibilidade geral, a habilitação para o Copilot secret scanning foi incluída nas configurações de segurança, permitindo que seja controlado quais repositórios estão detectando segredos em todas as organizações ou na empresa. A equipe está dedicada à melhoria contínua através de monitoramento contínuo, testes espelhados e refinamento da abordagem com base no feedback do cliente e nas tendências de detecção. O Copilot secret scanning serve como um componente crítico para uma segurança robusta de aplicativos e evoluirá para atender às necessidades dinâmicas dos usuários.
Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Via The GitHub Blog