6.3 ServiceNow Integration
6.3.1 Architecture
The ServiceNow integration is an outbound destination for the notification engine. When a rule matches — a certificate approaching expiry, a policy failure, a newly discovered weak key — the engine raises or updates a record in ServiceNow and tracks its state, so that a cryptographic finding becomes a tracked work item in the tool the customer already uses.
The integration is bidirectional in one specific and important sense: the engine polls the state of records it has created, so that a ticket closed in ServiceNow is reflected in the platform. Without that, the platform would keep reminding about work that has been done.
6.3.2 Prerequisites and Account Setup
A ServiceNow instance and permission to create an integration user.
An integration user with read and write access to the target table, and no more. Grant the minimum role rather than an administrative one.
Authentication credentials. OAuth2 is the recommended method and is the default. Basic authentication may be restricted or disabled by instance policy, and may be on a deprecation schedule, so an integration configured for Basic authentication alone will eventually stop working.
Network access outbound from the platform to the instance over HTTPS.
Two verification points deserve particular attention, because both fail quietly:
Verify access by making the call, not by inspecting instance properties. A property value tells you what a setting is, not whether your credentials will be accepted.
A successful HTTP response does not prove read access. ServiceNow access control filters read results silently, so a user without access to the table receives a success response with an empty result set. Assert on the row count, not the status code. The consequence of getting this wrong is that the integration never finds an existing ticket and therefore creates a duplicate on every evaluation — which presents as a duplicate-ticket defect rather than a permissions problem, and is diagnosed in the wrong place.
6.3.3 Configuration
Add a ServiceNow integration in the platform, supplying the instance URL, authentication method and credentials.
Configure the target table and the field mapping from finding attributes to record fields.
Configure which notification rules route to this destination.
Configure the state mapping — which record states the platform should treat as open, resolved and closed.
Save and verify with a test notification. Confirm both directions: a record is created, and a state change made in ServiceNow is reflected back in the platform.
6.3.4 Operations
A scheduler runs the rule evaluation, the reminder and escalation sweep, and the inbound state synchronisation, each on its own configured interval.
Records created by the platform carry a reference back to the finding, which is what allows state synchronisation and duplicate suppression to work.
Duplicate suppression relies on finding an existing open record before creating a new one. This is the code path that the silent-read-filtering problem in 6.3.2 breaks, so it is worth checking first when duplicates appear.
Escalation and reminders fire on elapsed time rather than on a new match, which is why they run as a separate sweep from the evaluator.
6.3.5 Troubleshooting
-
Authentication failures: expired OAuth2 credentials, or Basic authentication disabled by instance policy.
-
Duplicate tickets: the integration user cannot read the table, so the existing-record lookup returns empty. Verify by row count.
Tickets created but never closed in the platform — inbound state synchronisation is not running, or the state mapping does not match the instance workflow states.
-
No tickets created: check that a rule matched at all before checking the integration. Rule evaluation and delivery are separate stages and fail separately.
-
Field mapping errors: a mandatory field on the target table with no mapping. The record creation fails and the finding stays open with no ticket.