Encontre, faça a triagem e corrija vulnerabilidades de segurança em seus repositórios
Security Swarm é o produto de varredura de segurança e remediação do Devin. Ele cria um modelo de ameaças adaptado ao seu código, investiga e valida possíveis vulnerabilidades e ajuda você a corrigir os problemas encontrados por meio de pull requests. Ele pode identificar vulnerabilidades como execução remota de código (RCE), injeção de SQL, path traversal, falsificação de requisição do lado do servidor (SSRF), bypasses de autorização, bugs de segurança de memória, vulnerabilidades de negação de serviço e muito mais. Ele pode até identificar explorações encadeadas que abrangem vários arquivos.Security Swarm é uma orquestração personalizada de Devins que chamamos de Agentic MapReduce. Ele divide seu repositório entre vários Devins em paralelo, oferecendo ampla cobertura e investigação aprofundada, ao mesmo tempo em que mantém os custos sob controle, o que torna viável varrer grandes bases de código. Também avaliamos o Security Swarm com base em um conjunto de referência de vulnerabilidades publicadas do GitHub Advisory Database.
Pré-requisitos
Para executar uma varredura:
Sua organização precisa ter acesso ao repositório que você quer varrer.
Você precisa estar autorizado a usar sessões do Devin.
Você precisa da permissão Use code scans.
Para configurar um agendamento do Auto Scan, você também precisa de Manage code scans e de permissão para gerenciar automações.
Se você não vir Security na barra lateral ou não conseguir iniciar uma varredura, peça a um administrador para revisar sua função. Consulte Acesso e permissões para mais detalhes.
Abra Security na barra lateral esquerda e clique em Start scan.
Em Single repo, escolha um repositório para varrer.
Verifique se Interactive mode está ativado.
Clique em Run Scan.
Quando o modelo de ameaças proposto estiver pronto, revise-o e clique em Looks good, start scanning ou envie feedback.
À medida que os resultados aparecerem, revise as evidências e trate os resultados que exigem atenção.
Para varreduras repetíveis, crie um perfil que capture seu escopo, modelo de ameaças, critérios de severidade, etapas de validação e restrições de remediação.
Abra uma varredura para ver seus resultados. A página exibe uma lista de resultados à esquerda, agrupados por severidade, e os detalhes do resultado selecionado à direita.As abas de status mostram uma contagem em tempo real:
Open — precisa de atenção.
Reviewed — foi revisado e não requer mais ação.
Dismissed — foi identificado como falso positivo ou duplicado.
Enquanto uma varredura estiver em execução, a página será atualizada automaticamente à medida que os resultados forem chegando.
Reviewed é um status do fluxo de trabalho, não a confirmação de que uma correção recebeu merge. Um resultado pode ser marcado como Reviewed manualmente ou quando uma varredura posterior determinar que ele não está mais presente.
Severidade, status, explorabilidade, confiança e categoria.
O caminho do arquivo e os trechos de código afetados.
Uma descrição do problema e uma recomendação de remediação.
Um resultado de validação em tempo de execução, evidências de suporte e artefatos de validação.
Pull requests associadas e seu estado: aberta, mesclada ou fechada.
Responsáveis pelo código e notas, quando disponíveis.
Trate um padrão de código arriscado como um indício, não como prova de uma vulnerabilidade. Verifique se o resultado mostra um caminho alcançável a partir de uma entrada controlada por um invasor, leva em conta os controles de validação e autorização e explica um impacto concreto na segurança.
Inicia uma sessão do Devin para corrigir o problema e abrir um PR. A sessão e o PR resultante ficam registrados no resultado.
Envia contexto para uma sessão de feedback que refina o perfil de varredura para varreduras futuras. Por exemplo, explique que um fluxo de dados reportado é protegido por um gateway interno para que as varreduras futuras possam levar esse controle em conta.
Define um override para a severidade do resultado, com contexto opcional para Devin. Por exemplo, reduza a severidade quando a exploração exigir acesso interno privilegiado e inclua essa restrição como contexto.
Marca o resultado como Aberto, Revisado ou Descartado. Mantenha um resultado como Aberto enquanto ele exigir ação, marque-o como Revisado após a triagem ou descarte-o quando for um falso positivo ou duplicado.
Um perfil de varredura controla o escopo da varredura e fornece orientações para cada etapa da varredura. Cada varredura pode usar um perfil. Para avaliar um repositório em relação a vários perfis de invasor ou categorias de ameaça, execute varreduras separadas com perfis diferentes.
Um modelo de ameaça específico é uma das formas mais eficazes de manter a cobertura consistente entre as varreduras. Defina o invasor, os ativos sensíveis, os limites de confiança, os principais pontos de entrada e as exclusões explícitas.
Gerencie os perfis na aba Profiles da página Security.
Gerar com Devin — descreva o aplicativo, as ameaças, o escopo, as exclusões e os padrões de severidade em linguagem natural. Devin cria um rascunho do perfil para você.
Criar manualmente — preencha cada campo do perfil por conta própria.
Gerar com Devin é um ponto de partida útil, mas revise todos os campos gerados antes de usar o perfil. Deixar um campo opcional de orientação em branco faz com que o Security Swarm aplique o comportamento nativo dessa etapa.
Nome do perfil — nomeie a superfície da aplicação ou a categoria de ameaça, em vez da equipe que executa a varredura. Exemplo: Autorização de API multi-tenant.
Descrição — resuma o escopo do perfil e o objetivo de segurança. Exemplo: Identificar vulnerabilidades de autenticação, autorização e isolamento de tenant na API pública.
Os exemplos abaixo formam um único perfil para uma API multi-tenant. Adapte os limites, os comandos e os critérios de severidade à sua aplicação.
Descreva o atacante, os ativos sensíveis, as fronteiras de confiança, os pontos de entrada importantes e tudo o que estiver explicitamente fora do escopo. Essas orientações definem as regras que o Devin gera antes do início da investigação.
Considere um atacante não autenticado na internet ou um usuário autenticado em um tenant.Concentre-se em handlers HTTP públicos, callbacks OAuth, tokens de API, ações administrativase acessos a dados pertencentes ao tenant. Trate scripts internos de desenvolvimento e ferramentasexclusivamente locais como fora do escopo. Priorize bypasses de autenticação, acesso entre tenants, vazamentode tokens, injeção e SSRF.
Defina como Devin deve investigar um possível problema e quais evidências deve coletar. Peça que ele leve em conta as mitigações existentes e diferencie vulnerabilidades exploráveis de riscos teóricos.
Trace untrusted input from the route through middleware and service layers to thesensitive operation. Check authentication, authorization, tenant scoping, validation,and escaping at every boundary. Identify the exact reachable path and cite the relevantfiles and lines. Do not report a theoretical issue when an effective mitigation blocksthe path.
Defina como o Devin deve deduplicar e priorizar resultados. Inclua seus critérios de severidade para que os resultados estejam alinhados aos padrões da sua organização.
Agrupe os resultados que compartilham a mesma causa raiz. Trate execução remota de códigonão autenticada e acesso de escrita entre tenants como crítico. Trate acesso de leitura entre tenants edivulgação de credenciais como alto. Trate problemas de disponibilidade para um único usuário como médio, a menosque possam afetar a infraestrutura compartilhada. Classifique recomendações de defesa em profundidade como baixo.
Ative a validação de runtime quando Devin puder fazer o build e testar a aplicação com segurança. Explique como iniciar a aplicação, criar dados de teste, se autenticar e demonstrar a fronteira de segurança esperada.
Use o setup de desenvolvimento documentado do repositório. Inicie a API e crie doistenants não produtivos com um usuário de teste em cada. Tente a requisição suspeita comoum usuário do outro tenant e verifique tanto a resposta HTTP quanto os dados persistidos.Não chame serviços de produção nem modifique dados de produção.
Uma validação sem sucesso nem sempre descarta um resultado. Revise o resultado da validação e os artefatos para determinar se uma mitigação eficaz bloqueou a exploração ou se o ambiente configurado impediu que o Devin concluísse o teste.
A validação de runtime inicia uma sessão separada do Devin para cada resultado. Consulte Configurar a validação de runtime para ver orientações sobre o ambiente.
Ative os relatórios quando precisar de um artefato com um resumo após a varredura. Especifique o público-alvo e as informações que o relatório deve destacar.
Escreva um resumo executivo para as lideranças de Security e engenharia. Liste primeiro os resultados críticos e altos confirmados, seguidos dos resultados não validados. Inclua os componentes afetados, o status de validação, o status do pull request e um plano de remediação priorizado.
Especifique as restrições que Devin deve seguir quando você atribuir um achado para remediação. Inclua expectativas de teste, requisitos de compatibilidade e práticas a serem evitadas.
Prefira a menor alteração segura possível e preserve o comportamento existente da API pública. Adicione umteste de regressão que falhe antes da correção e passe depois dela. Execute os comandos delint e teste do pacote afetado. Evite grandes atualizações de dependências, a menos que a vulnerabilidade não possaser corrigida com segurança sem isso.
Abra Avançado para controlar o escopo dos arquivos e os lotes de investigação:
Include globs — restrinja a varredura aos arquivos que correspondem aos padrões. Por exemplo, apps/api/** e packages/auth/**.
Exclude globs — remova arquivos irrelevantes do escopo selecionado. Por exemplo, **/generated/**, **/vendor/** e **/fixtures/**.
Batch size — controle quantos arquivos com indícios são agrupados em cada lote de investigação. Mantenha o valor padrão, a menos que você esteja ajustando deliberadamente o comportamento da varredura. O intervalo permitido é de 1 a 500; o padrão é 5.
Exclusões amplas demais podem ocultar código vulnerável ou remover o contexto necessário para entender um fluxo de dados. Exclua apenas arquivos que você tem certeza de que são irrelevantes para este perfil.
Novos perfis são restritos à organização. Depois, os admins do Enterprise podem alterar a visibilidade de um perfil para Enterprise, tornando-o disponível em todo o Enterprise.Perfis do Enterprise só podem ser editados ou arquivados por admins do Enterprise. Outros usuários com acesso ao Security podem visualizá-los e usá-los, mas não podem modificá-los.
Com o Modo interativo ativado, Devin cria uma proposta de modelo de ameaças e pausa antes da investigação. A página de varredura exibe as regras propostas e permite que você:
Tudo certo, iniciar varredura — aceite o modelo de ameaças e inicie a investigação.
Enviar feedback sobre o modelo de ameaças — descreva o que adicionar, remover ou enfatizar e, em seguida, revise o modelo atualizado.
Use o modo interativo na primeira varredura de um repositório e sempre que sua superfície de risco ou perfil mudarem significativamente. Depois que o perfil incorporar as diretrizes aprovadas, as varreduras de rotina poderão ser executadas sem essa pausa.
A validação de runtime só é executada quando o perfil selecionado está com essa validação ativada e inclui orientações de validação. Forneça ao Devin informações suficientes para fazer o build, executar, popular dados e autenticar a aplicação no sandbox.Se o repositório tiver configuração declarativa, o Devin poderá reutilizar a configuração de build e instalação. Caso contrário, adicione os comandos de configuração necessários às orientações de validação do perfil.
Não coloque credenciais de produção nem valores secretos diretamente nas orientações do perfil. Use contas e credenciais de teste não produtivas já fornecidas pela configuração de ambiente da sua organização.
Use a aba Todos os repositórios na caixa de diálogo Nova varredura para enfileirar varreduras em uma organização:
Opcionalmente, insira um filtro de nome do repositório.
Opcionalmente, selecione um perfil de varredura.
Mantenha Pular repositórios já varridos ativado para excluir repositórios que já foram varridos com o perfil selecionado.
Clique em Prévia.
Revise os repositórios encontrados, desmarque os que não quiser varrer e confirme.
A prévia é uma simulação. Alterar o filtro, o perfil ou a opção de pular torna a prévia inválida, para que você não possa confirmar uma lista obsoleta.
A Auto Scan executa periodicamente a varredura dos commits adicionados desde a última varredura concluída. Você pode configurá-la:
Ao iniciar uma varredura de um único repositório, selecionando um agendamento diário, semanal, mensal ou personalizado.
Em uma varredura existente, adicionando, editando, desativando ou executando imediatamente seu agendamento.
A Auto Scan é implementada por meio de uma automação. Para configurá-la, é necessário ter Gerenciar varreduras de código e permissão para gerenciar automações. Os horários do agendamento são exibidos no seu fuso horário local.
Clique em Varrer novos commits em uma varredura concluída para investigar os commits adicionados desde o último commit varrido. O Auto Scan usa o mesmo comportamento incremental, tornando as varreduras subsequentes menos custosas do que repetir a varredura de todo o escopo do repositório.
Depois que a organização conclui sua primeira varredura, a página Security exibe um dashboard de toda a organização referente aos últimos 7, 30 ou 90 dias:
Estatísticas de pull requests — pull requests criados, merged, abertos e fechados, além da taxa de merge.
Resultados ao longo do tempo — resultados agrupados por severidade no período selecionado.
O acesso ao Security é controlado por meio das permissões de varredura de código no editor de funções:
Permissão
O que ela desbloqueia
Funções padrão
Visualizar varreduras de código
Visualizar varreduras, perfis, resultados e sessões de varredura associadas.
Admin
Usar varreduras de código
Iniciar varreduras, criar perfis da organização, enviar feedback sobre resultados, ajustar resultados, alterar o status dos resultados e atribuir resultados ao Devin.
Admin
Gerenciar varreduras de código
Arquivar ou desarquivar varreduras e configurar agendamentos do Auto Scan.
Admin
Gerenciar varreduras de código da conta
Promover perfis da organização para o escopo do Enterprise e editar ou arquivar perfis do Enterprise.
Administrador do Enterprise
Iniciar varreduras, enviar feedback e atribuir resultados ao Devin também exigem permissão para usar sessões do Devin. O Auto Scan também requer permissão para gerenciar automações.Por padrão, os membros não recebem permissões de varredura de código. Os proprietários têm todas as permissões, e os administradores podem conceder permissões aos membros por meio de funções personalizadas.
Para que a comparação seja útil, dê aos dois scanners o mesmo escopo, modelo de ameaça, critérios de severidade e expectativas de validação. Caso contrário, diferenças de configuração podem mascarar diferenças na capacidade subjacente.Use perfis para definir os critérios de comparação, o modo interativo para confirmar o modelo de ameaça gerado e a validação de runtime para aplicar o mesmo padrão de evidência aos resultados reportados.
O Security Swarm investiga possíveis vulnerabilidades no contexto do seu repositório, em vez de apenas reportar padrões arriscados isoladamente. Devin rastreia fluxos de dados relevantes, verifica controles de validação e autorização e avalia se o problema tem um impacto concreto na segurança.Cada resultado inclui um nível de confiança e evidências de suporte. Revise essas evidências antes de tomar qualquer ação, especialmente quando um resultado não tiver sido validado em validação de runtime.
Quais evidências devo revisar em um resultado?
Verifique o código afetado, o ponto de entrada, o fluxo de dados, as mitigações existentes, o impacto declarado, a confiança e a explorabilidade. Quando a validação de runtime estiver ativada, revise também o resultado da validação e os artefatos de suporte.Se as evidências não considerarem um controle ou indicarem um impacto sem respaldo, use Feedback para fornecer o contexto ausente em varreduras futuras.
O que a validação de runtime acrescenta?
A validação de runtime tenta reproduzir um resultado fazendo o build e exercitando a aplicação em um ambiente isolado. Uma validação bem-sucedida fornece evidências mais fortes de explorabilidade, enquanto uma validação malsucedida pode identificar suposições ou limitações do ambiente que exigem análise adicional.A validação de runtime é opcional e exige orientação de validação suficiente para que Devin possa fazer build, executar, carregar dados iniciais e autenticar a aplicação com segurança.
Como o Security Swarm encontra vulnerabilidades que abrangem vários arquivos?
O Security Swarm analisa partes do repositório em paralelo e combina os resultados em uma visão de todo o repositório. Isso permite identificar relações entre componentes, como um endpoint expor um identificador necessário para explorar outro endpoint.Qualquer resultado encadeado ainda deve identificar os caminhos de código relevantes e explicar como as condições individuais se combinam em um impacto concreto.
Por que os resultados podem variar entre varreduras?
O Security Swarm usa análise agentic, portanto varreduras diferentes podem não produzir resultados ou redações idênticos. Um escopo focado, um modelo de ameaças explícito, critérios de severidade claros e orientações específicas de investigação ajudam a manter a cobertura consistente.Registre esses requisitos em um perfil de varredura reutilizável, use o modo interativo para revisar o modelo de ameaças proposto e forneça feedback quando um resultado deixar de considerar um contexto importante.
Uma varredura concluída significa que o repositório não tem outras vulnerabilidades?
Nenhum scanner de segurança pode garantir cobertura completa. Os resultados dependem do escopo selecionado, da orientação do perfil, do contexto disponível do repositório e de os resultados poderem ser validados no ambiente configurado.Execute varreduras separadas para diferentes modelos de atacante ou categorias de ameaça, mantenha os perfis atualizados conforme a aplicação muda e use o Security Swarm em conjunto com suas práticas atuais de revisão de segurança e testes.
