#14.5 Third-Party and Supply Chain Breach

Playbook ID: PB-SUPPLY | Default severity: SEV-2 (escalate to SEV-1 if the vendor holds standing credentials into a production system of record, or if access to regulated personal data is confirmed; drop to SEV-3 only once you have proven the integration held no live access) | Owner: Incident Commander

#When to run this

Open this playbook on any of:

• A vendor breach notification — email, status page, security bulletin, a call from your account manager, or a subprocessor notice under your DPA.
• Public disclosure naming a vendor you use. After F5 disclosed that nation-state actors had held access to its network for at least twelve months and stolen BIG-IP source code and undisclosed vulnerability information, CISA issued Emergency Directive ED 26-01 with patch deadlines of 22 and 31 October 2025.
• Your own telemetry — bulk record reads by a vendor's service principal; an OAuth application querying object types it has never touched; API calls from vendor infrastructure outside their normal window.
• A build-chain trigger — CI installed a package version later found malicious, or an Action you pin by tag was republished. tj-actions/changed-files (CVE-2025-30066) reached 23,000+ repositories; a backdoored aquasecurity/trivy-action stole LiteLLM's PyPI publishing tokens and malicious wheels shipped five days later (LiteLLM).
• A fourth-party notice — your vendor telling you their vendor was breached.

Not for: takeover of your own tenant with no vendor involved (14.3), compromise of your identity provider (14.4), or exploitation of an edge appliance you operate (14.12) — use PB-SUPPLY to scope and cut standing access, then hand the appliance to 14.12. Vendor tiering, due diligence and contract clauses are Chapter 11. This is the day those stop being theoretical.

#What you are dealing with

You did not get breached. You got included. Someone else's responders are having the worst week of their year, and the only thing you control is how much of your data is still reachable from inside their burning building. Third-party involvement now appears in roughly 48% of confirmed breaches — about a 60% year-over-year increase — and only 23% of third parties had fully remediated their known MFA issues (DBIR 2026 via SecurityWeek).

Your blast radius is defined by standing trust, not by the vendor's breach size. An OAuth refresh token is a key you cut for a contractor: it keeps working after you change your password, after the project ends, after they stop returning your calls — and, the part that ruins quarters, after someone lifts it out of their van. Salesloft Drift is the case to know. Attackers reached Salesloft's GitHub environment, pivoted into Drift's AWS environment, and stole the OAuth refresh tokens customers had issued to Drift. Between 8 and 17 August 2025 they exported records from 700+ organizations — Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, Tanium and Zscaler among them — reaching Salesforce, Google Workspace and in some cases Slack (AppOmni; CSA). No customer had a vulnerability to patch. Every customer had work to do. And the highest-value loss was secondary: API keys, Snowflake tokens and passwords that customers' own staff had pasted into support-case text over the years. The CRM was the door; the ticket queue was the vault.

Teams get this wrong in two reliable ways. They wait — the vendor's disclosure timeline belongs to the vendor's counsel, while your GDPR clock runs from the moment you have reasonable certainty. And they perform containment theatre, rotating the vendor's password while the real exposure is a refresh token on infrastructure they do not control. Microsoft says it plainly: "Normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack, because these apps are external to the organization" (illicit consent grants). Actionable takeaway: treat every free-text field your vendors can read as a credential store that will eventually be exfiltrated, and secret-scan it on a schedule.

#Roles for this incident

Table conventions. `TIP-OFF marks a step the adversary can observe. EVIDENCE` marks a step that degrades evidence if run out of order. Do not reorder around those markers without the IC.

#Phase 1 — Detection and Triage

# Entra ID — enumerate every delegated consent grant in the tenant.
# Microsoft's documented method; run under Microsoft Graph PowerShell.
.\Get-AzureADPSPermissions.ps1 | Export-Csv -Path "Permissions.csv" -NoTypeInformation
# ConsentType = AllPrincipals means the app can reach EVERY user's content.

// Defender XDR — everything one OAuth application did. Populated ONLY if
// Defender for Cloud Apps and the Microsoft 365 activities connector are on;
// otherwise this returns nothing, silently.
CloudAppEvents
| where OAuthAppId == "<application id>"
| project ActionType, AccountObjectId, IPAddress, UserAgent, IsAdminOperation, UncommonForUser

#Phase 2 — Containment

