TigerGate has no native connector for these platforms yet. Each one can take data from a tool it doesn’t integrate with, through its own custom-integration feature. In most cases that means a small sync job you schedule: it reads from the Compliance API and writes to the platform’s API. Sprinto’s Ingestion module is the exception: it can call the Compliance API itself.
Before you start:
- Create one Compliance API key per platform, and set its Integration to match. Grant only the products and resources the platform needs for your audit scope.
- Run
GET /whoami with the key and note which products are readable.
- Read Pagination and sync. Most platforms replace their whole copy on each sync, which suits a full snapshot.
The platform-side details below are taken from each vendor’s public documentation, linked in each section. Vendors change their APIs and plans; check the linked pages before you build.
Vanta
Drata
Secureframe
Sprinto
Custom
Vanta takes data from other tools through a private integration that you create in Vanta’s Developer Console (guide). Your sync job pushes resources to Vanta:
- Endpoint:
PUT https://api.vanta.com/v1/resources/{resource_type}
- Auth: OAuth client credentials from the Developer Console. Access tokens last one hour.
- Sync model: each
PUT replaces everything the integration previously sent for that resource type. Anything you leave out is deleted in Vanta (reference).
- Limits: 20 requests per minute per access token, up to 10,000 resources and 10 MB per request (overview).
Because each PUT replaces the whole set, sync from a full snapshot. Read every page of GET /findings for each product, then send the complete set in one PUT per resource type. Don’t send an incremental pull to Vanta; the findings it doesn’t contain would be deleted.Vulnerabilities in Vanta hang off a vulnerable component, so send assets first:TigerGate asset.type | Vanta vulnerable_component targetType |
|---|
code_repository | CODE_REPOSITORY |
container_image | CONTAINER_REPOSITORY_IMAGE |
server, workstation | HOST |
Then map findings to Vanta’s vulnerability resource types:| TigerGate findings | Vanta resource type |
|---|
code_security sca, container_security vulnerability, infra and endpoint vulnerability | package_vulnerability_connectors |
code_security sast and iac | static_analysis_code_vulnerability_connectors |
pentest web | api_endpoint_vulnerability_connectors |
- Use the TigerGate finding
id as the Vanta unique id, and link each vulnerability to its component through asset.id.
- Vanta severities are numbers from 0 to 10. Send
severity_score.
- Vanta calculates remediation due dates itself, from when Vanta first sees a vulnerability and your SLA settings in Vanta (how Vanta calculates SLAs). Configure matching SLAs in Vanta, or keep TigerGate’s
sla.due_at in a custom_resource for reference.
- Cloud and Kubernetes misconfigurations have no Vanta vulnerability type. Send them as
custom_resource and build a Vanta custom test on them (custom tests).
Vanta’s full resource schemas are in its OpenAPI specification. Drata takes data from other tools through Custom Connections and Tests (overview), available on Drata’s Advanced and Enterprise plans. You define the record schema yourself, so a TigerGate finding can be sent as is.Create a custom connection and resource in Drata
Create a resource for findings, and one for assets if you want inventory. Use a TigerGate finding from GET /findings as the sample record when Drata asks for the schema.
Create a Drata API key
Give it the Custom Connections Data create, update and delete scopes (API setup). Schedule the sync
Push records to https://public-api.drata.com/public/v2/custom-connections/{connectionId}/resources/{resourceId}/records (recipe). Write tests
Build Drata tests on the fields you care about, for example “no finding has severity critical and sla.breached true”.
Drata supports both TigerGate sync modes:
- Daily: open a Drata upload session, push a full TigerGate snapshot, then complete the session. Completing a session replaces the whole dataset, so findings that have left TigerGate disappear from Drata.
- Hourly: upsert the findings from an incremental pull directly. Records are matched on
id.
Drata accepts up to 5 MB of JSON per request and 500 requests per minute from one IP address (public API). A TigerGate page of 200 findings is usually well under that; lower limit if a request is rejected for size. Secureframe takes data from other tools through Custom Integrations (guide), on Secureframe’s Complete plan. Data can be uploaded as CSV or pushed through the API:
- Endpoint:
POST https://api.secureframe.com/custom_connections/{id}/data. UK accounts use api-uk.secureframe.com. Secureframe marks this endpoint as early access (API reference).
- Auth: an
Authorization: <API key> <secret> header.
- Body: the schema, the vendor, and a
resource_data array of records. Requests are processed asynchronously and return 202.
- Limits: 500 requests per minute per IP address.
Secureframe custom integrations map records to cloud resources, personnel accounts, devices, training records or a Custom category that appears in the Asset Inventory. There is no vulnerability category, so:
- send TigerGate assets from
GET /assets, with last_scanned_at from GET /scan-activity, to show scan coverage;
- send findings as Custom records if your auditor wants them in Secureframe, keyed on the TigerGate
id.
Sync from a daily full snapshot. Sprinto’s Ingestion module can call the Compliance API directly, with no sync job of your own (overview).Create an ingestion plan
In Sprinto, create an ingestion plan with an HTTP request step (guide). Point it at TigerGate
Use bearer-token authentication with the Compliance API key, and a URL such as https://api.tigergate.dev/api/v1/compliance/findings?product=code_security&limit=1000. Use your region’s API host.
Define the entity type
Define fields from the finding shape, for example id, title, severity, status, first_detected_at and sla.due_at.
Pick a schedule
Sprinto runs plans every 4, 8 or 12 hours, or daily.
A single request returns at most 1,000 findings. If a product has more, either configure the plan to follow page.next_cursor, or narrow each request with filters such as severity=critical,high or status=open.Sprinto also offers a push API for custom integrations, but its documented entity models are users, devices and user access (models), not findings. Sprinto’s GraphQL developer API is for reading data out of Sprinto, not for sending data in. Any tool that can make HTTPS requests can use the API directly. A minimal sync loop in Python:import os, time, requests
BASE = "https://api.tigergate.dev/api/v1/compliance" # your region's API host
s = requests.Session()
s.headers["Authorization"] = f"Bearer {os.environ['TIGERGATE_COMPLIANCE_KEY']}"
def get(path, **params):
while True:
r = s.get(f"{BASE}{path}", params=params, timeout=60)
if r.status_code in (429, 503):
time.sleep(int(r.headers.get("Retry-After", "5")))
continue
r.raise_for_status()
return r.json()
def pull(product, updated_since=None):
params = {"product": product, "limit": 1000}
if updated_since:
params["updated_since"] = updated_since
while True:
page = get("/findings", **params)
for finding in page["items"]:
upsert(finding) # store by finding["id"]
if not page["page"]["has_more"]:
return page["meta"]["next_updated_since"]
params["cursor"] = page["page"]["next_cursor"]
for p in get("/whoami")["products"]:
if p["readable"]:
next_since = pull(p["product"], updated_since=load_checkpoint(p["product"]))
save_checkpoint(p["product"], next_since)
upsert, load_checkpoint and save_checkpoint stand for your own storage. A checkpoint of None runs a full snapshot. Run a full snapshot daily as well; see Recommended sync.
Thoropass
Thoropass does not publish a customer API or custom-integration feature for importing findings or assets (integrations). To give a Thoropass auditor TigerGate evidence, export it with the Compliance API, for example findings with sla dates or GET /scan-activity, and attach the export to the evidence request in Thoropass.
Choosing what to send
| Evidence an auditor asks for | Endpoint |
|---|
| Vulnerabilities are tracked and fixed within SLA | GET /findings with sla, and GET /sla-policy for the policy itself |
| All assets are scanned regularly | GET /assets and GET /scan-activity |
| Cloud, Kubernetes or data controls pass | GET /frameworks and GET /controls |
| Exceptions are documented | Findings with status: suppressed and their status_detail |