> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Swarm
> 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](https://devin.ai/blog/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](https://devin.ai/blog/security-eval) com base em um conjunto de referência de vulnerabilidades publicadas do GitHub Advisory Database.
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](#access-and-permissions) para mais detalhes.
## Faça sua primeira varredura
1. Abra **Security** na barra lateral esquerda e clique em **Start scan**.
2. Em **Single repo**, escolha um repositório para varrer.
3. Verifique se **Interactive mode** está ativado.
4. Clique em **Run Scan**.
5. Quando o [modelo de ameaças](#interactive-mode) proposto estiver pronto, revise-o e clique em **Looks good, start scanning** ou envie feedback.
6. À medida que os resultados aparecerem, revise as evidências e [trate os resultados](#act-on-a-finding) 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.
## Revise e aja sobre os resultados
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.
### O que compõe um resultado
Um resultado inclui:
* **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.
### Tome medidas em relação a um resultado
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.
## Perfis de varredura
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.
### Criar um perfil
Você pode criar um perfil de duas maneiras:
* **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.
### Informações básicas
* **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.
### Modelo de ameaça
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.
```text theme={null}
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 administrativas
e acessos a dados pertencentes ao tenant. Trate scripts internos de desenvolvimento e ferramentas
exclusivamente locais como fora do escopo. Priorize bypasses de autenticação, acesso entre tenants, vazamento
de tokens, injeção e SSRF.
```
### Orientações para investigação
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.
```text theme={null}
Trace untrusted input from the route through middleware and service layers to the
sensitive operation. Check authentication, authorization, tenant scoping, validation,
and escaping at every boundary. Identify the exact reachable path and cite the relevant
files and lines. Do not report a theoretical issue when an effective mitigation blocks
the path.
```
### Orientações de triagem
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.
```text theme={null}
Agrupe os resultados que compartilham a mesma causa raiz. Trate execução remota de código
não autenticada e acesso de escrita entre tenants como crítico. Trate acesso de leitura entre tenants e
divulgação de credenciais como alto. Trate problemas de disponibilidade para um único usuário como médio, a menos
que possam afetar a infraestrutura compartilhada. Classifique recomendações de defesa em profundidade como baixo.
```
### Validação de runtime
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.
```text theme={null}
Use o setup de desenvolvimento documentado do repositório. Inicie a API e crie dois
tenants não produtivos com um usuário de teste em cada. Tente a requisição suspeita como
um 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](#configure-runtime-validation) para ver orientações sobre o ambiente.
### Relatório
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.
```text theme={null}
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.
```
### Orientações de remediação
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.
```text theme={null}
Prefira a menor alteração segura possível e preserve o comportamento existente da API pública. Adicione um
teste de regressão que falhe antes da correção e passe depois dela. Execute os comandos de
lint e teste do pacote afetado. Evite grandes atualizações de dependências, a menos que a vulnerabilidade não possa
ser corrigida com segurança sem isso.
```
### Opções avançadas
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.
### Perfis de organização e do Enterprise
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.
### Modo interativo
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.
### Configurar a validação de runtime
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](/pt-BR/onboard-devin/environment/blueprints), 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.
## Ampliar a varredura
### Fazer varredura em vários repositórios
Use a aba **Todos os repositórios** na caixa de diálogo Nova varredura para enfileirar varreduras em uma organização:
1. Opcionalmente, insira um **filtro de nome do repositório**.
2. Opcionalmente, selecione um perfil de varredura.
3. Mantenha **Pular repositórios já varridos** ativado para excluir repositórios que já foram varridos com o perfil selecionado.
4. Clique em **Prévia**.
5. 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.
### Auto Scan
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](/pt-BR/product-guides/automations). 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.
### Varrer novos commits
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.
## Gerenciar e monitorar varreduras
Dependendo da varredura e do perfil dela, o cabeçalho da varredura pode incluir:
* **Relatórios** — baixe os relatórios gerados para a varredura.
* **Uso** — visualize os ACUs consumidos, a quantidade de sessões, a duração da varredura e as estatísticas de PR.
* **Sessão** — abra a sessão principal do Devin que executou a varredura.
* **Exportar como CSV** — exporte os resultados da varredura.
* **Arquivar** ou **Desarquivar** — oculte a varredura da lista padrão ou restaure-a nela.
* **varrer novos commits** — inicie uma varredura incremental.
As varreduras são executadas como sessões do Devin e consomem [ACUs](/pt-BR/admin/billing/usage).
### Dashboard de Security
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.
## Acesso e permissões
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](/pt-BR/enterprise/security-access/custom-roles).
## Compare o Security Swarm com outro scanner
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.
## FAQ
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.
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](#act-on-a-finding) para fornecer o contexto ausente em varreduras futuras.
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](#configure-runtime-validation) suficiente para que Devin possa fazer build, executar, carregar dados iniciais e autenticar a aplicação com segurança.
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.
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](#scan-profiles) reutilizável, use o [modo interativo](#interactive-mode) para revisar o modelo de ameaças proposto e forneça feedback quando um resultado deixar de considerar um contexto importante.
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.