SaaS, supply chain and OAuth abuse are converging in 2025

At a glance

What this is: FireCompass’s weekly report argues that SaaS trust abuse, supply chain compromise, and OAuth persistence are converging into a single operational problem for defenders.

Why it matters: IAM, PAM, and cloud security teams need to treat third-party integrations, delegated access, and developer tooling as part of one governance surface, not separate risk domains.

By the numbers:

• More than 700 organisations were affected by the Salesloft Drift breach, according to FireCompass.

Context

The core problem is trust expansion across SaaS, supply chain, and developer ecosystems, where a compromise in one service can quickly become durable access to many others. Traditional perimeter controls and routine patching struggle here because the attacker is not only exploiting a vulnerability, but also the delegated trust embedded in integrations, tokens, signed code, and automation.

This article is especially relevant to identity and access governance because OAuth tokens, service integrations, and third-party development tools behave like non-human identities once they can act across systems. When those credentials are persistent, over-scoped, or poorly monitored, they become a repeatable route to data access and lateral movement rather than a one-time breach condition.

The incidents described are not isolated anomalies. They reflect an increasingly typical operating model for modern attackers: compromise the trust fabric, keep access quiet, and move through legitimate channels that security teams often allow by design.

Key questions

Q: What breaks when OAuth access is not governed like a non-human identity?

A: Access persists beyond the user session that created it, so the organisation loses the usual sign-in checkpoints that would normally bound use. The application keeps operating with the originally granted token, which means revocation, ownership, and review become the real control points. Without them, integrations turn into standing access paths rather than temporary permissions.

Q: Why do third-party integrations increase risk in SaaS support environments?

A: Third-party integrations expand the attack surface because each connected app can expose data, permissions, or workflows outside the core platform. Weak configuration, excessive scopes, or compromise in a linked system can lead to unauthorized access or leakage. Teams should treat every integration as a governed dependency and review its necessity, permissions, and monitoring coverage.

Q: How do security teams detect when developer tooling is being used for reconnaissance?

A: Look for unusual credential searches, environment variable access, repository enumeration, and scripted scans across build and CLI workflows. The key signal is not one suspicious command but a burst of automated discovery that touches many secrets quickly across developer systems.

Q: How should organisations respond when a SaaS integration is compromised?

A: Treat it as an identity incident first. Revoke tokens, disconnect the integration, isolate affected tenants or workspaces, and review related service accounts and consent grants. Do not wait for a software patch if the access path is already active, because the attacker may be operating through valid authorization.

Technical breakdown

How OAuth token abuse turns delegated access into persistence

OAuth tokens are designed to let one application act on behalf of a user or tenant without sharing the primary password. That convenience becomes a control gap when the token outlives the business need, is granted broad scopes, or is reused across connected services. In the Salesloft Drift case, stolen OAuth tokens gave attackers persistent access into Salesforce and Google Workspace, which meant they could query data, exfiltrate it, and remain inside legitimate-looking session flows. The technical lesson is that token possession often matters more than user authentication once delegation has been established.

Practical implication: move OAuth review to issuance, scope, and revocation controls rather than relying on user password hygiene.

Why AI-assisted reconnaissance accelerates supply chain compromise

AI-assisted reconnaissance changes the economics of discovery by making it faster to search developer environments for credentials, secrets, and useful system paths. The article describes weaponised CLI tools that automatically scanned infected environments, which means the initial compromise can be followed by rapid harvesting of secondary access material. This matters because supply chain attacks increasingly target the build and developer layers, where secrets and environment variables are often exposed to scripts, logs, and local automation. The result is not just faster theft, but faster identification of the next system to compromise.

Practical implication: assume developer environments are searchable attack surfaces and restrict secret exposure in build and CLI workflows.

How signed-driver evasion undermines endpoint trust

Signed drivers are often treated as a trust boundary because they come with a valid signature that suggests legitimacy. The Silver Fox campaign shows how that trust can be abused when attackers preserve signature validity while changing behaviour enough to evade hash-based blocklists. That creates a gap between signature verification and actual safety, especially where EDR, AV, and kernel-level monitoring rely too heavily on static indicators. The attack demonstrates that trusted code paths can still be malicious, which is a broader lesson for defenders who depend on allowlists without behavioural validation.

Practical implication: pair signature checks with behavioural monitoring for driver loads and kernel-level changes.

Threat narrative

