SaaS supply chain security gaps expose OAuth trust relationships

At a glance

What this is: This analysis contrasts SaaS supply chain security with software supply chain security and shows that OAuth tokens create a distinct breach path one integration away from core applications.

Why it matters: IAM and NHI practitioners need to govern delegated SaaS access as a separate risk class because token abuse bypasses the controls built for code-centric supply chain threats.

By the numbers:

• Open-source malware detections surged 73% in 2025 compared to the prior year, highlighting escalating risks in the software supply chain.
• 15% of all SaaS breaches now originate from third-party or supply chain compromise, with organizations experiencing an average cost of $4.91 million per breach.
• 86% of organizations treat SaaS security as a high priority, with 76% increasing security budgets to address these blind spots.
• 700+ customer Salesforce instances were accessed through compromised Salesloft SaaS OAuth tokens.

👉 Read Obsidian Security's analysis of SaaS supply chain security vs software supply chain risk

Context

SaaS supply chain risk is what happens when a business grants one application permission to act inside another through OAuth tokens, API integrations, or service accounts. In this article, the primary governance gap is not code integrity but delegated access that can be abused after authorization, which makes the topic directly relevant to NHI governance.

Most security programs are still built around software supply chain assumptions such as dependency scanning, SBOMs, and pipeline hardening. Those controls matter, but they do not see whether an authorized SaaS integration is exporting data, overreaching its scope, or being used after a third party is compromised. That is why SaaS supply chain security needs its own identity-centric control model.

The article’s starting position is typical of the current market: organizations understand software supply chain risk better than SaaS integration risk. The gap is structural, not educational, because the controls and inventories for each domain answer different questions.

Key questions

Q: What is the difference between SaaS supply chain security and software supply chain security?

A: Software supply chain security focuses on code, dependencies, and build systems. SaaS supply chain security focuses on OAuth tokens, API integrations, and third-party apps that already have access to production data. The first problem is code integrity. The second is delegated identity and revocable trust.

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.

Q: When does SaaS supply chain risk become more dangerous than software supply chain risk?

A: It becomes more dangerous when a trusted integration can reach sensitive data across many tenants or business units, because abuse can begin immediately after compromise. The risk grows with broad OAuth scopes, long token lifetimes, weak monitoring, and poor owner accountability for third-party access.

Q: What should security teams monitor to detect SaaS supply chain abuse?

A: Monitor token use, API volume, timing, destinations, and the business context for each integration. Normal-looking application traffic can still be malicious if the access pattern changes, especially for exports, synchronisation jobs, and dormant integrations that suddenly become active.

Technical breakdown

OAuth tokens in SaaS supply chains: where trust becomes access

OAuth turns delegated authorization into reusable access tokens, which means a third-party app can act with the permissions a user or admin granted earlier. In SaaS environments, that delegation often survives long after the original business need changes. The technical problem is not authentication alone, but scope, lifetime, and downstream reach. If an attacker compromises the app or the vendor behind it, the token still functions until it is revoked or expires. Unlike code supply chain attacks, this path does not require tampering with build artifacts. It uses valid identity paths that already exist in production.

Practical implication: Inventory every high-privilege OAuth grant and shorten token lifetime wherever the business process allows.

Why integration inventories miss behavioural abuse

An integration inventory tells you which apps are connected, but not whether their behaviour matches the intended use. That is a static picture of trust relationships, not a live view of identity activity. In practice, a compromised SaaS integration may read, copy, or sync data using legitimate API calls that look normal in logs unless you baseline volume, destination, and timing. This is why SaaS supply chain detection requires behavioural telemetry, not only configuration records. The same limitation applies to service accounts and AI agents that inherit access through trusted connectors.

Practical implication: Correlate app identity, API activity, and data movement so you can detect abuse after authorization.

Patch versus revoke: the response model differs by domain

Software supply chain incidents usually require patching, rebuilding, and redeploying software, because the compromise sits in code or the build path. SaaS supply chain incidents usually demand immediate revocation of OAuth tokens, disconnecting integrations, and isolating affected tenants or workspaces. The architectural difference matters because a valid token can keep working even when the source vendor is already compromised. That means response speed depends on your ability to identify every dependent integration and every place that token is used. In NHI terms, the control is revocation, not remediation through software release.

Practical implication: Build a revoke-first playbook for SaaS integrations and test it before a breach forces the decision.

Threat narrative

Attacker objective: The attacker wants to turn a trusted integration into broad, low-friction access across multiple customer SaaS environments.

