If your CNAPP and CSPM platform is compromised: contain the cloud roles and rebuild trust

When a CNAPP or CSPM platform is compromised, the attacker inherits a trusted role into every cloud account it scans, a ranked list of your weakest resources and, if remediation is switched on, the ability to change your estate. The incident can start in your own tenant of the platform (a stolen admin login, a leaked API token, a rogue integration) or at the vendor, where a breach of the shared service puts every customer's connector credentials at risk. Either way the response is the same at its core: cut the platform's access into your clouds first, find out what was read or changed, rotate everything the platform held, then reconnect it with fresh, narrower trust. This guide is for cloud security engineers, incident responders and platform owners. It is vendor-neutral and assumes you run workloads in one or more of AWS, Azure and Google Cloud; confirm exact role and setting names in your vendor's documentation. Hardening before an incident is covered in Securing the CNAPP and CSPM platform itself, and this page does not repeat it.

Key takeaways

• Cut the cloud side first. The platform's power lives in roles and service accounts inside your clouds; disabling or constraining those stops the attacker even if the platform console is still in their hands.
• Assume the findings were read. A ranked list of exposed, unpatched and over-privileged resources is a target list; fix the top of it during the incident, not after.
• Rotate everything the platform held. External IDs, cloud keys, client secrets, registry and repository tokens, ticketing and chat webhooks, and SSO settings all count, and a missed one is how attackers come back.
• Snapshots and remediation roles widen the blast radius. Disk snapshot scanning can expose secrets stored on workload volumes, and write roles let an attacker change configuration under the platform's name.
• Reconnect with narrower trust than before. Rebuild integrations read only, with unique trust conditions and federation instead of stored keys, and add write roles back only after review.

How the compromise shows up

Few platforms alert on their own takeover. The signals usually appear in the cloud provider's logs, in the platform's audit trail, or in a vendor notice. The table lists the common ones and where to look.

Triage: the first hour

Triage decides how hard and how fast to contain. Answer these in order and write the answers into the incident record with the time and the evidence behind each.

1. Where did it start? Your tenant (admin account, API token, SSO), the vendor's shared service, or a component you host (an agent, an admission controller, an outpost or scanner running in your account).
2. Which integrations exist? List every cloud account, subscription, project, cluster, registry, code repository, ticketing system and chat channel connected to the platform, with the identity each one uses.
3. Which of those identities can write? Remediation, response and agent installation roles are the priority, ahead of read roles.
4. Is snapshot or agentless disk scanning enabled? If yes, treat any secret stored on a scanned volume as potentially exposed.
5. What did the attacker see? Export the current findings, attack paths and inventory as the attacker would have seen them; this becomes your urgent fix list.
6. Is the activity ongoing? Recent role assumptions or platform sessions from unknown sources mean containment starts now, before the investigation is complete.

Blast radius by component

This is our view of what each common part of a CNAPP gives an attacker and the first containment move for it. Not every platform has every component.

Containment by priority

Contain from the cloud side outwards. Each step is reversible, so you can restore scanning once trust is rebuilt.

1. Remove write capability. Detach or deny remediation and response roles in every account. In AWS an explicit deny on the role overrides any allow; in Azure remove the role assignments from the service principal; in Google Cloud remove the IAM bindings.
2. Cut active sessions of read roles. In AWS, the IAM console action Revoke active sessions attaches an inline policy named AWSRevokeOlderSessions that denies all actions to sessions whose aws:TokenIssueTime is earlier than the revocation time; AWS notes it does not affect requests signed with long-term IAM user keys, which must be deactivated separately. In Microsoft Entra, Microsoft's incident playbook for compromised applications recommends disabling sign-in for the service principal first (accountEnabled set to false) so you have time to assess before removing credentials.
3. Break the trust path. For AWS cross-account roles, change the sts:ExternalId condition to a value the vendor does not have, or set the trust policy to deny until the new integration is ready. In Google Cloud, disable the scanner service account or its keys; Google recommends disabling keys first and deleting only once you are sure they are no longer needed.
4. Stop data movement. Disable snapshot scanning, list snapshots created by the platform's roles, remove any createVolumePermission entries that share them with accounts you do not own and delete stray copies after evidence is taken.
5. Lock the platform tenant. Disable compromised admin accounts, revoke API tokens, remove unknown SSO or SCIM changes and break-glass any local admin. If the vendor side is compromised, follow the vendor's instructions and keep your cloud-side containment in place regardless.
6. Fix what the attacker saw. Take the top critical findings and attack paths from the export and close them now, starting with internet-exposed resources holding credentials or sensitive data.

Rollback: keep a record of every role, trust policy and binding you changed, with its previous state, so scanning can be restored deliberately rather than by undoing changes in a hurry.

Credential rotation and trust reset

Rotation must cover everything the platform held or could reach, not just the credential you think was stolen. The table shows the usual set.

