Tanium Comply

Vulnerability Management

Overview

The Tanium Comply connector integrates with the Tanium platform to synchronize the vulnerability findings produced by Tanium Comply. Findings are retrieved by running a configured Tanium saved question through the result-data API and are mapped into two Brinqa models: a per-endpoint Vulnerability finding, and a de-duplicated CVE-level Vulnerability Definition. Both models are projections of the same saved-question result set — the connector runs the (fully paginated) query once per sync transaction, caches the rows locally, and serves every model for that transaction from the cache.

Data retrieved from Tanium Comply

Connector Object	Required	Maps to Data Model
Vulnerability	Yes	Vulnerability
Vulnerability Definition	Yes	Vulnerability Definition

note

For detailed steps on how to view the data retrieved from Tanium Comply in the Brinqa Platform, see How to view your data.

Setup

Connection settings

When setting up a data integration, select Tanium Comply from the Connector dropdown and provide the following:

Setting	Required	Default	Description
Server URL	No	—	Tanium server URL
Api token	No	—	Tanium api token
Domain	No	—	(Optional) Tanium account domain name
Page size	No	—	Maximum number of records to get per API request
Parallel requests	No	min(4, available processors)	Maximum number of parallel API requests
Maximum retries	No	5	The maximum number of retry attempts before giving up a request. Must be at least 1.
SSL / TLS	No	—	Skip certificate verification
Saved question ID	Yes	—	The numeric ID of the saved question that returns vulnerability results. The connector requests results by ID (not by name), so enter the ID rather than the question's name. For example, the saved question Name: [Brinqa] Get All Vulnerabilities Question: Get Computer ID and IP Address and Computer Name and Comply - JovalCM Vulnerabilities[1ddc92f8] and Comply - Vulnerability Discovery Dates from all machines might have ID 1010 — enter 1010 here.

Authentication

The connector uses API token authentication, identical to the rest of the Tanium bundle. The configured API token is sent in the session request header on every call, along with an Accept: application/json header. No interactive login or token-exchange round trip is performed at sync time.

Endpoint

Method	URL
GET	https://<servername>/api/v2/result_data/saved_question/<savedQuestion>

Request Headers

Header	Value
session	<api-token>
Accept	application/json

Request Body

Requests are GET calls with no body. Results are paged with query parameters:

Query Parameter	Description
row_count	Page size (from the pageSize configuration property)
row_start	Zero-based starting row, incremented by row_count per page

Sample Response

The saved-question result is returned as nested result_sets, each containing columns and rows. Each row's data holds one cell array per column, aligned by index:

