​
Overview

TigerGate is a Cloud-Native Application Protection Platform (CNAPP) covering code, container, cloud, Kubernetes (KSPM) and data (DSPM) security, plus pentest, endpoint, infrastructure and runtime protection. LowerPlane connects through the read-only TigerGate Compliance API. It imports TigerGate’s open findings into Vulnerabilities, where they are tracked against your remediation SLA, and records scan coverage and framework posture as evidence. Each sync reads a full snapshot of every product your key can see, so LowerPlane mirrors TigerGate’s current state. New open findings are added. Findings that TigerGate fixed, or no longer reports, are closed with their fix time.
The integration is read-only: LowerPlane never changes anything in TigerGate. The Compliance API never returns secret values, source-code snippets or pentest payloads.

​
Prerequisites

You need the Owner or Admin role in your TigerGate organization to create a Compliance API key.

​
Create a Compliance API Key

1

Open Compliance API keys

In TigerGate, go to Settings → Organization → API Keys → Compliance API and click Create key.
2

Name the key and choose an expiry

Set Name to LowerPlane and Integration to LowerPlane. Choose an expiry of 90 days, 180 days, 1 year or 2 years. LowerPlane flags the key 14 days before it expires (see Key expiry and rotation).
3

Grant products

Grant every product you want LowerPlane to monitor, with all resources and all finding types. To include TigerGate users in access reviews, also grant Users. See Key scope for what each grant unlocks.
4

Copy the key

Copy the key (tgcmp_…). TigerGate shows it only once.

​
Key scope

If a product’s framework results are refused (for example, KSPM granted only some finding types), LowerPlane still syncs that product’s findings and assets. It only skips that product’s compliance posture evidence.
LowerPlane sees only what the key can see.
  • If you narrow a product’s resources or finding types, findings that drop out of view are closed in LowerPlane as not present.
  • If you remove a product from the key, or your plan stops including it, LowerPlane skips that product and keeps its last synced findings and assets. They stay open, keep ageing against their SLA and keep their tests failing until the product is readable again.
Keep the scope stable.

​
Connect to LowerPlane

1

Find TigerGate

Go to Integrations and search for TigerGate.
2

Enter the key and region

Paste the Compliance API key and select the region your TigerGate organization is hosted in (see below).
3

Connect

Click Connect. LowerPlane verifies the key with TigerGate and starts the first sync.
4

Set the sync frequency to Hourly

Hourly is recommended. Findings then open and close in LowerPlane within an hour of changing in TigerGate.

​
Region

A key works only in the region that issued it. A key used against the wrong region is rejected as invalid. On every sync, LowerPlane asks TigerGate for your organization’s API address and uses that. It only connects to tigergate.dev hosts over HTTPS.

​
How syncing works

  • Each sync reads a full snapshot of every readable product’s open findings. It also reads the findings TigerGate fixed since the last sync, so the ones LowerPlane already tracks close with their real fix time.
  • Products whose history TigerGate is still preparing, or that the key or plan no longer covers, are skipped until they become readable. If no product is ready (for example, right after you connect), the sync fails with the reason and no findings change.
  • A sync has a time budget. In very large organizations, products that don’t fit are synced first on the next run, so products take turns.
  • If the budget cuts the fixed-findings read short, some findings are first closed as Not present at the sync time, then corrected to TigerGate’s fix time on the next run.
  • If a product can’t be read completely, LowerPlane keeps its previous data. Nothing is closed on a failed or partial read, and open findings keep ageing against their SLA.

​
What LowerPlane Imports

LowerPlane imports TigerGate findings rated critical, high, medium or low that are open or in progress. Fixed findings are not imported: LowerPlane only uses TigerGate’s fixes to close findings it already tracks.

​
Classes

Each imported finding gets exactly one class, shown in its details:
  • Vulnerability: an exploitable weakness, such as a CVE, a vulnerable dependency, a code flaw, an exposed secret or a pentest finding.
  • Misconfiguration: a posture problem in a cloud account, cluster, IaC template, container, data store or device.
  • Detection: a sign of active threat, such as malware, an indicator of compromise, a runtime incident or a threat detection.
