Ticketing tools

An alert is only useful if someone fixes it, and the people who fix things often work in another tool: Jira or GitLab for developers, GLPI or ServiceNow for the IT team. TechWatchAlert opens the ticket in that tool, with everything needed to act, then brings its status back into the case: no more double entry.

Tools are set up in the project settings, Integrations page, Ticketing tools section (project administrators). Tickets are part of case management (Pro plans and above).

Supported tools

Tool	Where the ticket is created	Status sync
Jira Cloud and Data Center	The chosen Jira project (issue type and labels configurable)	Signed webhook, and re-reads
GitLab (gitlab.com or your instance)	The chosen project	Signed webhook, and re-reads
GitHub and GitHub Enterprise	The chosen repository	Signed webhook, and re-reads
GLPI 9.5 to 11	Assistance › Tickets	Re-reads
ServiceNow	Incidents, or vulnerable items of the Vulnerability Response module	Signed business rule, and re-reads
ConnectWise, Autotask, HaloPSA (partner space)	The client’s company	Re-reads

Several tools per project

A project can have up to five tools: for example Jira for developers and GLPI for IT. One of them is the default tool: it is used by the Open a ticket button of the alert page when the project has only one, and by workflows that do not pick one.

• On the alert page, when the project has several tools, the button becomes a menu: Open in IT GLPI, Open in Developers’ Jira…
• The Create a ticket workflow tile has a Ticketing tool setting: the default tool, or the chosen one. A “CVE exploited on a workstation” workflow can open in GLPI, and a “repository dependency” workflow in GitHub.
• There is still only one ticket per CVE and per project, whatever the tool: two tickets for the same flaw in two tools would be two truths contradicting each other in the case.

Adding a tool

1. Project settings › Integrations › Ticketing tools › Add a tool.
2. Pick the tool and, if you wish, a display name (“IT GLPI”).
3. Fill in the connection (address, target, credentials): see below for each tool. The Create this account in… walkthrough, folded under the form, lists the rights to grant.
4. Set the ticket created (entity, category, group, type…) and the status sync.
5. Test and save: the connection test checks, step by step, the settings, the tool’s answer, the account and access to the target, without creating anything in the tool. Nothing is saved if the test fails; the failing step gives the cause and the setting to fix.

Secrets (tokens, passwords, OAuth secrets) are encrypted and never shown again: a saved secret reads “Saved”, with Replace. Changing the tool’s address, the tool or the authentication mode requires entering the secrets again: a secret never follows to another destination.

GLPI

Two ways to connect:

• REST API (GLPI 9.5 to 11): like the GLPI inventory connector. In GLPI, Setup › General › API, enable the REST API and login with a token; create an API client (application token) if your instance requires it; on a dedicated account, generate the API token in its preferences.
• High-level API (GLPI 11): in Setup › OAuth, create a client allowed to use the “password” grant and the “api” scope, then a service account. Enter the client, its secret, the account and its password.

The account’s profile must be able to create tickets, followups and solutions in the chosen entity.

The ticket is created in Assistance › Tickets, with, if you set them: the entity, the ITIL category, the requester, the assigned group (numeric IDs, visible in the address of their GLPI page) and the type (incident or request).

ServiceNow

• Authentication: an integration account (user without web interface access, itil role), or an OAuth client (System OAuth › Application Registry, endpoint for external clients with the “client credentials” grant and an associated user holding the itil role).
• Create in: Incidents, or Vulnerability Response if the instance has this module (the connection test says so). A vulnerable item is linked to the CVE record of your instance; if the CVE is not there yet, opening fails with a clear message.
• Assignment group and caller: name or identifier (sys_id). Category, subcategory and the resolution code used on closure (“Solution provided” by default) are optional.

Jira

• Jira Cloud: https://…atlassian.net address, project key (SEC), email of a dedicated account and API token (id.atlassian.com › Security › API tokens).
• Jira Data Center: instance address, project key, empty email and personal access token.
• The account must be able to create, comment on and transition issues in the project.

GitLab and GitHub

