Visão Geral
As políticas de SLA permitem que sua equipe mantenha a remediação dentro de prazos mensuráveis. Você define por quantos dias uma issue aberta de cada severidade pode permanecer sem resolução; o ZeroPath então observa suas issues, notifica as pessoas certas quando uma issue ultrapassa seu limite de idade e acompanha o quão bem você está cumprindo essas metas ao longo do tempo. O recurso tem três camadas:
Abra Settings → SLA para encontrar quatro abas: Overview, Policies, SLO Dashboard
e Audit Trail.
A avaliação de SLA é executada apenas sobre issues abertas. Issues resolvidas, arquivadas
e de repositórios efêmeros ficam fora do escopo, então fechar uma issue interrompe seu
relógio de SLA.
Criando uma política de SLA
1
Abra o assistente de políticas
Vá em Settings → SLA → Policies e escolha New policy (ou parta de um
modelo para configurações comuns).
2
Defina os limites por severidade
Dê a cada severidade um prazo em dias — por exemplo, Critical = 7, High = 14,
Medium = 30. Uma issue entra em violação quando fica aberta por mais tempo que o
limite da sua severidade. (As severidades derivam da pontuação/confiança de cada
issue; INFO não é elegível para limites de SLA.)
3
Escolha o escopo
Aplique a política a todos os repositórios ou restrinja-a a repositórios
e/ou tags específicos.
4
Escolha os canais de notificação
Selecione canais do Slack e/ou webhooks para receber as notificações de
violação.
5
(Opcional) Adicione etapas de escalonamento e uma meta de SLO
Adicione etapas de escalonamento que envolvem canais adicionais em offsets de dias
posteriores e defina uma meta de conformidade de SLO para acompanhar no dashboard.
Limites por severidade
Um limite é o número máximo de dias (1–365) que uma issue aberta daquela severidade pode permanecer sem resolução antes de ser considerada em violação. O relógio de violação começa no início do ciclo de vida da issue — o momento em que ela entrou (ou reentrou) em um estado aberto — então uma issue fechada que é reaberta depois inicia um relógio novo.Escopo: repositórios e tags
Uma política se aplica a toda a organização por padrão, ou a um conjunto escolhido de repositórios e tags. O escopo por tag acompanha os repositórios atualmente em cada tag, então adicionar um repositório a uma tag o coloca automaticamente sob qualquer política com escopo naquela tag.Hierarquia de políticas
As políticas podem ser organizadas em uma hierarquia pai/filho (com até cinco níveis de profundidade). Uma política filha só pode apertar os limites da política pai — nunca afrouxá-los — de modo que uma linha de base da organização pode ser tornada mais rígida para uma equipe crítica sem permitir que nenhuma equipe fique abaixo da linha de base.Quando os limites de uma política pai mudam, as políticas filhas são recalculadas
automaticamente e quaisquer severidades recém-apertadas são preenchidas retroativamente,
mantendo a hierarquia consistente.
Modelos
Os modelos preenchem previamente uma política com limites e canais sensatos para necessidades comuns, para que você possa criar uma política em uma única etapa e ajustar a partir dela.Notificações
Uma vez que uma política existe, o ZeroPath varre suas issues abertas a cada hora e envia um resumo agrupado por(policy, severity, threshold) para os canais da
política — assim, um lote de issues Critical recém-violadas produz uma única mensagem
“N issues breached”, em vez de uma mensagem por issue.
- Slack — publica um resumo em Block Kit em cada canal configurado.
- Webhooks — entrega um evento
ISSUE_AGED_PAST_THRESHOLD(consulte Webhooks).
Etapas de escalonamento
Cada política pode definir etapas de escalonamento, cada uma com um offset em dias e seu próprio conjunto de canais do Slack e webhooks. Quando uma issue atinge a idade do offset de uma etapa, os canais daquela etapa são adicionados à notificação — permitindo ampliar o público (por exemplo, envolvendo um gerente no dia 14) quanto mais tempo uma issue permanece aberta.As etapas de escalonamento entregam para seus próprios canais independentemente da
seleção de canais base da política, então uma etapa pode introduzir um canal que a
política base não usava.
Datas de vencimento em tickets exportados
Quando um achado é exportado para o Jira ou o Linear, o ZeroPath pode marcar o ticket com o prazo de SLA do achado como sua data de vencimento, para que os engenheiros vejam o prazo de remediação diretamente no rastreador. Ative Set due date from SLA nas configurações de auto-ticketing do Jira ou do Linear (Settings → Integrations → Jira/Linear → Auto-Ticketing). Quando habilitado, todo ticket criado por essa integração — automaticamente na conclusão do scan, ou manualmente a partir de um achado — recebe uma data de vencimento igual ao prazo de SLA mais apertado em escopo da issue: a data de violação mais próxima entre todas as políticas que cobrem a issue, usando a mesma definição de violação da varredura e do SLO Dashboard.- Se nenhuma política de SLA cobre o achado, nenhuma data de vencimento é definida.
- A data de vencimento é marcada uma única vez, quando o ticket é criado; edições posteriores na política não movem a data de vencimento de um ticket existente.
- Um achado que já passou do prazo no momento da exportação recebe uma data de vencimento no passado (exibida como atrasada), porque o relógio de SLA começa quando a issue foi aberta.
Para o Jira, a data de vencimento só é aplicada quando o tipo de issue selecionado expõe um
campo Due date em sua tela de criação. Se não expuser, o ZeroPath avisa você ao salvar a
configuração e cria os tickets sem data de vencimento, em vez de falhar a exportação.
Dashboard de SLO
O SLO Dashboard transforma a atividade de SLA em uma tendência. Defina um SLO em uma política atribuindo a ela uma porcentagem-alvo de conformidade (50–100%) e uma janela de avaliação (1–730 dias); o dashboard então mostra, por política:
Esses valores vêm de snapshots de SLI — uma medição pontual que o ZeroPath registra
uma vez por dia por política (e por tag), de modo que os gráficos constroem um histórico
diário de conformidade, contagens de violação e latência de resolução.
Burn rate
O burn rate expressa a rapidez com que você está consumindo seu orçamento de erro — a folga entre 100% e a sua meta. Um burn rate acima de 1× significa que você está violando mais rápido do que a meta permite. O ZeroPath sinaliza dois níveis e, quando configurado, envia uma notificaçãoSLA_BURN_RATE_HIGH:
O burn rate é suprimido para políticas de volume muito baixo, em que uma única violação
faria a porcentagem oscilar e produziria alertas ruidosos.
Relatórios de conformidade
A partir de uma política, você pode gerar um relatório de conformidade de SLA (PDF, CSV ou JSON) para uma auditoria ou revisão com stakeholders. O relatório usa a mesma definição de violação da varredura ao vivo e do dashboard, então os números sempre coincidem. Consulte Relatórios para a geração e a exportação de relatórios.Trilha de Auditoria
A aba Audit Trail registra cada execução da varredura horária e as tentativas individuais de despacho que ela fez — qual canal, o resultado e qualquer erro — para que você possa confirmar que uma notificação foi enviada e diagnosticar um problema de entrega.Disparando automações a partir de eventos de SLA
Eventos de SLA podem disparar automações de agentes de IA. Configure um gatilho de evento de agente para o eventoISSUE_AGED_PAST_THRESHOLD ou SLA_BURN_RATE_HIGH para, por
exemplo, abrir automaticamente uma tarefa de remediação ou publicar um plano priorizado
quando um grupo de violações disparar. Gatilhos com escopo em repositórios ou tags
específicos correspondem quando qualquer repositório de um grupo de violações está no
escopo.