A finding type TigerGate adds later is classed as a vulnerability if it carries CVEs, and as a misconfiguration otherwise.
Runtime incidents and other detections are tracked as SLA-bound findings in Vulnerabilities. They don’t create LowerPlane Incidents.
Each finding also keeps its asset, rule, CVEs, CVSS score (vulnerabilities with CVEs only), TigerGate status detail, SLA deadline, TigerGate’s own triage (assignee, triage status, notes and linked ticket) and a link that opens it in the TigerGate console.

​
Findings that are not tracked

Some findings are stored but not tracked. They are left out of every list, count, export and test. Asset pages and the Repositories page show a short note with how many were left out and why. A finding is tracked again from the next sync after the reason goes away. For example, unsuppress it in TigerGate, or fix the branch setting on the Repositories page.

​
Users and access reviews

If the key is granted Users, LowerPlane reads every member of your TigerGate organization on each sync. A key that grants only users (no products) is also valid. For each user it records:
  • Role (owner and admin count as admin access), status, and team memberships
  • Whether MFA is enabled, and when they last logged in
  • Their matching person in LowerPlane, found by email, and whether HR has offboarded them
Users who are suspended or deactivated in TigerGate count as disabled. TigerGate then appears in Access Reviews as a critical system with its users, and the identity tests below run against them. Users removed from TigerGate disappear on the next sync. If reading users fails, LowerPlane keeps the last synced list. To create a users-only key through the TigerGate API (as an owner or admin):
To use one key for both, list your product grants under products instead of {}.

​
Assets, coverage and posture

For every product except Issues, LowerPlane also reads the asset list and scan activity: when each asset was last scanned successfully, and whether it is still monitored. Archived and inactive assets are not counted. For Cloud Security, KSPM and DSPM, LowerPlane also records framework and control pass rates.

​
SLA Deadlines

TigerGate findings are tracked against the remediation SLA policy you set in Assets → Settings (see Remediation SLAs). Each finding’s window is chosen per severity:
  1. A vulnerability uses the vulnerability SLA for its severity.
  2. A misconfiguration or detection uses the security alert SLA for its severity. If that value is blank, it uses the vulnerability SLA.
  3. If no LowerPlane window applies, the finding uses TigerGate’s deadline, which comes from TigerGate’s SLA policy or a due date set on the finding in TigerGate.
  4. If neither exists, the finding has no deadline. It is still tracked and counted as open without SLA in the sync summary evidence, but it can’t fail an SLA test.
Each severity is independent. For example, if you set only Critical to 7 days, critical findings get 7 days and every other severity uses TigerGate’s SLA. The clock starts at the exact time LowerPlane first imports the finding. TigerGate’s own first-found date is kept on the finding but doesn’t start the clock.
Connecting TigerGate doesn’t make existing findings overdue under your policy, because the clock starts when LowerPlane first imports them. Findings that use TigerGate’s own deadline can still be overdue straight away if that deadline has already passed.

​
Assets, scope and branches

Inventory rows. Every TigerGate asset becomes an inventory row. Repositories lists only repositories synced from GitHub, GitLab or Bitbucket. Other TigerGate repositories are listed in Vulnerabilities → Findings by asset. Images, cloud accounts, clusters, data stores, web targets, servers and workstations go to Inventory. Linking. If a repository was already synced from GitHub, GitLab or Bitbucket with the same provider and name, LowerPlane links the TigerGate asset to it. The name match is not case-sensitive. No duplicate is created. Out of scope. You can mark an asset out of scope in Inventory, Repositories or Vulnerabilities → Findings by asset. A reason is required. Its findings stay visible. They no longer count in the SLA and scan-coverage tests. The tests list them as Asset out of scope. Non-production assets work the same way and show Non-production resource. An exclusion you set yourself on a test entity is never overridden by these scope rules. Cloud resources. AWS S3 buckets, EC2 instances, RDS instances and IAM users from the AWS integration are matched to findings exactly by ARN. Azure resources are matched by resource ID. A matched finding links to both the resource and its TigerGate account. It is excluded if either one is out of scope or non-production. Other resources, and GCP, use the account only. If two AWS accounts share a resource name (for example an RDS identifier), only the account synced last is matched. The other account’s finding links to its account only. Resources a sync no longer finds are marked removed and hidden. They come back unchanged if they reappear. Production branch. Only code findings on a repository’s production branch count. This is the branch you set in the Production branch (audited) field on the Repositories page, or TigerGate’s default branch if you set none. Repositories not synced from GitHub, GitLab or Bitbucket always use TigerGate’s default branch. Findings on other branches, and findings in a repository with no production branch, are not tracked (Not on production branch). A sync never overwrites a branch you set. Changes apply at once. You don’t need to wait for a sync. Scope and branch changes update findings and tests right away.

