CSPM Integration
Overview
Cloud Security Posture Management (CSPM) tools scan your cloud environments and flag risky configurations — over-privileged IAM roles, stale credentials, unused admin access. What they can’t tell you is whether a flagged resource is already under governance.
A role flagged as over-privileged is a very different problem depending on the answer:
- Governed — the role is attached to a Britive profile. Nobody holds it standing; it’s checked out just-in-time, time-bound, and fully audited. The finding is largely mitigated by how the access is granted.
- Ungoverned — the role is assigned directly in the cloud provider, outside Britive. This is real standing privilege and needs attention.
The CSPM integration closes that gap. Connect your CSPM tool to Britive once, and every finding it sends is automatically cross-referenced against your Britive applications, profiles, and roles.
What this section covers:
- Creating a CSPM integration and connecting your CSPM tool to it
- Reading the Findings report and understanding how each column is resolved
- Querying findings through the API, including the filter grammar
- Troubleshooting an integration that isn’t receiving data
How It Works
Your CSPM tool sends each finding to Britive over an outbound webhook. Britive matches the flagged role against its own catalog of cloud roles and profiles, then presents the result in the Findings report.
flowchart LR
A["CSPM tool flags a<br/>risky cloud role"] --> B["Britive receives<br/>the finding"]
B --> C["Britive matches it against<br/>its applications and profiles"]
C --> D["Finding appears in the report,<br/>Resolved or Unresolved"]
Two properties are worth calling out:
Findings appear shortly after they’re sent. Britive acknowledges each event on receipt and does the matching afterwards, so allow a brief delay between a finding being sent and it showing up in the report.
Matching is a lookup, not a scan. Britive doesn’t re-scan your cloud accounts. It matches the reported resource against the roles Britive already catalogs from your onboarded applications. A role has to be known to Britive for the finding to resolve to anything.
Matching Logic
Every finding lands in one of three states, determined by how far the join gets:
| State | What it means | What you see |
|---|---|---|
| Unresolved, no application | Britive has never cataloged this role. It belongs to an account or cloud that isn’t onboarded. | Status Unresolved, Application and Profile both empty |
| Unresolved, with application | Britive knows the role — it’s in an onboarded application — but no profile grants it. | Status Unresolved, Application populated, Profile empty |
| Resolved | The role is attached to at least one Britive profile. | Status Resolved, Application and Profile both populated |
The middle case is the one to watch. Britive can see the role, which means you could bring it under a profile — the finding is telling you about privilege that exists in an environment you already govern but haven’t wrapped in JIT access.
Only findings whose flagged resource is a role are surfaced. Findings about buckets, VMs, network configuration, and other resource types are received and stored, but the Findings report shows role findings only — those are the ones Britive can correlate against profiles.
Section Contents
In This Section
- Wiz Integration
Create a CSPM integration in Britive, configure the Wiz webhook with the generated token and action template, and verify findings are flowing.
- Findings Reference
Every column in the CSPM Findings report, how each value is resolved, and the API endpoints, filter grammar, and sort attributes for querying findings.
- Troubleshooting
Diagnose a CSPM integration that isn't receiving findings, isn't resolving them against Britive profiles, or is rejecting Wiz webhook requests.
Next Steps
- Wiz Integration — create the integration in Britive and configure the webhook in Wiz
- Findings reference — every column, the API, and the filter grammar
- Troubleshooting — when findings don’t arrive or don’t resolve