The usual advice — posture quietly, then remediate in one burst so you do not tip off the adversary — partially inverts here. In your own estate you can watch an intruder while you build the picture. In your vendor's estate you have no telemetry, no authority and no ability to observe, and their containment and disclosure will tip the actor off regardless. So: scope fast, time-boxed, then contain your side in one atomic burst. Splitting revocation across days hands the adversary the paths you have not closed yet.

# Entra — revoke sessions for an in-scope account. Resets
# signInSessionsValidFromDateTime, killing refresh tokens and session cookies.
# Privileged Authentication Administrator for admin accounts; User Administrator otherwise.
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'svc-vendor@contoso.com' -ConsistencyLevel eventual
Revoke-MgUserSignInSession -UserId $User.Id

# Google Workspace — BOTH calls are required; they do different jobs.
# Scope: https://www.googleapis.com/auth/admin.directory.user.security

# 1. Sign out everywhere and reset sign-in cookies.
POST https://admin.googleapis.com/admin/directory/v1/users/{userKey}/signOut

# 2. Revoke the third-party OAuth grant. signOut does NOT do this — without
#    this call, the vendor's app keeps working.
DELETE https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}

// AWS — the policy the console attaches as AWSRevokeOlderSessions. Denies
// sessions assumed before the timestamp (plus ~30s of propagation slack).
// Requires PutRolePolicy. Service-linked roles cannot be revoked this way, and
// roles from IAM Identity Center permission sets must be revoked in Identity Center.
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny", "Action": "*", "Resource": "*",
    "Condition": { "DateLessThan": {"aws:TokenIssueTime": "2026-09-05T14:20:00Z"} }
  }
}

#Phase 3 — Eradication

What to demand from the vendor — and what you will probably get. Ask in writing for: the exposure window with start and end times; whether your tenant identifier appears in their access logs; the objects, fields and record counts reached in your instance; whether credentials you issued them were in scope; the log sources searched and their retention; indicators you can hunt with; whether law enforcement or a regulator is involved; and their written position on controller versus processor. What comes back is usually a status-page update and a confidentiality request. Send it anyway, keep the thread, and put the gaps in the review. Actionable takeaway: the time to negotiate evidence access is at contract signature — so send Chapter 11's clause list to procurement the week after this closes, while the pain is still fresh enough to win the argument.

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

Two things start clocks here, and only one of them is the vendor's announcement.

Two determinations must happen early and in writing. First, controller or processor: if you are the controller and the vendor is your processor, the duty to the supervisory authority and to data subjects is yours, and pointing at the vendor is not a defense. Second, your downstream duty: if your customers' data sat in that platform, you owe your customers notice on your contract's clock regardless of what the vendor tells the world. Chapter 15 carries the full matrix, templates and decision tree — never let a technical responder file a regulatory early warning without disclosure-counsel review of the wording. And agree what you will say publicly before the vendor's next update lands. Contradicting your vendor in public is a second incident, and it is the one the press will cover.

#Automation notes

The highest-value automation here is not a containment action. It is a "vendor name in, integration inventory out" workflow that answers step 1.3 in under five minutes: every OAuth grant, service principal, API key, SSO assignment, SCIM account, webhook and allowlist entry tied to a named vendor, pulled live from your IdP, cloud accounts and SaaS admin APIs. Most teams take a day and a half to assemble that by hand, and the whole incident queues behind it. Build that one thing and you buy back a day of exposure on every future vendor breach.

Safe to automate — reversible, scoped, verifiable after the fact: grant and key enumeration; diffing today's grants against a stored baseline; exporting logs and applying legal holds; pulling all activity for a named application ID; secret-scanning support tickets; opening the ticket and paging the roles; running the Phase 3 re-enumeration diff on a schedule.

Human gate required — irreversible, or blast radius that scales with a false positive: revoking a grant carrying production traffic; disabling SSO federation or SCIM; deleting an OIDC identity provider (there is no disable operation, only delete, and every role that trusts it stops working); attaching a quarantine SCP; rotating a shared secret with no tested rollback; and every customer or regulator notification. Microsoft recommends against the tenant-wide blunt instrument of disabling integrated applications — a script that "revokes all third-party grants" will take your business offline faster than the adversary would have.

The gate rule that holds up: automation may gather, enrich, correlate and recommend without approval; it may act only where the action is reversible, scoped and rate-limited; irreversible or tenant-wide actions require a named human approver. Every automated action writes its evidence into the incident log — an action with no artefact is one you cannot prove to a regulator six months from now.

#Pitfalls