SaaS Supply-Chain Response Playbook: Rotate, Revoke, Re-test

Phase 1 — Triage (< 1 hour)

• Assign an incident commander and declare the incident at whatever severity your runbook calls for third-party exposure (typically P2/SEV-2 until the scope is bounded).
• Read the bulletin carefully, twice. Note the exposure window, the data categories listed, and what the vendor explicitly says was not exposed. The scope you work from must be what the bulletin says, not what a Slack thread speculates.
• Start the clock. Note the UTC time; most of the phases below are relative.
• Open a dedicated channel. Not a thread in #security — a channel named after the incident, with a pinned status line that tracks phase, open blockers, and ETA to close.
• Loop in legal and communications early. Regulatory clocks start at vendor disclosure, not at your discovery; your DPO / counsel need the heads-up on day 0.

Phase 2 — Inventory (< 2 hours)

Before you rotate anything, know what the vendor could have reached. Build the list from three angles.

• Credentials you gave the vendor: API tokens, OAuth refresh tokens, Git PATs for mirroring, bot tokens for Slack / Linear / Jira / Notion, service-account JSON for GCS / S3 sync, webhook signing secrets.
• Credentials the vendor gave you: API keys the vendor issued (for your scripts, CI, bots), MCP server auth material, webhook endpoints hosted on your side.
• Trust relationships: SSO group mappings (if the vendor is an IdP or consumes one), SAML cert exchanges, SCIM bearer tokens, Zapier / Make / n8n integration tokens that chain through the vendor.

Pull the authoritative list from your secrets manager, your SSO admin console, and your attack-surface inventory. Do not reconstruct from memory.

Phase 3 — Rotate (< 24 hours)

Rotation order matters. Start with the highest-privilege, longest-lived credentials and work down.

1. Highest-privilege first: admin-scoped tokens, broad Slack / GitHub scopes, service accounts with write access to customer-data stores.
2. Long-lived next: static API keys, PATs, bot tokens.
3. Short-lived last: OAuth refresh tokens, STS session tokens — they expire naturally but revoke them anyway to invalidate replay.
4. Non-vendor fan-out: for every rotated credential, update every downstream system that holds it — CI secrets, Terraform modules, Vault entries, Kubernetes secrets, infra-as-code variable files. A rotation that misses the fan-out leaves the old credential live under a new name.
5. Track each rotation: credential ID, old-key-id, new-key-id, rotated-at, verified-at, verifier. Your auditor will ask.

Opportunity move: if you find a credential in the inventory you did not know existed, do not add it to the rotation and close the ticket. File a follow-up to get it into your secrets manager and inventory properly.

Phase 4 — Revoke (< 24 hours, parallel to Phase 3)

• OAuth grants to the vendor's application in each third-party system the vendor touches (GitHub app installations, Slack app installs, Google Workspace OAuth, Microsoft app consents).
• Webhooks inbound from the vendor — disable receivers until you have rotated the signing secret and confirmed the new secret is live.
• IP allowlists that the vendor relied on — tighten to only the vendor's documented new egress ranges, not the legacy ones.
• MCP servers the vendor configured — re-auth, rotate client secrets, and reconfirm tool-level allowlists.
• Service accounts and bot users exclusive to the vendor — if the vendor does not strictly need them during the response window, suspend them.

Phase 5 — Hunt (< 48 hours)

Rotation closes the forward door. Hunt is the backward question: did the attacker use any of the credentials during the exposure window?

• GitHub / GitLab audit logs: unexpected clones, new deploy keys, new SSH keys on bot accounts, pushes via the vendor's integration user outside normal working hours, forks of private repos.
• Slack admin audit log: new app installs, posts from the vendor bot token to channels it does not normally touch, token-scope expansions.
• Jira / Linear / Notion: unusual read activity on sensitive issues / pages via the vendor's integration user, bulk exports, new API-token issuance.
• Cloud audit logs: AWS CloudTrail / Azure Activity / GCP audit for the vendor's service-account activity — IAM changes, data-read spikes, new instances.
• Your own CI: pipeline runs triggered by vendor-issued API tokens that did not line up with a human action, especially runs that touched other secrets.
• Egress logs: unusual source IPs calling your vendor-webhook receivers; replayed deliveries; signed payloads with timestamps outside the expected window.
• EDR / endpoint: if the vendor integrates with a developer tool (CLI, desktop plug-in, local MCP server), hunt for anomalous child processes, outbound connections, or clipboard access on dev machines in the exposure window.

If you find evidence of reuse, declare a second incident scoped to what the attacker actually did — do not quietly fold it into the vendor-response ticket.

Phase 6 — Re-test and document (< 72 hours)

• Re-test every integration end-to-end. The webhook still delivers. The Git Sync still writes. The Slack bot still posts. Rotation without re-test is a roulette spin for Monday morning.
• Confirm every old credential is dead. Try to use the old token; expect a 401. For OAuth grants, confirm the token-revocation endpoint returned 200 and the token info endpoint returns invalid.
• Document the response: timeline, scope, actions taken, reused-credential findings, open follow-ups. Attach the vendor bulletin, your rotation log, and screenshots of the hunt queries.
• File the follow-ups: everything discovered mid-incident that isn't incident-scope work (undocumented credentials, missing budget caps, missing SSO coverage) goes on the backlog with owners and due dates.
• Debrief within one week. Not a blameless post-mortem — a timed post-mortem. If any phase took longer than its target, identify the single biggest tool gap that made it so.

A note on comms

If customer data flowed through the compromised vendor on your side, you have an obligation to notify — both because it is right and because many regulatory regimes (GDPR, state breach laws, sector-specific regs) put the clock on you, not the vendor. Have a pre-drafted customer-notification template. Keep it short, factual, and explicit about what was and was not exposed in your system, separate from the vendor's own scope statement. Legal review is part of the playbook, not an afterthought.

What good preparation looks like before the next one

• Vendor inventory with credential cross-reference. For every SaaS vendor, which of your credentials they hold and which of their credentials you hold. Live, not a spreadsheet from onboarding.
• Pre-scoped rotation runbooks for your top ten highest-risk vendor integrations. Each should be a 20-minute execution, not a two-hour investigation.
• Secrets-scanning on CI and registries. If a rotated credential is also committed to Git in six places, the rotation does not take.
• Egress logs on the receiver side of every vendor webhook. The hunt phase is only as fast as your log availability.
• A single channel template for third-party incidents, so the IC is not inventing structure under pressure.

How TigerGate helps

• Attack Surface Management builds the SaaS and integration inventory you'll need at the Triage step — including the long-tail tools your core inventory probably missed.
• Secrets scanning finds every place a vendor-issued token leaked into source, images, or CI — the fan-out list for Phase 3.
• Identity Security surfaces OAuth grants and SSO integrations by vendor, with last-used timestamps — Phase 4 as a dashboard.
• eBPF runtime detection provides the egress logs and CI pipeline anomalies you'll need for the hunt in Phase 5.
• Compliance evidence packages the rotation log, hunt findings and debrief into the audit-ready artefact your SOC 2 / ISO 27001 cycle wants.