ServiceNow

Sincronização bidirecional de achados com incidentes do ServiceNow, com mapeamento de estados, filtros de sincronização e polling.

A integração com o ServiceNow cria os achados da WASViking^® como registros na tabela Incident da sua instância, com mapeamento de estado bidirecional, filtros de sincronização por integração e polling para trazer as atualizações de status de volta à WASViking.

O que é sincronizado

• Achado → Incidente. Short description, uma descrição composta (severidade, categoria, CWE, OWASP, pontuação de risco, evidências) e qualquer campo de incidente que você mapear, incluindo campos personalizados u_*.
• Status → Estado do incidente. Mapeamento configurável (open ↔ New, resolved ↔ Resolved etc.). Os estados são lidos ao vivo da sua instância, então estados personalizados aparecem automaticamente. Quando um achado leva um incidente para Resolved ou Closed, os campos obrigatórios Resolution code e Close notes são preenchidos automaticamente com os códigos de resolução que a sua instância realmente define.
• Estado do incidente → Status do achado. As mudanças de estado feitas pela sua equipe no ServiceNow são lidas de volta por polling e mapeadas para os status da WASViking por categoria de estado (new, in progress, done).
• Avisos de fechamento e reabertura. Sempre que a WASViking fecha ou reabre um achado, o incidente recebe uma work note dizendo quem fez, quando e por quê: o scan que parou de detectá-lo, o operador e o motivo que ele escolheu, a regra de supressão ou o scan que o detectou de novo. Quando a WASViking resolve o incidente, o campo Close notes traz o mesmo motivo. Um estado que a sua equipe altera no ServiceNow nunca é ecoado de volta.

A integração mantém um vínculo estável por achado (número do incidente e sys_id), então ressincronizações não duplicam incidentes.

Requisitos

• Uma instância em service-now.com ou servicenowservices.com (Government Community Cloud). URLs personalizadas (vanity URLs) não são aceitas.
• Um usuário de integração dedicado com o papel itil, autenticado com Basic auth. Use uma conta de serviço, não um usuário pessoal.
• Defina o fuso horário do usuário de integração como GMT/UTC. O polling de entrada filtra pelo horário de atualização, e o ServiceNow interpreta esses timestamps no fuso horário do usuário que faz a consulta.

Configuração

1. No ServiceNow: crie o usuário de integração com o papel itil e o fuso horário GMT/UTC.
2. Na WASViking: Settings → Integrations → ServiceNow.
3. Informe a URL da instância, o nome de usuário e a senha e, em seguida, clique em Test connection. O teste roda com os valores digitados no formulário, para que você os confirme antes de qualquer coisa ser armazenada. Quando ele responder connection ok, selecione Save credentials: a senha é armazenada criptografada e os campos e estados de incidente são lidos da sua instância.
4. Mapeie os campos da WASViking para os campos do incidente. O Auto-detect preenche os mais comuns. A severidade mapeada para Urgency, Impact ou Severity é convertida automaticamente para os valores de escolha 1/2/3. Priority não pode ser mapeado: o ServiceNow o calcula a partir de impact e urgency.
5. Mapeie os status da WASViking para os estados do incidente, na saída e na entrada. O Auto-detect propõe o modelo padrão do ServiceNow (open → New, in progress → In Progress, resolved → Resolved). Reopened é opcional: em branco, um achado reaberto segue a transição de open, de modo que um incidente fechado por um scan volta quando o achado é detectado de novo.
6. Escolha o que encaminhar com os filtros de sincronização (veja abaixo).
7. Ative Enable bidirectional sync e clique em Save mapping.

Mapeamento de campos (padrões)

Ao contrário do Jira, o ServiceNow não rejeita campos desconhecidos; ele os ignora silenciosamente. Mapeie para campos que existem no seu formulário de incidente ou crie antes os campos personalizados u_* e execute o Auto-detect de novo.

Filtros de sincronização

Cada integração decide o que encaminha:

• Grupos de achados. Os achados gerais e os achados de componentes SCA / SBOM têm controles independentes.
• Minimum severity (severidade mínima). Encaminha apenas achados em um limiar ou acima dele.
• Categorias. Escolha quais categorias de achados criam incidentes.
• Repositórios. A única regra que adiciona. Um repositório que você adiciona tem todos os seus achados transformados em incidentes, independentemente do que digam a categoria, a severidade ou o controle de SCA. Tudo o que está fora da lista continua respondendo às regras acima. Uma lista vazia não adiciona nada.
• Forward only findings from these repositories (encaminhar apenas achados destes repositórios). Ativado, a lista deixa de adicionar e passa a ser o escopo inteiro: só esses repositórios chegam ao ServiceNow. Desativado é o padrão.

Todos os filtros são aplicados em conjunto: grupo, severidade, categoria e repositório precisam todos concordar antes de um incidente ser criado.

A página mostra uma prévia do impacto em tempo real antes de você salvar. O envio manual de um único achado sempre ignora os filtros; esse clique é uma decisão explícita do operador.

Backfill

O backfill cria um incidente para cada achado existente que ainda não tem um. Achados já vinculados são pulados, e os envios são espaçados (2 segundos entre eles, com teto de 30 minutos) para respeitar os limites de taxa da instância. Execute-o uma vez depois da primeira configuração, quando os filtros de sincronização já estiverem do jeito que você quer.

Polling

O ServiceNow não tem webhooks de saída nativos, então a WASViking consulta os incidentes vinculados a cada 5 minutos e traz de volta as mudanças de estado, mapeadas para os status da WASViking pelo seu mapeamento de entrada. Os incidentes criados pela WASViking recebem o marcador de correlation display WASViking, o que mantém o polling restrito aos registros da própria integração em vez de varrer a tabela Incident inteira.

Uma janela curta anti-loop impede que um envio de saída e o seu próprio eco fiquem jogando o status de um lado para o outro entre os dois sistemas.

Só um estado que realmente mudou é lido de volta. Um incidente que continua no estado que a WASViking viu ou definiu por último não traz novidade, mesmo quando uma atualização de campo ou uma work note o atualizou, de modo que um achado que um scan acabou de reabrir continua reaberto até a sua equipe mover o incidente.

Incidentes excluídos

Se alguém exclui um incidente vinculado diretamente no ServiceNow, o próximo envio registra um erro em Sync history e para de tentar. Com Recreate the incident automatically (recriar o incidente automaticamente) ativado, a integração detecta o registro ausente, recria o incidente com um novo número e retoma o fluxo normal.

Limitação de taxa

O throttling do ServiceNow é definido por instância, por regras de limite de taxa. A WASViking respeita o header Retry-After nas respostas 429 e recua mantendo a fila intacta. Backfills grandes se espaçam por conta própria.

Como remover a integração

Desative Enable bidirectional sync. Os incidentes existentes permanecem; a WASViking simplesmente para de enviar e de consultar. Reativar depois não duplica incidentes, porque os vínculos dos achados são mantidos.

Prefere construir a sua própria sincronização? Assine os eventos de achados diretamente via Webhooks.