> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Equipes e Permissões
> Gerencie o acesso de equipes, funções e permissões refinadas em toda a sua organização
Visão Geral
A ZeroPath usa um sistema de **autorização refinada (FGA)** para controlar o acesso a recursos dentro da sua organização. As equipes agrupam usuários e podem ser atribuídas a repositórios específicos, permitindo que você controle quem vê o quê.
Gerenciamento de Equipes
Criando Equipes
1. Navegue até **Settings → Teams** no dashboard.
2. Clique em **"Create Team"**.
3. Dê à equipe um **nome** e uma descrição opcional.
4. Adicione **membros** por e-mail ou nome de usuário.
5. Atribua os **repositórios** aos quais a equipe deve ter acesso.
Membros da Equipe
As equipes podem incluir:
* **Usuários** — pessoas com contas ZeroPath na sua organização
* **Contribuidores** — contribuidores de código identificados a partir de dados de Git blame (correspondidos por e-mail, nome ou nome de usuário no VCS)
Os contribuidores são associados automaticamente às equipes quando os metadados de seus commits git correspondem à identidade de um membro da equipe.
Vinculando Contribuidores Não Correspondidos
Quando a ZeroPath identifica contribuidores de código que não foram correspondidos a uma conta de usuário, eles aparecem no painel **Unmatched Contributors**. A partir dele você pode:
* **Pesquisar contribuidores** por nome, nome de usuário ou e-mail para encontrar rapidamente a pessoa que deseja vincular.
* **Pesquisar membros da organização** dentro do menu de atribuição para encontrar a conta correta.
* **Vincular contribuidores individualmente** — cada contribuidor pode ser vinculado de forma independente, sem bloquear outras operações de vinculação.
Sincronização de Equipes do GitHub
Você pode mapear a estrutura de equipes do GitHub para as equipes de controle de acesso da sua organização ZeroPath.
Há duas formas de sincronizar:
* **Sincronização contínua (automática)** — ative a sincronização automática para manter as equipes alinhadas sem intervenção. Quando ativada,
a ZeroPath sincroniza suas equipes do GitHub em um agendamento recorrente de hora em hora. Você pode ativar ou desativar isso
na seção **GitHub Team Sync** em **Settings -> Teams**.
* **Sincronização única** — clique em **Sync now** para executar uma única sincronização imediatamente, sem ativar
a sincronização contínua. Isso é útil para uma importação inicial ou uma atualização manual.
A seção de sincronização mostra:
* Se a sincronização contínua está atualmente ativada ou desativada.
* O timestamp da última sincronização concluída, para que você possa confirmar quando os dados das equipes foram atualizados pela última vez.
* Um indicador de progresso enquanto uma sincronização está em andamento.
Após a conclusão de uma sincronização, quaisquer contribuidores do GitHub que não puderam ser correspondidos a uma conta de usuário
ZeroPath aparecem no painel **Unmatched Contributors** para vinculação manual.
Permissões Padrão de Equipe
Você pode configurar permissões de base que são aplicadas automaticamente às equipes criadas pela sincronização de equipes do GitHub. Isso é especialmente útil ao habilitar o controle de acesso pela primeira vez, já que equipes recém-sincronizadas começam sem nenhuma permissão por padrão.
Em **Settings → Teams**:
1. Clique em **"Configure Defaults"** para abrir o editor de Default Team Permissions.
2. Defina as permissões de base que cada nova equipe sincronizada deve receber, em três categorias (veja abaixo).
3. Clique em **"Save Defaults"** para persistir suas alterações.
4. Clique em **"Apply to All Teams"** para aplicar retroativamente os padrões configurados a todas as equipes existentes na sua organização. As permissões existentes são preservadas — os padrões são adicionados por cima.
Ao habilitar o controle de acesso pela primeira vez, um banner de aviso explica que equipes sem permissões configuradas não terão acesso. Você pode dispensar esse banner depois de configurar as permissões das suas equipes ou de aplicar os padrões.
Categorias de Permissões
O editor de permissões padrão organiza as permissões em três categorias, cada uma exibida com uma contagem resumida de quantos padrões estão selecionados no momento:
**Organization Permissions** — Controla o que as equipes sincronizadas podem fazer no nível da organização, agrupado em:
| Grupo | Permissões |
| ------------------------- | ---------------------------------------------------------------------- |
| **Member Management** | Editar funções de membros, convidar membros, remover membros |
| **Team Management** | Visualizar equipes, criar equipes, gerenciar equipes |
| **Installations** | Visualizar, criar e excluir instalações de VCS (GitHub, GitLab etc.) |
| **API Tokens** | Visualizar, criar e excluir tokens de API |
| **Alerts & Monitoring** | Visualizar, editar, criar e excluir alertas de segurança |
| **Repository Management** | Criar repositórios e alvos de scan de repositórios enviados por upload |
| **Custom Reports** | Visualizar, criar e excluir relatórios personalizados salvos |
| **Assistant** | Abrir o assistente e executar chats do assistente no escopo do usuário |
**Repository Permissions** — As permissões padrão de repositório são aplicadas universalmente, ou seja, as equipes sincronizadas recebem essas permissões em todos os repositórios da organização. Os grupos incluem:
| Grupo | Permissões |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Repository Access** | Visualizar repositório |
| **Security Scans** | Visualizar scans, iniciar scans, cancelar scans |
| **Issue Management** | Arquivar issues, marcar como verdadeiro/falso positivo, exigir contexto para falsos positivos, abrir/fechar issues, editar prioridade, excluir issues |
| **Patches & Fixes** | Gerar patches, criar pull requests |
| **PR Security Checks** | Ignorar verificações de segurança de pull requests |
**Team Self-Management** — Controla se as equipes podem gerenciar suas próprias configurações e composição por padrão. As permissões individuais incluem editar a equipe, adicionar membros, remover membros e excluir a equipe.
Você pode alternar grupos inteiros de permissões de uma vez clicando no cabeçalho do grupo, ou alternar permissões individuais dentro de um grupo. Um botão **Reset** permite descartar alterações não salvas e reverter para o último estado salvo.
Permissões
A ZeroPath usa permissões baseadas em funções no nível da organização. As principais categorias de permissões incluem:
| Categoria | Permissões |
| ----------------------------- | -------------------------------------------------------------------------------------------------- |
| **Issues** | Visualizar, gerenciar, marcar como falso positivo, exigir contexto para falsos positivos, arquivar |
| **Scans** | Iniciar scans, cancelar scans, visualizar histórico de scans |
| **Repositórios** | Adicionar, remover, configurar repositórios |
| **Agente** | Visualizar, gerenciar e executar o AI AppSec Assistant |
| **Integrações** | Conectar e gerenciar Jira, Linear, Slack, Wiz |
| **Tokens de API** | Criar, visualizar, excluir tokens de API |
| **Patches** | Gerar patches, aprovar patches, criar PRs |
| **Configurações** | Gerenciar configurações da organização, configurações do scanner |
| **Equipes** | Criar, editar, excluir equipes |
| **Relatórios Personalizados** | Visualizar, criar, excluir relatórios personalizados salvos |
Acesso a Repositórios
As equipes podem ter escopo limitado a repositórios específicos. Ao atribuir repositórios a uma equipe, você pode pesquisar repositórios por nome, e a lista suporta paginação, facilitando encontrar os repositórios certos mesmo em organizações com um grande número de repositórios conectados.
Quando uma equipe é atribuída a um repositório:
* Os membros da equipe podem visualizar resultados de scan e achados desse repositório
* Notificações e alertas são roteados para a equipe apropriada
* A atribuição via Git blame vincula os achados aos membros da equipe que escreveram o código afetado
Acesso a Repositórios Baseado em Tags
Além de selecionar repositórios individuais, você pode conceder a uma equipe acesso a repositórios por meio de **tags**. Quando você seleciona uma tag, a equipe recebe as permissões de repositório configuradas em todos os repositórios que pertencem àquela tag. O acesso é atualizado automaticamente conforme repositórios entram ou saem da tag — não é necessário ajustar manualmente a composição da equipe quando seu conjunto de repositórios muda.
Para configurar o acesso baseado em tags:
1. Abra as configurações de uma equipe e navegue até o painel **Permissions**.
2. Em **Repository Access**, selecione **Selected repositories**.
3. Na seção **Tags**, selecione uma ou mais tags para conceder acesso a todos os repositórios dentro dessas tags.
4. Salve as permissões da equipe.
Cada tag mostra o número de repositórios membros ao lado do nome. Tags **auto-synced** (cuja composição é definida por propriedades personalizadas do GitHub) são rotuladas como tal — o acesso da equipe acompanha automaticamente as mudanças na composição de repositórios da tag. Tags marcadas como **default** são aplicadas automaticamente a cada repositório recém-adicionado, de modo que equipes com acesso concedido por meio de uma tag padrão recebem acesso a novos repositórios sem nenhuma etapa manual.
Ao visualizar a aba **Repositories** de uma equipe, quaisquer tags concedidas à equipe são exibidas como chips somente leitura no topo da lista de repositórios. Cada chip mostra o nome da tag, o número de repositórios com que ela contribui e se a tag é auto-synced. Repositórios herdados por meio de uma tag não podem ser removidos individualmente — para revogar o acesso baseado em tags, remova a tag na aba **Permissions**.
Alterar o acesso a repositórios de uma equipe para **All repositories** remove quaisquer mapeamentos baseados em tags. Um aviso é exibido antes que essa alteração entre em vigor.
Gerenciando o Acesso Baseado em Tags via API
Ao definir as permissões de uma equipe pela API, você pode incluir `tagIds` junto com `repositoryIds` para conceder à equipe acesso a repositórios por meio de tags. A equipe recebe as `repoPerms` configuradas em todos os repositórios que pertencem a cada tag listada.
Ao ler as permissões de uma equipe, a resposta inclui:
* `tagIds` — as tags cujos repositórios membros a equipe pode acessar.
* `repoAccess` — um objeto estruturado com um discriminante `mode` (`"universal"` ou `"selected"`) que torna explícito o modelo de acesso da equipe. No modo `"selected"`, ele inclui `repositoryIds` (concessões explícitas por repositório) e `tagIds` (concessões com escopo de tag) junto com as `perms` concedidas.
Alternar para **All repositories** (`universalRepoPermissions: true`) limpa tanto as concessões por repositório quanto as baseadas em tags. Por outro lado, definir `universalRepoPermissions: false` limpa as concessões universais e aplica apenas os `repositoryIds` e `tagIds` explicitamente listados.
Detalhes do Achado
Ao visualizar um achado, a ZeroPath exibe informações contextuais para ajudar sua equipe a fazer a triagem com eficácia:
* **Exploit steps** — um passo a passo de como a vulnerabilidade poderia ser explorada
* **Preconditions** — condições que o scanner não conseguiu verificar completamente e que podem reduzir a explorabilidade. Cada precondição inclui uma descrição e evidências de suporte opcionais que você pode expandir para obter mais contexto. As precondições ajudam sua equipe a avaliar o risco real destacando as suposições que precisam valer para que a vulnerabilidade seja explorável.
* **SCA vulnerability and reachability data** — para achados de dependências, detalhes do pacote e se o caminho de código vulnerável é alcançável a partir da sua aplicação
* **Runtime Validation** — quando um achado foi testado dinamicamente, um painel de Runtime Validation aparece inline na issue. Ele mostra o veredito (por exemplo, Confirmed, Disconfirmed ou Unable), um timestamp e um resumo do resultado. Você pode expandir duas seções recolhíveis para mais detalhes:
* **Validated attack path / Validation path** — para achados confirmados, passos de reprodução com entradas numeradas; para todos os achados testados, a sequência de ações do agente e os resultados observados.
* **Evidence and scope** — um resumo narrativo das evidências coletadas, além dos alvos e das funções específicas que foram testados. Se a issue não pôde ser testada dinamicamente, esta seção registra que o teste não foi possível.
Convidando Membros
Você pode convidar novos membros para sua organização em **Settings → Members**. Ao adicionar convidados, você pode atribuir a cada pessoa uma função — **Member** ou **Admin** — no momento do convite, para que tenham as permissões corretas desde o momento em que entram. Novos convidados recebem por padrão a função Member.
Você pode adicionar convidados um de cada vez ou alternar para o **bulk edit mode** para colar uma lista de endereços de e-mail separados por vírgulas ou quebras de linha. E-mails adicionados em massa recebem a função Member por padrão; volte para a visualização em lista para ajustar funções individuais antes de enviar os convites.
Se você inserir novamente um endereço de e-mail que já está na lista de convites com uma função diferente, a função é atualizada para refletir sua seleção mais recente.
Status de Membro
Os membros da organização podem estar em um dos seguintes estados:
| Status | Descrição |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Active** | O membro aceitou o convite e tem acesso completo com base na sua função. |
| **Pending** | Um convite foi enviado, mas o membro ainda não entrou. Admins com permissão de convite podem reenviar o convite usando o ícone de envio ao lado do nome do membro. Reenviar um convite preserva a função atribuída ao convidado, de modo que um Admin pendente não seja rebaixado inadvertidamente para Member. Membros pendentes também podem ser removidos para cancelar o convite em aberto. |
| **Inactive** | O membro foi desprovisionado por meio do seu provedor de identidade (SCIM). Membros inativos aparecem com um selo **Inactive** e não podem ter a função alterada nem ser removidos pelo dashboard — eles devem ser gerenciados no seu provedor de identidade. Isso evita modificações acidentais em contas desprovisionadas, ao mesmo tempo em que dá aos admins visibilidade de quem já teve acesso. |
Fluxo de Status de Issues
Os achados seguem um ciclo de vida estruturado que se alinha aos fluxos de trabalho das equipes. Você pode alterar o status de um achado diretamente na visualização de detalhes da issue — ações de status como marcar como falso positivo, risco aceito, verdadeiro positivo ou resolvido entram em vigor imediatamente, sem diálogo de confirmação, agilizando o processo de triagem.
| Status | Significado |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pending Review** | Achado novo, aguardando triagem |
| **Reviewing** | Em revisão ativa pela equipe |
| **Patching** | A correção está sendo desenvolvida |
| **Resolved** | A correção foi aplicada (manualmente ou via PR mesclado) |
| **False Positive** | Confirmado como não sendo uma vulnerabilidade real. As equipes podem opcionalmente exigir que os usuários forneçam uma justificativa ao marcar achados como falso positivo (veja a permissão **Require Context for False Positives**). |
| **Accepted Risk** | Problema conhecido aceito pela equipe |
| **Non-Exploitable** | Tecnicamente presente, mas não explorável no contexto. Quando um usuário marca uma issue como não explorável e fornece um motivo, a justificativa é preservada e exibida tanto no detalhe da issue quanto na lista de issues por meio do campo `nonExploitableReason`. |
| **Backlog** | Reconhecido, mas adiado para depois |