ServiceNow Connector

Getting started with ServiceNow connector

Updated this week


The ServiceNow connector is being used for both creating incidents (automatically or manually) and for pulling data from CMDB. For that reason, the configuration of the connector requires several parameters. The data is pulled from the following ServiceNow tables:

Username and password are used for pulling assets. Assets are taken from the following tables: cmdb_ci_computer, cmdb_ci_vm_instance.
Client Id and Client Secret used to create incidents.
Users are being pulled from the table sys_user.
Business units are being pulled from the table cmn_department.

Defining a connector

On the Connectors page, click on Add a Connector.

Click on the ServiceNow connector.

Fill in all the relevant fields:

Instance Name - Name of the hosted ServiceNow instance.
For example - if the ServiceNow instance URL is, the instance name is dev123456.

Select Authentication method - Basic Auth/OAuth 2.0

Username (Basic and OAuth 2.0) - Username which is used to log in to ServiceNow instance. Users must have admin permission when using Basic Auth, and security_admin when using OAuth 2.0.
Make sure the user name is indicative of Vulcan's platform.
In order to assign a role to the user, follow the next steps:

  1. In your ServiceNow instance, navigate to User Administration > Users, then open a user record.

  2. In the Roles-related list, click Edit.

  3. In the Collection list, select the desired roles, and then click Add.

    For "Notifier" only, the user must have 3 roles for the vulcan user (permissions):

    1. itil - To manage, create and edit tickets tickets.

    2. personalize_dictionary - To read from sys_dictionary table (Vulcan fetches labels for fields)

    3. personalize_responses - To personalize predefined responses for suggestion fields, such as the Additional Comments field (Vulcan syncs the options for the fields showed on the UI)

    The Notifier user must be assigned to a group that has permission to create/edit/view incidents, problems, and problem tasks.

  4. Click Save.

Password (Basic and OAuth 2.0) - Password of the same user which is used to login to ServiceNow instance

Client Id (OAuth 2.0 only) - Key in order to communicate with ServiceNow API

Client Secret (OAuth 2.0 only) - Key in order to communicate with ServiceNow API

Note: ServiceNow connector requires username and password even with OAuth2 (based on ServiceNow recommendations).

To create the API Client ID and Client Secret, follow the steps listed below:

  1. Browse to your ServiceNow instance and log in.

  2. Once you have logged in browse to the System OAuth section and click Application Registry and click the New button.

  3. Now click the Create an OAuth API endpoint for external clients link.

Collect Users - Will allow assigning a vulnerability to a ServiceNow user entity through Vulcan.
Users are being pulled from the table sys_user.

Collect Assets - Will collect computer assets from ServiceNow, which will be validated against the scanner's data. This will allow finding unscanned assets that are configured in ServiceNow but not in the scanner.
Assets are taken from the following tables: cmdb_ci_computer, cmdb_ci_vm_instance.

When enabling the option to collect assets you will also have the ability to choose if there are assets from specific classes which you don't want to display in Vulcan. Click on Choose CMDB_CI table values to pull the available values which you can filter out.

You can select exactly which assets you want to display in Vulcan. The available values are only the ones who are relevant to your ServiceNow account. Note that by default Vulcan's ServiceNow connector is pulling all the assets.
Click Save. 

Click on Create. 

  • You can see the connector’s progress in the Logs tab:

Manually opening a ServiceNow Incident

  • From a specific vulnerability, you can choose to Take Action, and open a ServiceNow ticket:

  • For that ticket you can choose to alter the specific ServiceNow fields as you wish (including which assets/solution to include in that ticket):

Connector pulls all categories, subcategories, and fields within your ServiceNow instance.

Manually opening a ServiceNow Problem and Problem Tasks

Another type of entity you can create via Vulcan is Problem and Problem Task.
The problem will contain the vulnerability details (similar to an incident), only for each vulnerable asset a Problem Task will be created with the asset name as a "Configuration Item" (if cannot find a Configuration Item ->  the asset name will be under the short description attribute). Problem tasks are related to their parent problem. Read more about problem life cycle management.

In order to create Problem and Problem Tasks follow the instructions: 

  • From a specific vulnerability, you can choose to Take Action.

  • Choose Problem

  • Fill all relevant fields to create the Problem

  • Scroll down in order to fill relevant fields for creating Problem Tasks

  • Click Open Ticket

Automating ServiceNow incidents

ServiceNow incidents can be opened up automatically using Vulcan.

  1. Navigate to the Automation page, click on Create new Playbook.

  2. Name your Playbook.

  3. Choose your Playbook’s trigger (Vulnerability to fix)

    • Vulnerability from the source – The connector from which we pull assets. For example Vulnerabilities from source AWS.

    • Vulnerability where – The rule by which the playbook will be attached by. For example Vulnerability where CVSS Score is greater than 7.

    • On assets where – The asset’s property you wish to be automated. For example: On assets where OS is Windows.

    • In this example, the vulnerability that will be fixed is any vulnerability with CVSS score higher than 7, which was found on assets with Windows OS, and that was discovered by AWS connector.

  4.  Choose Open ServiceNow ticket at Remediation actions.

  5. Fill the fields on the Open ServiceNow ticket:

    1. Assignee - The person that will be assigned to remediating the vulnerability.
      Note: Two assignee fields might appear in the ticket configuration in the following cases: (a) if set by code, and (b) if the ticket type is "problem" and the ticket aggregation behavior is separated by assets.

    2. Category - The incidents will be categorized as the selected category.

    3. Subcategory - The incident will be categorized as the selected subcategory.

    4. Playbooks note (optional) - Additional information to be included in the incident.

  6. Click Save.

  7. That’s it. From now on, a ticket will be generated automatically by the parameters you’ve set. You can create as many playbooks as you want and define different rules to assign tickets to other teams.

Getting ServiceNow Data

This is an example of a vulnerability that has a ServiceNow incident attached to it. You can see it in the right pane under: ‘Open Tickets’.

The activity log for the vulnerability will show any changes in the ticket:

  • To locate assets coming from ServiceNow, you can filter ‘ServiceNow’ as a source in the appropriate filter:

Ticket lifecycle management

ServiceNow ticket states can be changed by Vulcan when vulnerabilities are fixed or no longer needed. See more on this in the ServiceNow ticket lifecycle.


Note: If "reduced" permissions are required for the ServiceNow user profile, the profile will need access to all the tables below.

The ServiceNow connector based on the following default API calls:


Read and write permission:


*Note- any other custom fields or tables that are selected from the ServiceNow connector configuration in Vulcan, will also need to be manually added as a permission to the ServiceNow user.


Did this answer your question?