This guide walks you through configuring ServiceNow Application Vulnerability Response (AVR).
ServiceNow supports two authentication methods for this integration, shown as tabs below:
- OAuth 2.0 (recommended): A Client Credentials application that authenticates as a linked Application User. Access is governed by that user's roles, with no REST API Access Policies required.
- Basic Credentials: A dedicated service account with username and password.
After authentication is set up, configure the integration using the values from your chosen path.
The integration uses ServiceNow REST APIs against AVR tables. Query operations use the Table API. Importing findings posts JSON rows to the Import Set REST API (/api/now/import/u_avr_staging/insertMultiple). Access is governed by the integration user's (or Application User's) roles and ACLs; no REST API Access Policies are required.
Read permissions listed below are required to support all queries.
When importing findings you must also complete the ServiceNow Application Vulnerability Findings Import Setup Guide.
| Purpose | Access needed |
|---|---|
| List discovered applications | AVR read (Table API) |
| List findings for an application | AVR read (Table API) |
| List application vulnerability findings | AVR read (Table API) |
| Get a single finding | AVR read (Table API) |
| Import findings into AVR (discovered applications, vulnerability entries, AVITs) | Import and AVR write roles; import pipeline |
Before starting, confirm:
| Requirement | Notes |
|---|---|
| Application Vulnerability Response (AVR) | Installed and active; tables exist: sn_vul_app_vulnerable_item, sn_vul_app_release, sn_vul_app_vul_entry |
| Integration user | Dedicated user with Table API access for queries; additional import/transform and AVR write access for importing findings |
| Normalized Severity Map | Required when importing findings — source must match the u_source value sent by the integration (default Synqly AVR) |
Suggested roles (adjust to your org):
import_transformerorimport_admin(for importing findings)- AVR administrator or equivalent read/write roles on
sn_vul_app_*tables - CMDB read access for optional business application lookup during import
Log in to ServiceNow as an admin.
Create a service account (recommended). A dedicated account avoids broken integrations if an employee account is deactivated. Go to All > Organization > Users, select New, set User ID (required), select Internal Integration User, and complete any other required fields. Open the new user, go to the Roles tab, select Edit..., and assign roles that grant read access to Application Vulnerability Response records through the ServiceNow Table API.
When importing findings, also assign import/transform and AVR write roles as described under Instance prerequisites.
OAuth 2.0 requests are authenticated as the Application User linked to the OAuth Application Registry. ServiceNow evaluates the request against that user's roles and ACLs directly—you do not create REST API Access Policies for this path.
ServiceNow authenticates this method with an OAuth 2.0 Client Credentials application. With this approach, you authenticate an application (using a Client ID and Client Secret) that then acts as a linked OAuth application user. The application credentials themselves carry no permissions—that user's roles and ACLs determine what the integration can read or write, exactly as they would for Basic Credentials, but without embedding a username or password in the integration settings.
In the ServiceNow filter navigator, type sys_properties.list and press Enter. Search for glide.oauth.inbound.client.credential.grant_type.enabled and confirm its value is true.
On instances running the Zurich release or later (where the Machine Identity Console is available), this property is typically already set to true. If you can see the Machine Identity Console in the navigation, you can skip this step and return here only if token requests fail with access_denied.
If the property does not exist, click New and create it: set Name to glide.oauth.inbound.client.credential.grant_type.enabled, Type to true | false, and Value to true.
Navigate to All > Machine Identity Console, then click the Inbound integrations tab. Click New Integration.
In the "Select your application connection type" dialog, select OAuth - Client credentials grant ("Used for machine-to-machine access to the application without the user's context").
Fill in the Details section:
| Field | Value |
|---|---|
| Name | A descriptive name, for example Synqly Integration. |
| Provider name | A label for the external system connecting to ServiceNow, for example Synqly. |
| OAuth application user | The service account that should own tokens issued from this integration. This is the key field—the token acts as this user, and that user's roles and ACLs govern all API access. |
| Client ID | Auto-generated. |
| Client secret | Auto-generated. |
In the Auth scope section, leave Auth scope empty and uncheck the Allow access only to APIs in selected scope checkbox.
Unchecking "Allow access only to APIs in selected scope" is required. When unchecked, access is governed entirely by the OAuth application user's roles and ACLs. If the checkbox is left checked or an Auth scope is added, different ServiceNow REST surfaces require different scopes and will conflict with each other, producing 403: Missing required api access scope or 403: Access to unscoped api is not allowed errors.
Click Save.
The Client secret is masked after saving. Copy it before clicking Save, or use the copy icon next to the field on the saved record. Store both the Client ID and Client secret securely; you will need them when configuring the integration in Synqly.
The OAuth application user is set directly on the creation form in step 2. Verify that the correct service account is selected before saving.
Do not create a REST API Access Policy that enforces a specific Auth Scope (for example on table_api_access) for OAuth traffic. Combining this integration with REST API Access Policies produces 403 scope-conflict errors identical to those described in step 2 above.
Client ID + Client Secret
| (authenticate)
v
OAuth Integration Record
| (acts as)
v
OAuth Application User
| (governed by)
v
Roles and ACLs
|
v
What the token can read or writeThe OAuth credentials themselves grant no permissions on their own—they are a key to the door. What is behind that door is defined entirely by the OAuth application user's roles, assigned in the next step below.
Open the Application User you set in step 2 and, in the Roles tab, select Edit.... Assign:
- Read access to AVR tables for query operations
import_transformerorimport_admin(or equivalent) for Import Set transform access- AVR write roles on
sn_vul_app_release,sn_vul_app_vul_entry, andsn_vul_app_vulnerable_itemfor importing findings - CMDB read access if you rely on business application lookup during import
Then complete ServiceNow Application Vulnerability Findings Import Setup Guide. Ensure the Application User can write to the staging table, transform maps, and AVR tables your administrators protect with ACLs.
URL
The root URL of your ServiceNow instance, for example https://<tenant>.service-now.com/.
Client ID
The Client ID from the Application Registry record.
Client Secret
The Client Secret from the Application Registry record.
Token URL (optional)
Only set this if your identity provider issues tokens from a URL other than your ServiceNow instance's default OAuth token endpoint.
OAuth Scopes (optional)
Leave empty for a Broadly scoped Application Registry (recommended). Only set this if the registry is Securely scoped with explicit Auth Scopes—see the warning in step 2 above.
To enable importing findings, complete the ServiceNow Application Vulnerability Findings Import Setup Guide after you finish this guide. That guide configures the u_avr_staging Import Set table, REST Insert Multiple mapping, transform map, onBefore script, normalized severity map, and troubleshooting for AVR finding imports.