1. Entry occurs when attackers compromise a third-party SaaS environment and inherit already-authorized OAuth access into downstream customer tenants.
2. Escalation happens when the attacker uses valid tokens and API permissions to enumerate connected data and expand from one integration into multiple SaaS environments.
3. Impact occurs when sensitive records are exported or manipulated at scale, often before defenders can distinguish the traffic from legitimate application activity.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The SaaS supply chain is now an identity problem, not just a vendor risk problem. When access is delegated through OAuth and API connections, the control plane becomes identity-centric even if the application feels operational rather than security-related. That means security leaders should stop treating SaaS supply chain exposure as a procurement issue alone. The practical conclusion is that NHI governance must cover every trusted connection that can act on data.

Software supply chain tools do not solve SaaS supply chain exposure. SBOMs, SCA, and build integrity controls answer a code provenance question, not a runtime trust question. SaaS breaches are different because the malicious action often uses legitimate tokens and ordinary API paths. Practitioners need separate control objectives for code integrity and delegated SaaS access, or they will keep missing the real attack surface.

Identity blast radius is the right concept for SaaS integration risk. A single compromised integration can inherit the privileges, data access, and workflow reach of many downstream tenants or business units. That blast radius is governed by scope, token lifetime, and monitoring depth, not by source code review. The practitioner conclusion is simple: reduce what each integration can touch before you need to explain what it touched.

Continuous review of non-human access must include business context. An OAuth token with legitimate scope can still be dangerous if the application no longer needs that access or if the integration is stale, overbroad, or unmanaged. Security teams should align access review with actual service usage rather than static approval records. The practical result is cleaner NHI governance and fewer hidden trust relationships.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to Guide to the Secret Sprawl Challenge.
• 28% of secrets incidents now originate outside code repositories in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
• A related control gap appears in MCP adoption, where 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.

What this signals

Identity blast radius will become the dominant metric for SaaS governance. The question is no longer only how many integrations exist, but how far each one can move once compromised. Programs that cannot bound delegated access will keep inheriting risk from every vendor and workflow connected to core SaaS data.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, protocol adoption is already creating new identity exposure patterns that mirror the SaaS integration problem, according to The State of Secrets Sprawl 2026. Teams should expect tool sprawl, not just user sprawl, to drive next-year review backlogs.

The practical next step is to align SaaS access review, service-account review, and AI agent governance into one lifecycle process. If those reviews stay separate, attackers will keep finding the gaps between them.

For practitioners

• Map all delegated SaaS access paths Inventory OAuth grants, API integrations, service accounts, and third-party apps across every SaaS tenant. Classify each connection by data sensitivity, privilege level, and business owner so revocation decisions can be made quickly when one integration is compromised.
• Baseline integration behaviour before an incident Monitor normal token use, API volume, timing, and destination patterns for each high-risk integration. Behavioural baselines help distinguish routine sync activity from unusual export patterns that indicate abuse after authorization.
• Build a revoke-first incident runbook Pre-approve the steps for disabling integrations, revoking refresh tokens, rotating secrets, and notifying app owners. A SaaS supply chain incident should not wait for a patch cycle because access is already live.
• Separate software and SaaS supply chain controls Keep SBOM and build-security workstreams, but add a distinct SaaS governance track for OAuth consent, third-party app review, and runtime monitoring. The two domains share a trust theme, but they fail in different ways.

Key takeaways

• SaaS supply chain security is an NHI governance problem because trusted integrations can become active breach paths without touching code.
• The scale of the issue is already measurable, with 15% of SaaS breaches tied to third-party or supply chain compromise and millions in average breach cost.
• Security teams should separate code supply chain controls from SaaS revocation and behavioural monitoring, or they will miss the attack class that token abuse creates.

Key terms

• SaaS Supply Chain Security: SaaS supply chain security is the practice of governing the trusted connections between cloud applications. It focuses on OAuth tokens, API integrations, third-party apps, and service accounts that can move data without changing code. The main concern is delegated access that outlives the original approval.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and workflows a non-human identity can reach if it is compromised. In SaaS environments, it is shaped by token scope, integration depth, and data permissions. Smaller blast radius means less attacker leverage after a single credential or app compromise.
• Delegated Trust: Delegated trust is access that one system or app receives because another identity approved it earlier. In SaaS and agentic environments, it is often implemented through OAuth consent or API grants. The security problem is that delegation can remain valid long after business need changes, creating hidden exposure.

Deepen your knowledge

SaaS supply chain security and delegated access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for OAuth, integrations, or service accounts, it is worth exploring.

This post draws on content published by Obsidian Security: SaaS Supply Chain Security vs Software Supply Chain Security. Read the original.