• GitLab: project path (group/project) and project access token, api scope, at least the Reporter role (Developer to close issues).
• GitHub: repository (organisation/repo) and fine-grained token restricted to the repository, “Issues: read and write” permission. GitHub Enterprise: its API address (https://…/api/v3).

Ticket content and priority

Each ticket carries the title “[Sécurité] CVE… · product — severity”, the severity and CVSS, EPSS, exploitation (KEV, EUVD, CERT-FR, public exploit), the component, the fixed versions, the description, a to-do list and a link to the alert in TechWatchAlert.

For GLPI and ServiceNow, urgency, impact and priority follow the case decision (BOD 26-04 / SSVC tier, see Handling an alert):

Case decision	GLPI: urgency / priority	ServiceNow: urgency
Fix within 3 days, with forensic triage	Very high / Major	1 – High
Fix within 3 days	Very high / Very high	1 – High
Fix within 14 days	High / High	2 – Medium
Fix within 60 days	Medium / Medium	2 – Medium
Deferred	Low / Low	3 – Low

Impact is high when the attacker gains full control, medium when the component is exposed to the Internet, low otherwise. ServiceNow then computes the priority with its own matrix.

Status sync into the case

The ticket status comes back into TechWatchAlert, reduced to four states: open, in progress, resolved, rejected (“Won’t fix”, “not planned”, cancelled, risk accepted…). It arrives through a signed webhook as soon as the tool sends it (Jira, GitHub, GitLab, ServiceNow), and through regular re-reads otherwise (GLPI, PSA tools), or as a safety net if a webhook gets lost. The tool’s rate limits are respected: the re-read waits and resumes later.

Each change adds a line to the case history, and:

• Ticket resolved: the open case moves to “Resolved”, as if a member had set it. If a machine in the fleet still carries the vulnerability, it stays awaiting verification by the inventory; it only becomes “Resolved, verified” when the inventory sees it, and goes back to “Remediating” if nothing changes. A closed ticket never counts as verification.
• Ticket rejected: a comment, and the page suggests declaring an exception (Mitigated, Risk accepted or Not applicable). The case is not closed: not fixing is a decision that must be documented.
• Open, in progress, reopened: a comment only.

The alert page shows, under Fix, the ticket, its status in the tool, when it changed there and the last read, with Read now (Analyst and above).

The other way round, when a case becomes “Resolved, verified”, TechWatchAlert comments on the ticket once. With the Close the ticket once the fix is verified option (off by default), it also closes it: transition to “Done” in Jira, issue closed in GitHub and GitLab, solution added in GLPI (the requester approves the closure), incident resolved in ServiceNow with the configured resolution code. A ticket covering several CVEs (remediation action ticket) waits until all of them are verified. Vulnerability Response items are never closed from here: the module closes them on its own detection.

Webhooks

In the tool’s page, Create the address and secret gives the address to call and the signing secret. The secret is shown only once; Renew the secret makes the old one unusable, Turn off disables the address. Any call that is unsigned, wrongly signed, or about another project or repository than the tool’s is ignored.

Jira

1. Jira › System settings › Webhooks › Create a webhook (Jira administrator).
2. URL: the address given by TechWatchAlert. Secret: the signing secret.
3. Events: “Issue” › updated (and created). Suggested JQL filter: project = SEC.
4. Save. Jira signs each call (X-Hub-Signature header).

GitHub

1. Repository › Settings › Webhooks › Add webhook.
2. Payload URL: the address given by TechWatchAlert; Content type: application/json; Secret: the signing secret.
3. Let me select individual events › Issues only.
4. Add webhook. GitHub signs each call (X-Hub-Signature-256 header).

GitLab

1. Project › Settings › Webhooks › Add new webhook.
2. URL: the address given by TechWatchAlert; Secret token: the signing secret.
3. Trigger: Issues events only. Keep SSL verification enabled.
4. Save. GitLab sends the token in the X-Gitlab-Token header.

ServiceNow

ServiceNow has no ready-made webhook: a business rule sends the status. To be done by a ServiceNow administrator:

1. System Definition › Business Rules › New. Table: Incident (or Vulnerable Item for Vulnerability Response). Advanced checked.
2. When: async, on Update. Condition (incidents): State changes AND Correlation display is TechWatchAlert (incidents opened by TechWatchAlert carry this value).
3. In the Advanced tab, paste the script below and replace the address and secret.
4. Save, then move a test incident forward: the tool’s page shows “Last call received”.

(function executeRule(current, previous) {
    // Address and secret given by TechWatchAlert (tool page).
    var ADRESSE = 'https://…/webhooks/tickets/…';
    var SECRET = 'paste-the-secret-here';
    var champ = function (nom) {
        return { value: current.getValue(nom), display_value: current.getDisplayValue(nom) };
    };
    var corps = JSON.stringify({
        table: current.getTableName(),
        sys_id: current.getUniqueValue(),
        number: current.getValue('number'),
        state: champ('state'),
        substate: champ('substate'),
        close_code: champ('close_code'),
        sys_updated_on: current.getValue('sys_updated_on')
    });
    // HMAC-SHA256 of the body with the secret (key passed in base64).
    var signature = new GlideCertificateEncryption().generateMac(
        GlideStringUtil.base64Encode(SECRET), 'HmacSHA256', corps);
    var requete = new sn_ws.RESTMessageV2();
    requete.setEndpoint(ADRESSE);
    requete.setHttpMethod('post');
    requete.setRequestHeader('Content-Type', 'application/json');
    requete.setRequestHeader('X-TWA-Signature', 'sha256=' + signature);
    requete.setRequestBody(corps);
    requete.executeAsync();
})(current, previous);

Caution

Keep the secret out of tables everyone can read: preferably in an encrypted system property (password2 type), read with gs.getProperty. Without this business rule, incidents are still re-read regularly: the webhook speeds up the sync, it is not required.

Who can do what

Action	Project role
See the tools, an alert’s ticket and its status	All members
Open a ticket, re-read its status	Analyst and above
Add, edit, test, remove a tool; create or turn off the webhook	Admin and Owner

Removing a tool does not delete tickets already opened: they stay linked to the alerts, but their status no longer comes back.