Bidirectional ticket sync

What it is

Two-way sync between Umbra findings and your ticketing system. A status change in Jira or GitHub flows back into Umbra; a status change in Umbra transitions the linked ticket. Operator- tunable status maps for both directions so any custom workflow fits.

What it produces

• Inbound webhook → Umbra
  • Jira Cloud webhook: when an issue’s status changes, the linked finding’s status updates. Authenticated by URL token (mirrors Sentry/PagerDuty/Linear).
  • GitHub Issues webhook: when an issue is closed / reopened / labeled, the linked finding’s status updates. Authenticated by HMAC-SHA256 (GitHub’s native scheme).
• Reverse sync (Umbra → external)
  • Close a finding in Umbra → the linked Jira issue transitions to the configured “done” state.
  • Close a finding in Umbra → the linked GitHub issue closes.
• Status-map editor UI: operator-tunable per channel. Inbound maps the external state name → one of the Umbra lifecycle states. Reverse maps the Umbra state → the external transition name (Jira) or state (GitHub open / closed).
• Sensible defaults: every new channel starts with a working map covering the standard Jira workflow (To Do, In Progress, Done, Won’t Do) and the two GitHub states.

What to use it for

• Stop the manual “close the finding too” step after the engineering team fixes a ticket.
• Run your remediation program from Jira / GitHub if that’s where the engineering team lives. Findings stay in sync.
• Custom workflows (multi-stage QA, label-based GitHub workflows) by editing the map instead of writing code.

Why it matters

One-way “create ticket from finding” is table stakes. The slow part of a security program is the close-out: keeping the two systems aligned without manual reconciliation. Two-way sync removes that friction so the operator can run the remediation program from whichever surface their team prefers, knowing both sides stay coherent.

Why it’s valuable

• URL-token auth for Jira; HMAC for GitHub. Each integration uses the auth model the platform actually supports, not a lowest-common-denominator hack.
• Defaults work out of the box for ~80% of installs. The editor is there for the 20% that need a label-based or multi-stage workflow.
• Empty map = “use defaults”. Clearing the table doesn’t break sync; it falls back to the shipped defaults on receive.
• Status maps round-trip cleanly through the audit log so a change is attributable.

How to use it

1. Admin → Notifications → Add channel → Jira or GitHub Issues. Fill in the host + token + project (Jira) or owner+repo+PAT (GitHub).
2. Save. An inbound webhook URL (and HMAC secret for GitHub) appears on the edit modal. Paste it into the external system’s webhook config.
3. Edit the four status maps (Jira inbound, Jira reverse, GH inbound, GH reverse) if your workflow differs from the defaults. Each has a one-click Reset to defaults and a Show defaults disclosure.
4. From any finding, Create ticket to bind a ticket to the finding. From that point, status flows both ways.