ServiceNow

Two-way sync of findings with ServiceNow incidents, with state mapping, sync filters, and polling.

The ServiceNow integration creates WASViking^® findings as records on the Incident table of your instance, with two-way state mapping, per-integration sync filters, and polling for status updates back into WASViking.

What syncs

• Finding → Incident. Short description, a composed description (severity, category, CWE, OWASP, risk score, evidence), and any incident field you map, including custom u_* fields.
• Status → Incident state. Configurable mapping (open ↔ New, resolved ↔ Resolved, etc.). States are read live from your instance, so custom states appear automatically. When a finding moves an incident to Resolved or Closed, the mandatory Resolution code and Close notes are filled in automatically using the resolution codes your instance actually defines.
• Incident state → Finding status. State changes made by your team in ServiceNow are polled back and mapped to WASViking statuses by state category (new, in progress, done).
• Reopen notices. When a scan detects a resolved finding again, the incident receives a work note with the scan reference.

The integration tracks a stable link per finding (incident number and sys_id), so re-syncs do not duplicate incidents.

Requirements

• An instance on service-now.com or servicenowservices.com (Government Community Cloud). Custom vanity URLs are not accepted.
• A dedicated integration user with the itil role, authenticated with Basic auth. Use a service account, not a personal user.
• Set the integration user's timezone to GMT/UTC. Inbound polling filters by update time and ServiceNow interprets those timestamps in the querying user's timezone.

Setup

1. In ServiceNow: create the integration user with the itil role and GMT/UTC timezone.
2. In WASViking: Settings → Integrations → ServiceNow.
3. Provide the instance URL, the username, and the password, then Save credentials and Test connection.
4. Map WASViking fields to incident fields. Auto-detect fills the common ones. Severity mapped to Urgency, Impact, or Severity is converted to the 1/2/3 choice values automatically. Priority cannot be mapped: ServiceNow computes it from impact and urgency.
5. Map WASViking statuses to incident states, outbound and inbound. Auto-detect proposes the vanilla model (open → New, in progress → In Progress, resolved → Resolved).
6. Choose what to forward with the sync filters (see below).
7. Turn on Enable bidirectional sync and Save mapping.

Field mapping (defaults)

Unlike Jira, ServiceNow does not reject unknown fields; it silently ignores them. Map to fields that exist on your incident form, or create u_* custom fields first and re-run Auto-detect.

Sync filters

Each integration decides what it forwards:

• Buckets. General findings and SCA / SBOM component findings have independent toggles.
• Minimum severity. Only forward findings at or above a threshold.
• Categories. Choose which finding categories create incidents.

The page previews the impact live before you save. Manual push of a single finding always bypasses the filters; that click is an explicit operator decision.

Backfill

Backfill creates an incident for every existing finding that does not have one yet. Already-linked findings are skipped, and pushes are spread out (2 seconds apart, capped at 30 minutes) to respect instance rate limits. Run it once after the first setup, after the sync filters are configured the way you want.

Polling

ServiceNow has no native outbound webhooks, so WASViking polls the linked incidents every 5 minutes and brings back state changes, mapped to WASViking statuses through your inbound mapping. Incidents created by WASViking are stamped with the correlation display marker WASViking, which keeps the poll scoped to the integration's own records instead of scanning the whole Incident table.

A short anti-loop window prevents an outbound push and its own echo from ping-ponging the status between the two systems.

Deleted incidents

If someone deletes a linked incident directly in ServiceNow, the next push logs an error in Sync history and stops trying. With Recreate the incident automatically turned on, the integration detects the missing record, recreates the incident under a new number, and resumes the normal flow.

Rate limiting

ServiceNow throttling is defined per instance by rate limit rules. WASViking honors the Retry-After header on 429 responses and backs off with the queue intact. Large backfills spread out on their own.

Removing the integration

Turn off Enable bidirectional sync. The existing incidents remain; WASViking simply stops pushing and polling. Re-enabling later will not duplicate incidents, because the finding links are kept.

Prefer building your own sync? Subscribe to finding events directly via Webhooks.