​
Automated Tests

LowerPlane creates 13 TigerGate tests: 9 tests covering vulnerability SLAs by severity, leaked secrets, misconfigurations, asset scan coverage, endpoint agent reporting, and API key health, plus 4 standard identity tests that use TigerGate users. The SLA tests are re-evaluated after every successful sync and on their daily schedule, so findings become overdue even if syncs stop. The four identity tests need the Users grant. Without it they show Not applicable. In the SLA tests, findings with no deadline and deactivated findings don’t fail. Not tracked findings, and findings on assets that are out of scope or non-production, aren’t counted. An SLA test with no findings of its class and severity passes if the last sync succeeded, and shows Not applicable otherwise. When a failing finding is fixed and disappears from TigerGate, its remediation task is closed automatically.

​
Accepting Risk and False Positives

TigerGate is the source of truth for each finding. In LowerPlane its name, description, severity, CVSS score, dates and status are read-only, and it can’t be deleted. You can take a finding out of the SLA tests in either of two ways.

Suppress in TigerGate

Suppress the finding in TigerGate. From the next sync it is not tracked in LowerPlane (Suppressed in scanner). It is tracked again once you unsuppress it in TigerGate.

Deactivate in LowerPlane

Deactivate monitoring with the reason Risk accepted or False positive, an explanation and a duration. The decision is recorded in LowerPlane and kept across syncs.
If TigerGate fixes a deactivated finding, it closes as Resolved in LowerPlane. Deactivating in LowerPlane doesn’t change anything in TigerGate.

​
Key Expiry and Rotation

The TigerGate API key is connected and not about to expire test starts failing 14 days before the key expires, and immediately if TigerGate rejects the key (expired, revoked, invalid, inactive subscription or invalid scope). A key with no expiry date passes. If TigerGate sends an expiry date that LowerPlane can’t read, the test fails so that you check the key. While the key is rejected, syncs fail and LowerPlane closes nothing. The SLA tests keep running on the data already synced. To rotate a key:
1

Create a new key

In TigerGate, create a new Compliance API key with the same products and finding types as the old one.
2

Update LowerPlane

In Integrations, edit the TigerGate integration, paste the new key and keep the same region. Click Sync Now.
3

Revoke the old key

Once the sync succeeds, revoke the old key in TigerGate.

​
Evidence Collected

​
Frameworks Supported

Detections (malware, indicators of compromise, runtime incidents and threat detections) are tracked with SLA deadlines in Vulnerabilities, but no test covers them.

​
Troubleshooting

Check that you selected the region that issued the key. A key from one region is rejected by every other region. If the region is right, create a new key and update the integration.
Create a new key in TigerGate and follow Key expiry and rotation.
The key isn’t granted that product, your TigerGate plan doesn’t include it, or TigerGate is still preparing its history. Grant the product to the key, or wait. LowerPlane checks again on every sync.
It is probably not tracked: suppressed in TigerGate, from a local scan, not on the repository’s production branch, or a secret still in progress. Asset pages show how many findings were left out and why. Informational and already-fixed findings are never imported.
KSPM framework results need the key to be granted every Kubernetes finding type. DSPM framework results need the control finding type. Findings and assets still sync without them.
Findings that were already past your SLA when TigerGate was connected, or when a policy change first gave them a deadline, are overdue straight away. Fix them in TigerGate, suppress them there, or deactivate them in LowerPlane with a reason.
The key can’t read TigerGate Endpoint, or no devices are enrolled. The test applies once Endpoint data is synced.