Wiz Integration

Overview

This guide connects Wiz to Britive so that Wiz findings are cross-referenced against your Britive applications and profiles. Britive generates the credentials; Wiz sends the events.

What you’ll accomplish:

Create a named Wiz integration in Britive and capture its token, ingest URL, and action template
Configure an outbound webhook in Wiz using those three values
Confirm findings arrive and resolve against your Britive profiles

Before You Begin

A Britive tenant, with an identity holding the securityadmin.security.manage permission
A Wiz account with permission to create webhooks or automation actions
At least one cloud application already onboarded in Britive (AWS, Azure, GCP, OCI)

Onboarding an application is what gives Britive its catalog of cloud roles. Without it, findings still arrive — they just all report as Unresolved with no application, because there’s nothing to match against. See the Cloud Providers guides.

Create the Integration in Britive

A tenant can hold multiple CSPM integrations, including several Wiz integrations — one per Wiz tenant, per business unit, or per environment. Each gets its own token and its own ingest URL, and findings are always scoped to exactly one integration.

Using the Britive Console

Open CSPM Integration

Navigate to System Admin → CSPM Integration.

If no integrations exist yet, select New Integration. Otherwise select Manage on an existing one, or New Integration to add another.

Add a Wiz integration

Find Wiz in the list of available integrations and click the + icon in the Action column.

Name the integration

Field	Value
Name	A unique, descriptive name (for example, `wiz-production`)
Description	Optional context — which Wiz tenant or business unit this covers

Names must be unique across all CSPM integrations on the tenant, not just Wiz ones.

Click Add.

Copy the three values

Britive immediately shows a dialog with everything Wiz needs:

Value	What it’s for
Token	The shared secret Wiz sends on every request
Ingest URL	The endpoint Wiz POSTs to
Action Template	The payload body Wiz must render

Copy all three now, then click Ok.

The token is shown once. Britive stores only its SHA-256 hash and cannot display it again. If you lose it, use Rotate Token to generate a replacement — but note that rotating immediately invalidates the old token.

Using the API

List the available CSPM apps

curl -s -X GET "https://$BRITIVE_TENANT/api/cspm/apps" \
  -H "Authorization: TOKEN $BRITIVE_API_TOKEN"

[
  {
    "name": "wiz",
    "description": "Wiz Cloud Security Platform"
  }
]

Create the integration

curl -s -X POST "https://$BRITIVE_TENANT/api/cspm/token" \
  -H "Authorization: TOKEN $BRITIVE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "app": "WIZ",
    "name": "wiz-production",
    "description": "Wiz tenant for production cloud accounts"
  }'

Returns 201 Created:

{
  "app": "wiz",
  "name": "wiz-production",
  "description": "Wiz tenant for production cloud accounts",
  "token": "6f1c9b2e-8d4a-4f77-9c31-b0e5a7d4e912",
  "ingestUrl": "https://acme.britive-app.com/wiz-ingest/cspm-3a91f0c8-52b7-4d16-9f4a-77c0de11ab34",
  "createdOn": "2026-08-07T16:22:41.913Z",
  "actionTemplate": "{ \"trigger\": { ... } }"
}

Capture the token

token appears in this response and nowhere else. Store it in your secret manager before moving on.

Anywhere the API takes an integration identifier, you can pass either the integration’s name or its generated id (cspm-<uuid>). The examples below use the name.

Understand the Three Values

Before configuring Wiz, it’s worth knowing what each value actually does.

Ingest URL

https://<your-tenant>.britive-app.com/wiz-ingest/cspm-<uuid>

The trailing cspm-<uuid> is the integration’s id. It’s what tells Britive which integration a given event belongs to — which is why every integration has a distinct URL. The URL is derived from the id, not the token, so rotating the token leaves the URL unchanged.

Token

A randomly generated UUID, sent by Wiz in the Authorization header. Britive stores only SHA-256(token) and compares hashes on every request using a constant-time comparison.

Britive rejects the request unless all of the following agree: the token hashes to the stored value, the tenant in the request host matches the tenant that owns the integration, and the integration id in the URL path is the one the token actually authenticates. A token from one integration cannot be used to post to another integration’s URL.

Action Template

A Mustache template that tells Wiz what JSON to send. Britive’s parser expects exactly this shape — four objects, trigger, issue, resource, and control:

{
  "trigger": {
    "source": "{{triggerSource}}",
    "type": "{{triggerType}}",
    "ruleId": "{{ruleId}}",
    "ruleName": "{{ruleName}}",
    "updatedFields": "{{#changedFields}} {{name}} field was changed from {{previousValue}} to {{newValue}}, {{/changedFields}}",
    "changedBy": "{{changedBy}}"
  },
  "issue": {
    "id": "{{issue.id}}",
    "status": "{{issue.status}}",
    "severity": "{{issue.severity}}",
    "created": "{{issue.createdAt}}",
    "projects": "{{#issue.projects}}{{name}}, {{/issue.projects}}"
  },
  "resource": {
    "id": "{{issue.entitySnapshot.providerId}}",
    "name": "{{issue.entitySnapshot.name}}",
    "type": "{{issue.entitySnapshot.nativeType}}",
    "cloudPlatform": "{{issue.entitySnapshot.cloudPlatform}}",
    "subscriptionId": "{{issue.entitySnapshot.subscriptionExternalId}}",
    "subscriptionName": "{{issue.entitySnapshot.subscriptionName}}",
    "region": "{{issue.entitySnapshot.region}}",
    "status": "{{issue.entitySnapshot.status}}",
    "cloudProviderURL": "{{issue.entitySnapshot.cloudProviderURL}}"
  },
  "control": {
    "id": "{{issue.control.id}}",
    "name": "{{issue.control.name}}",
    "description": "{{issue.control.descriptionPlainText}}",
    "severity": "{{issue.control.severity}}",
    "risks": {{issue.control.risks}}{{^issue.control.risks}}[]{{/issue.control.risks}}
  }
}