Attacker objective: The attacker objective was durable access to business data and connected services through trusted channels that were difficult to distinguish from normal administration.

1. Entry occurred through compromise of trusted SaaS, developer, or integration pathways rather than through noisy direct intrusion.
2. Credential_harvested activity focused on OAuth tokens, secrets, and environment data that could be reused across connected systems.
3. Escalation came from using legitimate delegated access to query data, exfiltrate information, and suppress forensic visibility.
4. Impact included broad data exposure, persistent access across SaaS estates, and operational disruption across affected organisations.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth persistence is now a governance problem, not just an authentication problem. Once a token can act across Salesforce, Google Workspace, and connected apps, the real control question becomes scope, lifetime, and revocation. Organisations that still treat OAuth as a plumbing detail are missing the fact that delegated access is now a primary attack surface. Practitioners should govern tokens as non-human identities with lifecycle controls, not as disposable integration artifacts.

AI-assisted reconnaissance creates discovery debt for defenders. The article shows that attackers are using AI tools to scan developer environments for credentials and secrets faster than manual methods ever could. That means the window between exposure and exploitation is shrinking, especially in CI/CD and local build contexts. Security teams need to assume that search at scale is now part of the compromise pattern, and that secret sprawl will be found quickly once access begins.

Supply chain abuse and SaaS abuse are merging into one trust-exploitation pattern. The same actor can compromise a third-party integration, reuse its privileges, and then move into business systems without triggering traditional perimeter alarms. That convergence weakens controls that are still organised by tool category instead of trust relationship. The practical conclusion is that governance must follow delegation chains across application, identity, and developer planes.

Named concept: delegated trust sprawl. This article shows what happens when organisations accumulate integrations, tokens, and automation paths without a shared lifecycle model. The result is a wide but poorly governed web of machine access that attackers can reuse after one compromise. Practitioners should treat every external connection as part of the identity estate.

The breach pattern validates a control assumption failure that many programmes still make. Teams often assume that access certified at the human level is enough, but the article shows that the real risk sits in the machine path created after the user is gone. A business can have strong login controls and still lose data through delegated access that was never inventoryed or retired. The control gap is lifecycle ownership of non-human access, not just stronger authentication.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Delegated trust sprawl: the hidden risk is no longer only the application that was compromised, but the network of tokens, integrations, and automation paths it can reach. That governance problem will keep widening unless identity teams treat SaaS access as part of the non-human identity estate and review it with the same discipline as service accounts.

The practical signal for programmes is clear: security teams need continuous visibility into OAuth grants, third-party connections, and build-time secret exposure. The trust boundary now sits in the relationship between systems, not just at login, so controls have to follow delegation chains across application and developer environments.

Attackers are increasingly exploiting legitimate channels after initial compromise, which means detection must move from endpoint-only thinking to trust-path monitoring. Integrations, signed code, and automation all need lifecycle ownership, or they remain reusable attack infrastructure.

For practitioners

• Inventory delegated SaaS connections Build a complete register of OAuth apps, third-party integrations, and automation paths that can access production data, then classify them by business owner and scope.
• Shorten token lifetime and scope Limit OAuth scopes to the minimum required functions, revoke unused tokens, and remove integrations that can still operate after the business need has ended.
• Monitor developer environments for secret exposure Inspect build logs, local CLI workflows, and repository hooks for secrets, environment variables, and credential material that attackers can harvest during reconnaissance.
• Validate signed-code trust with behaviour Do not rely on signature validity alone for drivers or other trusted code. Correlate signed loads with unusual process termination, blocklist bypass attempts, and kernel-level changes.
• Exercise cross-SaaS incident response Run response drills that include integration disablement, token revocation, mailbox review, and evidence preservation across connected cloud services.

Key takeaways

• The article’s central warning is that SaaS, supply chain, and OAuth abuse are no longer separate threat stories but one connected trust problem.
• The Salesloft Drift breach and related incidents show how legitimate delegation can be turned into persistent access and large-scale exfiltration.
• Controls that focus only on login or patching will miss the real failure point unless organisations govern tokens, integrations, and developer exposure together.

Key terms

• OAuth Token Abuse: The misuse of valid OAuth access or refresh tokens to gain unauthorized access without repeating the original login. In NHI terms, the token becomes the credential, so the real control problem is issuance, storage, scope, and revocation rather than passwords alone.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity lifecycle control to broader security and access governance.