Skip to content

Troubleshooting

Overview

CSPM problems fall into two categories, and telling them apart is the first diagnostic step:

  • Findings aren’t arriving — Wiz isn’t successfully delivering events. The Findings report is empty.
  • Findings arrive but don’t resolve — rows appear, but Application, Profile, and Environment are empty. Delivery works; correlation doesn’t.

The HTTP status Wiz receives tells you which one you have.

Isolate the Problem

Send a test from Wiz

Use Wiz’s Test action on the webhook and note the response code.

ResponseMeaningGo to
204 No ContentDelivery worksFindings aren’t resolving
403 ForbiddenAuthentication failedAuthentication failures
404 Not FoundWrong URL or methodRouting failures
400 Bad RequestEmpty or unparseable bodyPayload problems
500Server-side errorContact Britive support with the timestamp
Timeout / no responseNetwork or DNSConfirm Wiz can reach your tenant hostname

Confirm the report is empty for the right reason

An empty report with a passing test usually means the Wiz rule hasn’t fired yet, or it’s firing on controls that don’t produce role findings.

403 Forbidden

Britive rejects a request unless the token hash matches, the tenant in the request host owns the integration, and the integration id in the URL is the one that token authenticates. Any disagreement returns 403 — deliberately, so a token can’t be replayed against a different integration’s URL.

CauseCheckFix
Token has a prefixIs the header Authorization: Bearer <token>?Send the token bare — no Bearer, no TOKEN
Token was rotatedCompare the Created date on the General tab against when you last updated WizRotate again and paste the new token into Wiz immediately
Token belongs to a different integrationDoes the cspm-<uuid> in the URL match the integration the token came from?Re-copy both values from the same integration
Whitespace in the tokenA trailing newline from copy/pasteRe-copy; verify no leading or trailing space
Wrong tenant hostnameIs the URL host your Britive tenant?Re-copy the full Ingest URL from Britive

A lost token cannot be recovered — Britive stores only its SHA-256 hash. Rotate Token is the only path forward, and it invalidates the current token the instant you click it.

404 Not Found

The request reached Britive but didn’t match the ingest route.

CauseFix
Method isn’t POSTOnly POST is accepted
URL is missing the id segmentThe path must be /wiz-ingest/cspm-<uuid>, not /wiz-ingest
The id segment was truncatedRe-copy the Ingest URL in full — UUIDs are easy to clip
Extra path segments appendedThe route is exactly one segment deep; /wiz-ingest/cspm-<uuid>/events is rejected
Trailing slashRemove it

400 Bad Request

The request authenticated but carried no usable payload.

CauseFix
Body template not configuredPaste the Action Template from Britive as the webhook body
Body is an empty JSON objectConfirm the Wiz rule actually populates the template fields
Content-Type not JSONSet application/json

Wiz sometimes emits payloads with bare :, or :} where a value is missing. Britive repairs these before parsing, so malformed-looking JSON from Wiz is not itself a cause of 400.

Findings Arrive but Don’t Resolve

Wiz gets 204 and rows appear, but the Britive columns are empty. Work down the correlation chain — each empty column narrows the cause.

Every row: Application, Profile, Britive Role all empty

Britive can’t find these roles in its catalog at all.

CauseCheckFix
Cloud application not onboardedIs there a Britive application covering the accounts Wiz is scanning?Onboard it — see Cloud Providers
Environment not added to the applicationIs the specific account in the application’s environment list?Add the environment and re-scan
Britive hasn’t scanned yetDoes the application show recent scan activity?Run an environment scan so roles get cataloged
resource.id altered in the templateDoes the Action Template still use {{issue.entitySnapshot.providerId}}?Restore the template from Britive verbatim

The match is on the cloud provider’s native role identifier. If that field doesn’t render, or renders as a display name instead of the provider id, nothing will ever match.

Application populated, Profile empty

This is usually not a problem — it’s the finding.

Britive knows the role, and no profile grants it. That’s exactly the ungoverned standing privilege the integration exists to surface. Bring the role under a profile and the row flips to Resolved after the next event.

Investigate only if you’re confident a profile does grant that role. In that case, verify the profile’s permission is attached with the same role name and permission type Britive cataloged.

Environment empty, everything else populated

The role resolved, but no Britive environment’s native id matched Wiz’s resource.subscriptionId.

CauseFix
Environment’s native id doesn’t match the cloud account idConfirm the Britive environment’s native id is the real AWS account / Azure subscription / GCP project id
Template field changedConfirm subscriptionId maps to {{issue.entitySnapshot.subscriptionExternalId}}
Account not in this application’s environment treeAdd it to the application

sourceEnvironment will still show what Wiz reported — compare it against your Britive environment’s native id to spot the mismatch directly.

Some rows resolve, others don’t

Expected. The report is a mix by design: roles you govern, roles Britive can see but doesn’t govern, and roles from accounts you haven’t onboarded. Filter by resolved eq unresolved to work the gap.

No Findings At All

Wiz reports success but the report stays empty.

Wait for correlation

Ingestion is asynchronous. Britive returns 204 on receipt and correlates afterwards, off a queue. Give it a few minutes before concluding anything.

Confirm the rule fired

A passing webhook test only proves connectivity. Check in Wiz that the automation rule bound to the webhook has actually triggered on real issues.

Confirm the rule produces role findings

Only findings whose flagged resource is a role appear in the report. Everything else is ingested and stored but deliberately not shown.

If your Wiz rule covers storage, networking, or compute controls, it will deliver 204s and produce no visible findings. Bind the webhook to rules covering IAM and identity controls.

Confirm you’re looking at the right integration

Findings are scoped to a single integration. With several Wiz integrations configured, confirm you’re viewing the one whose ingest URL Wiz is actually posting to — match the cspm-<uuid> in the Wiz webhook URL against the Ingest URL on the integration’s General tab.

Check the resource type rendering

Verify the Action Template’s resource.type still maps to {{issue.entitySnapshot.nativeType}}, and that Wiz renders it as role for the findings you expect. A different casing or a vendor-specific type string won’t match.

Configuration Errors

“A CSPM integration named ‘x’ already exists”

Names are unique tenant-wide, across all CSPM apps — not per app type. Pick a different name, or reuse the existing integration.

Re-submitting an integration’s own current name on a PATCH is a no-op, not a conflict.

“No CSPM integration found with name: x”

The identifier didn’t match any integration by id or by name. Names are case-sensitive. List them to confirm:

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

“Unsupported CSPM app”

The app value wasn’t recognized. For Wiz, use WIZ — it’s matched case-insensitively, so wiz works too. Check for a typo or stray whitespace.

“Unsupported filter attribute”

The attribute isn’t queryable. The error names every supported attribute. The most common cause is filtering on environment, which is resolved in the application layer and cannot be queried — use sourceEnvironment instead. See Filterable attributes.

“Unsupported filter operator”

Only eq, co, and sw are supported. There is no ne, gt, lt, or in, and no or or parenthetical grouping.

CSPM Integration missing from the navigation

The identity lacks the securityadmin.security.manage permission. Have an administrator grant it.

Next Steps

Last updated on