Como conectar APIs de LLM ao escaneamento de vulnerabilidades de código aberto para reduzir o tempo de revisão de segurança

O código aberto é conveniente, mas traz riscos proporcionais. De acordo com uma pesquisa de 2025, desde que a IA começou a escrever código em nome dos desenvolvedores, a taxa de ocorrência de bugs saltou 41% em relação ao ano anterior. Para um responsável por segurança que precisa revisar sozinho dezenas de milhares de linhas de bibliotecas externas, isso é nada menos que um desastre. Como é impossível ler todo o código, precisamos transformar a IA em nossa aliada. Reunimos aqui como criar seu próprio fluxo de trabalho de segurança que opere de forma inteligente, como o Project Glasswing.

Instalando um mecanismo de segurança de IA no GitHub Actions

Automatizar a revisão de segurança permite eliminar tarefas repetitivas e simples que consumiam mais de 10 horas por semana. Isso também evita erros que passariam despercebidos pelo olho humano. Tente construir um pipeline que chame APIs de LLM no ambiente do GitHub Actions para escanear em tempo real sempre que um Pull Request for aberto. A estratégia principal não é apenas fazer perguntas, mas separar a identificação da auditoria.

• Proteção da chave de API: Registre a LLM_API_KEY nos GitHub Secrets. Ela deve ser mantida no armazenamento criptografado Libsodium para evitar vazamentos acidentais da chave para o exterior.
• Configuração de diretórios-alvo: Não há necessidade de olhar todos os arquivos. Use o path-filter na configuração YAML para selecionar e escanear apenas diretórios sensíveis, como src/auth ou lib/core, onde um incidente seria fatal.
• Validação cruzada: Na primeira etapa, faça o LLM analisar a estrutura do código e escrever notas; na segunda etapa, execute escaneamentos repetidos (pelo menos 3 vezes) com base nessas notas. Como a IA ocasionalmente alucina, é necessário um processo de comparar os resultados várias vezes para garantir a precisão.

Com essa configuração concluída, o responsável pela segurança só precisa revisar o relatório de segurança resumido pela IA, em vez de dezenas de milhares de linhas de código.

Filtrando os perigos reais com CVSS e EPSS

Ferramentas de IA são boas em encontrar vulnerabilidades, mas também geram muitos falsos positivos. Se 100 itens forem encontrados e 15 deles forem falsos, a equipe de desenvolvimento inevitavelmente ficará frustrada. Para não desperdiçar recursos limitados de desenvolvimento, é necessário um critério para filtrar as ameaças reais. Defina as prioridades mesclando a pontuação CVSS 4.0 com o índice EPSS, que indica se ataques reais estão ocorrendo no momento.

1. Verificação da pontuação base: Primeiro, observe a gravidade técnica através do CVSS 4.0 Base Score.
2. Ajuste da pontuação ambiental: Subtraia ou adicione pontos dependendo se o código é uma função exposta à internet externa ou uma função que roda apenas na rede interna.
3. Contraste com a probabilidade de ataque: Consulte o banco de dados EPSS para verificar se essa vulnerabilidade está em voga entre os atacantes agora. Se a probabilidade de ataque ultrapassar 50%, pare tudo e aplique o patch imediatamente.

Ao focar apenas em classificações críticas de 9.0 ou superiores, o nível de segurança sobe drasticamente. Reduzir solicitações de correção desnecessárias também diminui naturalmente os conflitos com a equipe de desenvolvimento.

Validando e implantando códigos de correção em Sandbox

As correções sugeridas pela IA podem parecer perfeitas superficialmente, mas às vezes quebram funcionalidades que estavam operando normalmente. Empresas como a Shopify usam IA, mas não confiam cegamente no código gerado. É necessário ter um procedimento para verificar automaticamente se o código do patch é seguro em ambientes isolados como Firecracker ou gVisor.

• Criação de ambiente isolado: Use a sbx CLI para subir uma MicroVM que tenha o mesmo ambiente de runtime do serviço atual.
• Simulação de ataque: Verifique se a vulnerabilidade é realmente explorável com um script de ataque, aplique o patch fornecido pela IA e tente o ataque novamente para checar se ele foi bloqueado.
• Teste de funcionalidade: Execute os testes unitários existentes com o patch aplicado. Não adianta nada bloquear a segurança se o login parar de funcionar.

Essas salvaguardas evitam que códigos criados pela IA — que estão "quase certos", mas apresentam erros sutis — cheguem ao servidor de produção.

Escrevendo relatórios que os mantenedores de código aberto aceitem imediatamente

Não devemos parar após corrigir apenas o nosso serviço. Reportar falhas do próprio código aberto que estamos utilizando para o projeto original também é dever do responsável por segurança. Mantenedores são pessoas ocupadas, então você deve fornecer evidências claras. Utilize os canais PVR do GitHub para entregar o relatório de forma responsável.

No título, descreva claramente o tipo e a localização da vulnerabilidade. Incluir um caminho de reprodução que qualquer um possa seguir e capturas de tela é o básico. O melhor é enviar junto o código de correção que você já validou anteriormente na sandbox. Ao reduzir o tempo de revisão para o mantenedor, a probabilidade de o patch ser aceito aumenta drasticamente. Um relatório bem feito comprova a capacidade técnica da empresa e pode até resultar na obtenção de um número oficial de CVE.