{
  "data": {
    "result_sets": [
      {
        "columns": [
          { "name": "Computer ID" },
          { "name": "Computer Name" },
          { "name": "IP Address" },
          { "name": "CVE" },
          { "name": "Title" },
          { "name": "Scan Type" },
          { "name": "CVSS Score" },
          { "name": "CVSS Vector" },
          { "name": "Severity" },
          { "name": "OVAL Definition" },
          { "name": "Result" },
          { "name": "First Found Date" },
          { "name": "Last Seen Date" }
        ],
        "rows": [
          {
            "id": "1",
            "cid": "987654321",
            "data": [
              [ { "text": "987654321" } ],
              [ { "text": "WIN-HOST-01" } ],
              [ { "text": "10.1.2.3" } ],
              [ { "text": "CVE-2024-0001" } ],
              [ { "text": "Sample vulnerability" } ],
              [ { "text": "Vulnerability" } ],
              [ { "text": "7.5" } ],
              [ { "text": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N" } ],
              [ { "text": "High" } ],
              [ { "text": "oval:com.example:def:1" } ],
              [ { "text": "fail" } ],
              [ { "text": "20240101" } ],
              [ { "text": "20240601" } ]
            ]
          }
        ]
      }
    ]
  }
}

Response Fields

Field	Description
data.result_sets[]	Result sets returned by the saved question
result_sets[].columns[].name	Column names used to align row cell values
result_sets[].rows[]	One row per endpoint; cid is the computer id, data holds per-column cell arrays
data[][].text	Cell text value (a column may carry multiple cells, aligned by index with the CVE list)

Usage

The configured API token is attached to the session header of all requests. The result-data API is offset-paginated, so independent pages are fetched concurrently (see parallelismLevel); reading stops once a short or empty page is returned. Each row may yield multiple findings — one per CVE in the row's CVE column — with the other multi-valued columns (Title, CVSS Score, CVSS Vector, Severity, OVAL Definition, Result, dates) aligned to the CVE list by index. When a column has fewer values than the CVE list, the last available value is reused.

---

Sync Behavior

Each sync is a full sync. The connector does not maintain a sync token and does not apply an incremental filter; the since value is accepted but not used. Every run re-runs the configured Tanium saved question and enumerates all returned records. The configured saved question governs the scope of the result set.

---

How to obtain Tanium Comply credentials

Obtain the required credentials (savedQuestion) from your Tanium Comply administrator or the Tanium Comply admin console, then enter them in the connection settings above.

Data & mappings

Attribute mappings

Expand the sections below to view the mappings between the source and the Brinqa data model attributes:

Vulnerability

Source Field Name	SDM Attribute
Computed MD5 of row cid + Computer ID + CVE + Title	UID
Computer ID column	TARGETS
Computer ID column	COMPUTER_ID
Computer Name column	COMPUTER_NAME
Constant ACTIVE	PROVIDER_STATUS
CVE column	TYPE
CVE column	CVE_IDS
First Found Date column	FIRST_FOUND
IP Address column (all values)	IP_ADDRESSES
IP Address column (values containing :)	IPv6_ADDRESS
IP Address column (values without :)	IPv4_ADDRESS
Last Seen Date column	LAST_FOUND
Normalized PROVIDER_STATUS	SOURCE_STATUS
OVAL Definition column	OVAL_DEFINITION
Result column	RESULTS
Scan Type column	SCAN_TYPE
Sync timestamp	LAST_CAPTURED
Title column	TITLE

note

Comply's "Open Vulnerabilities" question carries no raw status column, so PROVIDER_STATUS is published as a constant ACTIVE default rather than a value Tanium reported. SOURCE_STATUS is derived from it through the shared normalizer, so the pair stays consistent if a future saved question does expose a status column.

Vulnerability Definition

Source Field Name	SDM Attribute
CVE column	UID
CVE column	CVE_IDS
CVE column	CVE_RECORDS
CVSS Score column	SOURCE_SEVERITY_SCORE
CVSS Vector column	CVSS metrics
CVSS Vector column (parsed)	CVSS_V3_BASE_SCORE
Derived from normalized SEVERITY	SEVERITY_SCORE
Normalized from SOURCE_SEVERITY	SEVERITY
Severity column, else unknown	SOURCE_SEVERITY
Sync timestamp	LAST_CAPTURED
Title column	DESCRIPTION
Title column	SUMMARY
Title column, falling back to CVE	NAME

note

The stock Comply "Open Vulnerabilities" saved question selects CVSS Score and CVSS Vector but no Severity column, so most definitions will carry SOURCE_SEVERITY/SEVERITY of unknown and a SEVERITY_SCORE of 0.0. To get real severities, add the Severity column to the saved question. SOURCE_SEVERITY_SCORE still carries the raw CVSS base score in either case.

Operations & API

Operations & API

Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).

Vulnerability

Operation options

This object does not support any operation options.

Delta sync

Not supported. The connector performs a full sync of Vulnerability on every run and applies no incremental date filter.

API

• Type: REST endpoint · Endpoint: GET /api/v2/result_data/saved_question/{savedQuestion} — runs the configured Tanium saved question and returns its result rows

Vulnerability Definition

Operation options

This object does not support any operation options.

Delta sync

Not supported. The connector performs a full sync of Vulnerability Definition on every run and applies no incremental date filter.

API

• Type: REST endpoint · Endpoint: GET /api/v2/result_data/saved_question/{savedQuestion} — the same saved question as the Vulnerability model

Changelog

Changelog

The Tanium Comply connector has undergone the following changes:

Version	Description	Migration Steps
3.1.0	New Features - Tanium Comply vulnerability ingestion is now available. Comply CVE data is published at two levels: a per-endpoint Vulnerability finding and a deduplicated, CVE-level Vulnerability Definition (name, summary, CVSS score, CVSS metrics, and derived severity) shared across every endpoint that reports the same CVE. Findings link to their definition by CVE. - Both models are mapped onto the standard Brinqa graph model schema. Findings use shared model attributes (CVE, targets, results, severity score, and first/last-found timestamps), providing consistency with other vulnerability connectors. Findings also carry the Comply Scan Type reported for the endpoint result. - Two new configuration properties tune how saved-question results are retrieved. Parallel requests sets how many result pages are fetched at the same time, defaulting to the number of available processors capped at four. Maximum retries sets how many times a failed request is attempted before the sync gives up, defaulting to five. Improvements - Result pages are now fetched concurrently rather than one after another, shortening sync time on large result sets. Use the new Parallel requests property to raise or lower the load placed on the Tanium server. - Failed result requests are now retried with an increasing delay between attempts instead of ending the sync at the first error, so a transient Tanium API error or timeout no longer costs a full sync. The attempt limit is set by the new Maximum retries property. - Each result response is now logged with its status, content type, and size, and a response that is not JSON is raised as a warning rather than passing unremarked — making a misdirected saved question or an intercepting proxy visible in the connector log. - When an error response cannot be read as JSON — for example an HTML login or gateway page returned by a proxy — the log now includes the start of the actual response body instead of only a parse-failure message, so the underlying cause can be identified without reproducing the request. - The Saved question ID help text now states that the numeric question ID is required rather than the question's name, and shows a worked example.	• Vulnerability: For customers upgrading from the 1.x Tanium bundle, both the record identity and several attribute data types have changed. The unique identifier and the attribute identifiers are different — for example, the previous SYS_ID and COMPUTER_ID are replaced by the standard graph-model attributes — so existing records will no longer match and would otherwise accumulate as stale duplicates. In addition, firstFound and lastFound are now timestamps rather than numeric epoch values, and ipv4Address and ipv6Address are now multi-valued rather than single-valued. Because an upgrade adds new attributes but does not change the type of attributes that already exist, carrying the existing Vulnerability model forward prevents any finding from being saved. Action: stop the connector schedule, drop and recreate the Tanium Comply Vulnerability data model for the source instance — archiving or deleting the records alone is not sufficient, the model itself must be recreated — upgrade to 3.1.0, then run a full sync to repopulate. The new CVE-level Vulnerability Definition model has no prior records and is populated by that same sync. Note that firstFound and lastFound are now interpreted in UTC; on a deployment set to another time zone the repopulated dates shift by that offset. Customers already on the 3.x line need no action — the Comply models were not published on 3.x before this release, so there are no existing Tanium Vulnerability records to migrate.
3.0.6	No changes in this release.	N/A
3.0.5	Improvements Dependency Upgrades - Upgraded internal framework and model libraries to the latest stable versions for improved reliability, security patches, and alignment with the rest of the connector platform.	N/A
3.0.4	No changes in this release.	N/A
3.0.3	No changes in this release.	N/A
3.0.2	Improvements - Standardized the attribute schema for Vulnerability findings so field names are consistent and stable across syncs, with explicit data types (for example, CVSS score as a number and first/last-found as timestamps).	• Vulnerability: The attribute identifiers used for Vulnerability findings have changed (for example, Sys ID is now SYS_ID), while their display labels are unchanged. Any mappings or rules that reference the previous attribute identifiers must be updated, and a full sync should be run after upgrading so records are repopulated with the new attribute names. The record identifier itself is unchanged, so existing records will continue to match.
3.0.1	No changes in this release.	N/A
3.0.0	Overview The Tanium Vulnerability connector integrates with Tanium Comply to synchronize vulnerability findings discovered on endpoints, including CVE identifiers, CVSS scoring, affected hosts, and first/last-found dates. Category: Vulnerability Management Models	N/A