Paste the template Britive gives you rather than the one printed here, and don’t edit the field names. Britive parses these keys by name — renaming or dropping one silently drops that data from your findings. Three fields are load-bearing for correlation:

resource.id — the cloud provider’s native role identifier, used to match against Britive’s catalog
resource.type — must render as role for the finding to appear in the report
resource.subscriptionId — used to resolve the Britive environment

Configure the Webhook in Wiz

Create a webhook action

In Wiz, create a new outbound webhook action (under Wiz’s integrations or automation actions, depending on your Wiz version).

Set the endpoint

Setting	Value
Method	`POST`
URL	The Ingest URL from Britive
Content-Type	`application/json`

Add the token

Add an Authorization header whose value is the Britive token, verbatim:

Authorization: 6f1c9b2e-8d4a-4f77-9c31-b0e5a7d4e912

No Bearer or TOKEN prefix. Britive hashes the entire header value and compares it to the stored hash, so any prefix causes a 403.

Set the body

Paste the Action Template from Britive as the webhook’s body template.

Test the connection

Use Wiz’s Test action on the webhook. A correctly configured webhook returns 204 No Content.

Attach it to a rule

Bind the webhook action to the Wiz automation rule(s) that should feed Britive — typically the rules covering IAM and identity controls, since role findings are what Britive correlates.

Verify

Confirm Wiz got a 204

The test in the previous step is the fastest signal that the URL, token, and tenant all line up. A 403 means authentication failed; a 404 means the URL path is wrong. See Troubleshooting.

Open the Findings report

In Britive, go to System Admin → CSPM Integration → Manage on your integration → the Findings tab.

Allow a short delay after Wiz sends an event — ingestion is asynchronous, so findings appear after the correlation step completes, not the instant Wiz gets its 204.

Confirm findings resolved

You should see rows with a Source Role and a Severity. Check that at least some rows show a populated Application and Profile with Status Resolved.

If every row is Unresolved with an empty Application, the roles Wiz is reporting aren’t in any onboarded Britive application — see Troubleshooting.

Verify via the API

curl -s -X GET \
  "https://$BRITIVE_TENANT/api/cspm/wiz/findings/wiz-roles?integration=wiz-production&size=5" \
  -H "Authorization: TOKEN $BRITIVE_API_TOKEN"

{
  "page": 0,
  "size": 5,
  "count": 128,
  "data": [
    {
      "sourceRoleName": "acme-prod-admin",
      "sourceEnvironment": "Acme Production (123456789012)",
      "britiveRoleName": "acme-prod-admin",
      "controlName": "IAM role with administrative privileges",
      "controlDescription": "Role grants unrestricted access to all resources.",
      "controlSeverity": "CRITICAL",
      "appName": "AWS Production",
      "appType": "AWS",
      "profileName": "Prod-Admin-Breakglass",
      "environment": "Production (a1b2c3d4)",
      "source": "britive",
      "resolved": "resolved"
    }
  ]
}

Manage the Integration

Rename or re-describe

Editing the name or description leaves the token, id, and ingest URL untouched.

On the integration’s General tab, click Edit, change the Name or Description, then Save.

curl -s -X PATCH \
  "https://$BRITIVE_TENANT/api/cspm/integrations/wiz-production" \
  -H "Authorization: TOKEN $BRITIVE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "wiz-prod-us", "description": "US production Wiz tenant"}'

Both fields are optional — omit one to leave it unchanged.

Rotate the token

Rotation generates a fresh token and replaces the stored hash in place.

On the General tab, click Rotate Token, confirm, then copy the new token from the dialog.

The old token stops working immediately. There is no grace period and no overlap window. Wiz will receive 403 on every event until you paste the new token into the webhook — and those events are not retried by Britive. Plan the rotation and the Wiz update as a single change.

The id, name, description, and ingest URL survive rotation unchanged. Only the token and the Created timestamp change — that timestamp tracks the active token’s creation, so it’s how you tell when a token was last rotated.

Delete an integration

Delete the integration from the CSPM Integration list.

Deleting removes the integration record and invalidates its token, so its ingest URL starts rejecting requests. Disable or delete the corresponding webhook in Wiz too, so it isn’t posting into a dead endpoint.

Troubleshoot

Symptom	Likely Cause	Fix
Wiz test returns `403`	Token wrong, has a `Bearer`/`TOKEN` prefix, or belongs to a different integration	Re-copy the token; send it bare in the `Authorization` header. If it’s lost, rotate
Wiz test returns `404`	Ingest URL path is wrong or truncated	Re-copy the full Ingest URL, including the `cspm-<uuid>` segment
Wiz test returns `400`	Empty or unparseable body	Confirm the Action Template is set as the webhook body
`204` received but no findings	Correlation still running, or no role-type events sent yet	Wait, then confirm the Wiz rule fires on IAM/role controls
Every row `Unresolved`, Application empty	Roles aren’t cataloged in Britive	Onboard the cloud application covering those accounts

For the full diagnostic path, see Troubleshooting.

Next Steps

Findings reference — every column explained, plus the API filter grammar
Troubleshooting — trace an event through the pipeline
Cloud Providers — onboard the applications that findings resolve against

Last updated on August 7, 2026

Findings Reference