TigerGate can push scan results, quality-gate failures, critical findings, and compliance and runtime events to the tools your team already uses. Notification channels are configured per organization, and delivery is retried automatically on failure.
Configure them under Integrations → Notifications & Destinations. The page has four tabs: Notification Channels, Event Destinations, Ticket Rules and Issue Tracker.
Notification channels
On the Notification Channels tab, choose Add Channel, pick a type, give it a name, and enter its configuration. Each configured channel has Edit, Test, and remove actions.
| Channel | Configuration |
|---|
| Slack | Incoming webhook URL, plus an optional bot token |
| Microsoft Teams | Incoming webhook URL |
| Email | Recipient list, plus optional SMTP host / port / username / password (leave the SMTP fields blank to use the platform default server) |
| PagerDuty | API key, plus an optional Events API v2 routing key (used for critical incident paging) |
| Custom Webhook | Endpoint URL, plus an optional signing secret |
If you set a signing secret on a Custom Webhook, TigerGate adds an X-TigerGate-Signature header to each request so you can confirm the payload came from TigerGate.
Issue tracker
The Issue Tracker tab connects a ticketing system so your team can create tickets directly from security findings.
| Provider | Configuration |
|---|
| Jira | Connect to Jira authorizes the TigerGate app on your Atlassian site (OAuth), then you choose the site, project and default issue type |
| GitHub Issues | Personal access token (or the connected GitHub App installation), repository, default issue type |
| Linear | API key, team ID, optional default issue type |
| ServiceNow | Instance URL, an integration user or an OAuth client, the table, and optional assignment group, category and severity mapping |
Secrets are write-only. They are stored encrypted and never shown again; leave a secret field blank on save to keep the stored value. Only owners and admins can change the configuration. Test connection checks the saved configuration against the tracker.
A finding’s Create Ticket action files the ticket and links it to the finding. For Jira and ServiceNow, the finding’s panel also shows the ticket’s live status, assignee and priority. That is read-only in both directions: closing the ticket does not close the finding.
ServiceNow
ServiceNow tickets are records created through the Table API on your instance. The default table is incident.
| Setting | What it does |
|---|
| Instance URL | https://<instance>.service-now.com. HTTPS only. Enter just the instance name and .service-now.com is added for you. The host must resolve to a public address. |
| Authentication | Integration user (basic auth with a username and password) or OAuth client credentials (the client ID and secret of an Application Registry entry that allows the client credentials grant). TigerGate fetches a fresh OAuth token for each operation and never stores it. |
| Table | The table tickets are filed in: incident, or another task table such as sn_si_incident for Security Incident Response. The user or OAuth client must be able to read and create records in it. On incident, the itil role covers this. |
| Assignment group | Optional. A group name, which TigerGate looks up in sys_user_group when it files a ticket, or the group’s sys_id. |
| Category | Optional. The category’s stored value, for example security, not its display label. |
| Severity mapping | The impact and urgency each finding severity is filed with. ServiceNow derives the priority from the two. |
The default severity mapping follows ServiceNow’s standard priority matrix:
| Finding severity | Impact | Urgency | Resulting priority |
|---|
| Critical | 1 - High | 1 - High | 1 - Critical |
| High | 1 - High | 2 - Medium | 2 - High |
| Medium | 2 - Medium | 2 - Medium | 3 - Moderate |
| Low | 3 - Low | 2 - Medium | 4 - Low |
| Info | 3 - Low | 3 - Low | 5 - Planning |
Test connection reads one record from the table (GET /api/now/table/incident?sysparm_limit=1) and confirms that the assignment group exists. Each ticket gets a short description (the finding title, up to 160 characters), a description with the finding’s details (and a link back to the finding when it is filed from the console), and a correlation_id that identifies the finding. The record’s number (for example INC0010023) and its link appear on the finding.
TigerGate makes HTTPS calls only to the instance URL you configured, and never follows redirects.
Event destinations and ticket rules
The Event Destinations tab streams Data Security (DSPM) and Runtime Security events to a SIEM, XDR, SSE or workflow tool: a signed webhook, Splunk HEC, Microsoft Sentinel, syslog or CEF over TLS, or a notification channel. The Ticket Rules tab opens a ticket in the connected tracker for every new or reopened Data Security Finding that matches a rule. Both are described in Data Security integrations.
Events
Once at least one channel is configured, TigerGate delivers alerts for:
| Event | When |
|---|
| Scan results | A scan finishes |
| Quality-gate failures | A scan trips a configured quality gate |
| Critical findings | A new critical finding is detected |
| Compliance report | A scheduled compliance report is generated |
| Compliance violation | A control moves into a failing / violation state |
| Control status change | A control’s pass/fail status changes |
| Agent status | A runtime agent goes online or offline |
Users can independently opt in or out of email and Slack delivery for compliance reports, violations, control status changes, and agent status.
Slack and Teams messages are formatted (Slack uses Block Kit sections) and color-coded by severity. Email uses HTML templates. Webhook deliveries POST a JSON payload describing the event.
Delivery and retries
Failed deliveries are retried automatically up to three times with exponential backoff — starting at roughly one second, doubling each attempt, and capped at 30 seconds, with jitter. A background sweep also re-attempts recently failed sends.
Test a channel
Every configured channel has a Test button that sends a connection test to the destination, so you can confirm the webhook is reachable, the credentials are valid, or the email passes your filters before real alerts start flowing.