WASViking Docs
⌘K
Integrations

Jira

Two-way sync of findings with Jira, with bulk push, polling, and stable mapping.

The Jira integration pushes WASViking® findings into your existing Jira project, with two-way field mapping, bulk push, and polling for status updates back into WASViking.

What syncs

  • Finding → Jira issue. Subject, description, severity, CWE, Risk Score, evidence link.
  • Status → Jira status. Configurable mapping (open ↔ To Do, etc.).
  • Comments. WASViking comments are pushed; Jira comments are polled back when --two-way is enabled.
  • Assignee. If the WASViking finding has an assignee with a Jira account email, it propagates.

The integration tracks a stable mapping per finding so re-syncs do not duplicate issues.

Setup

  1. In Jira: create an API token for the user that will own the integration. Use a service account, not a personal user.
  2. In WASViking: Integrations → Jira → Connect.
  3. Provide the Jira site URL, the user email, the API token, and the target project key.
  4. Map WASViking severity to Jira priority.
  5. Map WASViking status to Jira status.
  6. Decide bulk push behavior: every new finding, every escalation, or manual only.

Field mapping (defaults)

WASViking Jira
title Summary
description + evidence link Description
severity Priority
risk_score Custom field wv_risk_score (optional)
cwe Custom field wv_cwe (optional)
assignee.email Assignee
category Labels (wv:sqli, etc.)
compliance[] Labels (wv:pci-6.5.8, etc.)

The optional custom fields are created automatically the first time the integration runs, if your Jira project permits field creation.

Bulk push

Bulk push is the right initial mode for teams importing existing WASViking findings into Jira. From the Findings page:

  1. Filter to what you want to push.
  2. Bulk actions → Push to Jira.
  3. Review the dry-run summary.
  4. Confirm.

The integration creates issues in a single batched API call where possible, and rate-limits to respect Jira's per-app quotas.

Two-way polling

When enabled, WASViking polls the linked Jira issues on a schedule (default 15 minutes) and brings back:

  • Status changes (mapped back to WASViking statuses).
  • New comments.
  • Reassignment.

Local WASViking status transitions still emit webhook events and are auditable; they are mirrored to Jira, not replaced by it.

Conflict resolution

If a finding is mutated in both systems between polls:

  • WASViking status is the source of truth for open, mitigated, false_positive, fixed.
  • Jira status is the source of truth for in-flight workflow states the team uses in Jira ("In Code Review", "Waiting on Vendor", etc.).
  • Comments are merged (both sides retained).

Quiet hours and rate limiting

Jira rate-limits aggressively per app installation. WASViking honors the rate-limit headers and queues bursts. If you push 5,000 findings, expect the bulk import to spread across the next 30 to 60 minutes.

Removing the integration

Integrations → Jira → Disconnect. The existing Jira issues remain; the WASViking link is dropped. Re-connecting later will not duplicate issues if the original wv_finding_id field is still present in Jira.