Ticketing

A finding needs an owner, and your tracker already assigns owners. Foxborne opens the issue with the case link inside it, so the discussion happens in the tracker while the evidence stays behind your identity provider.

The Ticketing group on the Destinations tab of Integrations holds the trackers. The console describes it as "Issues that hold the case link, so work is tracked where the team already tracks it."

Choose a tracker#

Jira Cloud and ServiceNow sit outside the enclave, so they show Needs a network path out. They take L0 unless your program authorizes them for CUI.

Jira Data Center authenticates with a personal access token sent as a bearer token. It is the one tracker with status sync back.

Atlassian stopped selling Data Center to new customers on 30 March 2026, and existing customers can buy until 30 March 2028. End of life is 28 March 2029, when the products turn read-only.

Jira Cloud (Atlassian Government Cloud) uses OAuth 2.0 (3LO). Atlassian Government Cloud reached FedRAMP Moderate in March 2025. On 23 September 2026 Atlassian moved its IL5 submission to July 2028 and its FedRAMP High submission to January 2029.

ServiceNow (GCC, NSC) authenticates with OAuth 2.0 or a web-service-only integration user. Event Management takes events from a user with the evt_mgmt_integration role, and message_key deduplicates them.

GitLab self-managed opens issues with a project access token, or posts to the project's alert HTTP endpoint with its key as a bearer token. GitLab offers that endpoint in Free, Premium and Ultimate, on self-managed and Dedicated.

What Foxborne sends#

At L0, the default, an issue carries the rule, the severity, the vehicle alias, the UTC time and the case link. The link opens the case only for people who can sign in to your deployment. No ticket carries L2: evidence moves only through Export, with approval.

In the example dataset, Jira Data Center received this issue for INC-0142. It answered 201 Created, REL-418 (id 48213).

{
  "fields": {
    "project": {
      "key": "REL"
    },
    "issuetype": {
      "name": "Task"
    },
    "summary": "INC-0142: R4 Memory pressure, Critical",
    "description": "Foxborne case INC-0142. Highest alert R4 Memory pressure, Critical, UAS-04 at 14:32:01.204 UTC on 24 Sep 2026.\nCase: https://foxborne.hfr.internal/app/incidents/INC-0142",
    "labels": [
      "foxborne"
    ]
  }
}

The ledger records its idempotency key as the case, case:INC-0142. When the incident's status changes, Foxborne comments on the same issue, for example "Foxborne case INC-0142 is now In review." with the case link. Jira Data Center's Sync back reads "Issue status flows back to the case activity".

Where tickets come from#

In the example dataset, R3's route and A1 share one issue per case: REL-423 holds INC-0143. A3 deduplicates per device and closes its ticket after 10 clean sorties. Automations describes each automation in full.

Before you start#

• An admin is available to turn on egress. Admins confirm with a hardware security key.
• The deployment can reach the tracker. Jira Cloud and ServiceNow need a network path out.
• The credential sits in your secret store: a personal access token, an OAuth client, an integration user or a project access token.
• You know the project or table the issues go to.

Connect a tracker#

1. 01

   Open the destination

   Go to Integrations. On the Destinations tab, select the tracker in the Ticketing panel, then Set up in its drawer.

2. 02

   Fill in the settings

   The example dataset's Jira Data Center destination uses these values:

   Host allowlist

   jira.hfr.internal:443

   Protocol

   REST API v2, POST /rest/api/2/issue

   Project and issue type

   Project REL, issue type Task

   Credential reference

   secretsmanager:foxborne/int/jira-pat

   Data class

   L0

3. 03

   Send a test

   Select Send test. For Jira, the test is an authentication check with no body: GET /rest/api/2/myself on Jira Data Center, or /rest/api/3/myself on Jira Cloud. A good token answers 200 OK, authenticated.

4. 04

   Save and turn on egress

   Select Save, then the switch in the Egress column and Turn on egress. The audit log records Configured integration and Enabled egress, for example L0 to jira.hfr.internal:443.

5. 05

   Route alert rules to it

   Go to Alerts, select Edit on R3 and tick the tracker's route under Delivers to. A1 and A3 use the tracker once it is on.

Check the result#

On the Delivery ledger tab, the issue appears as, for example, Created REL-418 for INC-0142. A status comment appears as Comment on REL-418, INC-0142 in review. The drawer's About row links the incident, the run, the alert firing and the automation run.

On the incident, the Activity tab shows that A1 "opened REL-418 in Jira Data Center".

Troubleshoot#

The test fails with an authentication error. Jira Data Center takes the personal access token as a bearer token. Check the secret the Credential reference points to.

Status changes never come back to Foxborne. Only Jira Data Center syncs status back. Jira Cloud, ServiceNow and GitLab receive issues in one direction.

The test to Jira Cloud or ServiceNow answers No route. Egress is denied at the VPC, so your network team has to open a path to the host first.

ServiceNow refuses events. The user posting to Event Management needs the evt_mgmt_integration role.

No issue opened after a finding. A1 opens one only when a finding is High, and R3's route needs the tracker's egress on. Check the firing's Delivered section on Recent firings.

Next#

• Automations covers A1, A3 and A4, which write to your tracker.
• Alerts routes R3 and sets the severities that decide when A1 opens an issue.
• Egress, data classes and the delivery ledger explains what L0 and L1 carry.