Rotation of secrets the platform could read is often the largest piece of work. Microsoft's playbook orders downstream rotation by exposure: secrets directly retrieved first, then remaining secrets in exposed vaults, then the rest of the exposed subscriptions. The same order works across clouds. See the Cloud Credential Compromise Playbook for cloud key response in depth.

Eradication and rebuild

Before you reconnect, remove what the attacker may have left behind. Persistence after a CNAPP compromise sits in your clouds more often than in the platform.

• New identities and credentials: search every connected account for users, access keys, role trust changes, service principal credentials and service account keys created during the window (ATT&CK T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles).
• Configuration changes: compare security groups, firewall rules, bucket and storage policies, KMS key policies and logging settings with a known good baseline; attackers often weaken logging to hide later activity.
• Compute and images: look for new instances, functions or images, including images pushed to registries the platform could write to (ATT&CK T1525 Implant Internal Image).
• Cluster objects: check for new cluster role bindings, webhooks and daemon sets, and for admission controller changes that would allow unscanned images.
• Self-hosted components: rebuild any scanner, outpost or collector you host from a clean image rather than cleaning it in place.
• Platform tenant: remove unknown admins, tokens, integrations, policy changes and exceptions, and confirm the policy set matches your last reviewed version.

Recovery and reconnection

1. Pilot one account. Reconnect a single non-production account with a new read only role, a new external ID or federated trust, and the minimum permission set the vendor documents.
2. Verify behaviour. Watch the cloud logs for a full scan cycle: source, API mix and volume should match the vendor's documented pattern.
3. Roll out in rings. Production accounts next, then the organisation or management group level once the pattern holds.
4. Add write roles last. Re-enable remediation only for named actions, with approval for anything destructive, and only after the post-incident review.
5. Re-enable snapshot scanning deliberately. Confirm where snapshots are processed and that copies are deleted after the scan.
6. Restore integrations. Reissue repository, registry, ticketing and SIEM connections with new credentials.

Roll back by disabling the new role again if the reconnected integration behaves unexpectedly; because the old trust is gone, this cannot reopen the attacker's path.

Evidence to preserve and notification

• Cloud logs: export audit logs for every connected account covering the full window before retention expires, including data events where they exist.
• Platform audit trail: export admin, token, policy, exception and integration history; some platforms keep it for a short period only.
• Snapshots and changes: record snapshot IDs, sharing attributes and every configuration change with before and after state.
• Vendor communications: keep notices, case numbers and the vendor's statement of what was exposed.

Notification depends on what was read. If scanned disks, storage or code contained personal data, data protection breach rules may apply; under GDPR Article 33 a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Sector and national incident reporting rules may apply too: see the Cyber Incident Reporting Requirements Map. If the vendor was breached, your contract's notification and cooperation clauses decide what the vendor must tell you and when.

Decision guidance

Detection and measurement

• Time to cut cloud access: minutes from declaration to all platform roles denied or disabled.
• Integration coverage: percentage of platform integrations with a named owner and documented rotation steps.
• Rotation completeness: credentials rotated out of credentials held, tracked to 100%.
• Stored keys remaining: number of connectors still using long-lived keys rather than roles or federation.
• Baseline alerts: alerts that fire when the platform's roles are used from outside the vendor's documented sources, tested at least yearly.

Framework mapping

Common failure patterns

• Rotating the stolen key and nothing else. The Cloudflare Thanksgiving breach showed how credentials left unrotated after an earlier supplier breach were later used to get in.
• Waiting for the vendor's root cause before acting. When a provider is breached, customers who rotate early fare better; the Sumo Logic breach led the vendor to advise customers to rotate the credentials they had given it.
• Forgetting snapshot copies. Shared or copied snapshots outlive the role that made them and keep disk contents available.
• Reconnecting with the same permission set. Restoring the old write roles and broad read scope recreates the exposure the attacker used.
• Ignoring suppressed findings. Exceptions added during the window can hide the attacker's foothold long after the incident is closed.

Practitioner checklist

• Keep a current list of every platform integration, its identity, its permissions and its owner.
• Write and test the cloud-side cut-off for each provider before you need it.
• Deny remediation roles first, then revoke sessions of read roles.
• Change external IDs or federated trust so old connector credentials cannot work.
• Check snapshot creation, sharing and copies for the whole incident window.
• Export the findings and fix the top critical attack paths during the incident.
• Rotate every secret the platform held or could read, in order of exposure.
• Hunt for new identities, keys and configuration changes in every connected account.
• Reconnect in rings, read only first, write roles only after review.
• Preserve cloud and platform logs before retention expires.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• AWS: Revoke IAM role temporary security credentials
• AWS: The confused deputy problem
• AWS: Share an Amazon EBS snapshot
• Microsoft: Compromised and malicious applications investigation
• Google Cloud: Best practices for managing service account keys
• MITRE ATT&CK: Trusted Relationship

Related NHI Mgmt Group resources: CNAPP Guide · Securing the CNAPP and CSPM platform itself · Cloud Incident Response Guide · How to review AWS cross-account trust policies for confused deputy · CNAPP and CSPM platform integration security guide