SaaS supply chain risk is hiding in OAuth and API integrations

At a glance

What this is: This is a guide to SaaS supply chain security that distinguishes SBOM, VRM, CI/CD, and SaaS integration risk management, with the central finding that hidden OAuth and API connections create the most overlooked exposure.

Why it matters: IAM and NHI teams need to treat SaaS-to-SaaS integrations as governable identities and permissions, because the attack path often lives in the connection layer rather than the application boundary.

By the numbers:

• 15% of all SaaS breaches originate from a third-party or supply chain compromise, with an average cost of $4.91 million per breach.
• Our research found that SaaS to SaaS data moves 10x faster than human to SaaS.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Obsidian Security's guide to SaaS supply chain security and integration risk

Context

SaaS supply chain security is the discipline of controlling the hidden connections between cloud applications, especially OAuth permissions, API integrations, automations, and add-ons. In IAM terms, those connections behave like non-human identities with delegated authority, yet many organizations still govern them as if they were low-risk app features rather than access pathways.

The article’s central claim is that vendor posture tools only describe part of the risk picture. The operational exposure sits inside the connection layer, where integrations can be created quickly, privileges accumulate quietly, and shadow SaaS expands the attack surface faster than security reviews can catch up.

That is a typical starting position for SaaS-heavy organisations. Security teams often have inventory of vendors and applications, but not of the permissions and data flows created between them, which is where this category now concentrates risk.

Key questions

Q: How should security teams govern SaaS-to-SaaS integrations as NHI risk?

A: Security teams should treat every SaaS integration as a non-human identity with an owner, a scope, a lifecycle, and a revocation path. The practical goal is to know what each connection can access, how long it remains valid, and whether it still has a business need. Without that discipline, delegated access becomes permanent by accident.

Q: What is the difference between vendor risk management and integration risk management?

A: Vendor risk management evaluates the external posture of a third party, while integration risk management evaluates the live permissions and data flows between SaaS applications. The first is useful for procurement and assurance. The second is what exposes hidden access paths, because a secure-looking vendor can still have a dangerous connector inside your environment.

Q: When does an OAuth integration become a privileged access risk?

A: An OAuth integration becomes privileged access risk when its scopes let it read sensitive records, create downstream actions, or mint additional access without tight oversight. Long-lived tokens with broad permissions behave like standing privilege. The key test is not whether the integration is approved, but whether its access is narrow, time-bound, and revocable.

Q: Why do SaaS supply chain incidents spread beyond the first compromised app?

A: They spread because trusted integrations connect multiple systems that already share credentials, data, or automation rights. Once attackers control one delegated connection, they can often move through legitimate paths rather than breaking new defenses. That makes the blast radius a function of integration density as much as of the original compromise.

Technical breakdown

Why SaaS-to-SaaS integrations behave like non-human identities

An OAuth token or API grant is not just a technical link. It is delegated authority that allows one service to act on behalf of another, often with broad read, write, or administrative scope. In practice, that makes each integration a non-human identity with its own lifecycle, permissions, and blast radius. The weakness is that these privileges are frequently long-lived, hard to enumerate, and invisible to tools focused on endpoint, email, or infrastructure controls. Once an employee creates an integration, the business often treats it as harmless automation even when it can access sensitive SaaS data across multiple systems.

Practical implication: Treat every active SaaS integration as an identity that needs ownership, scope review, and revocation paths.

Why VRM, SBOM, and CI/CD controls only cover part of the attack surface

VRM tells you something about the outside of a vendor. SBOM tells you what components exist in software. CI/CD integrity tells you whether the build pipeline was tampered with. Those controls matter, but they do not answer the core SaaS question: which third-party connections can move data or privileges across applications today? That gap explains why organizations can have strong procurement checks and still miss a compromised OAuth token or an overprivileged connector. The control plane for SaaS supply chain risk is not the vendor record, the build artifact, or the component list. It is the live permission graph between applications.

Practical implication: Add integration inventory and permission graph reviews to existing third-party risk and software integrity processes.

How blast radius grows in shadow SaaS environments

Shadow SaaS expands when users connect applications without formal review, and every new connection can inherit the trust of the source account. Because SaaS systems exchange data continuously, a single compromised integration can become a pivot point into CRM records, cloud credentials, or downstream automations. That is why attackers value these paths: they bypass hardened perimeters and inherit legitimate access. The problem is not simply unauthorized software. It is unmanaged delegated access that persists after the original business need has changed, leaving stale permissions available for abuse.

Practical implication: Establish recurring reviews for stale integrations, overprivileged scopes, and orphaned automations.

Threat narrative

Attacker objective: The attacker’s objective is to turn one compromised integration into broad, downstream access across customer environments and sensitive SaaS data.

1. Entry occurs when attackers compromise a SaaS-to-SaaS integration or its OAuth tokens and use that delegated access to enter a trusted application.
2. Escalation follows when the compromised integration exposes downstream SaaS environments, allowing the attacker to export contacts, credentials, or other sensitive data.
3. Impact appears as cascading compromise across multiple business systems, with the original breach multiplying into a broader third-party incident.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Integration risk management is becoming the missing control layer in SaaS governance. Traditional vendor assessments still matter, but they do not govern the live access relationships that actually move data between applications. The relevant security unit is no longer just the vendor or the app, but the OAuth grant, the API connection, and the automation behind it. Practitioners should treat those connections as first-class identities with owners and review cycles.

Shadow SaaS creates identity sprawl faster than most IAM programmes can absorb. Employees can create integrations in minutes, while inventory, review, and revocation processes often run on monthly or quarterly cycles. That time mismatch creates trust debt, because business convenience outpaces governance. Security teams need to assume that unmanaged integrations already exist and build discovery around that assumption.

OAuth scope is now a privileged access problem, not a convenience setting. Broad delegated scopes can expose records, files, mailboxes, and cloud credentials without requiring a separate login. That makes overprivileged integrations functionally similar to standing privileged accounts, especially when tokens remain valid long after business need changes. Least privilege must extend into SaaS connection design, not stop at human access controls.

Blast radius, not just exposure, should drive SaaS supply chain priorities. A single compromised connection can reach multiple tenants, multiple systems, and multiple data classes if the integration graph is dense enough. That changes the practical question from whether a vendor is risky to how far a trusted integration can propagate. NHI governance should therefore measure downstream reach, not only source-side hygiene.

Identity lifecycle controls need to cover machine-to-machine permissions in SaaS ecosystems. Provisioning, periodic review, rotation, and offboarding are not only for human access or cloud service accounts. They are equally relevant to OAuth grants, app credentials, and connector permissions that remain active after the original workflow is obsolete. Teams that close that lifecycle gap will reduce the largest unmanaged part of SaaS risk.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For adjacent NHI exposure patterns, see The 52 NHI breaches Report for breach roots, then pair it with integration review and revocation planning.

What this signals

Ephemeral integration access is creating trust debt. Security teams are approving SaaS connections faster than they can review, rotate, or retire them, which means delegated access accumulates quietly in the background. The result is a governance gap between business enablement and actual control, and that gap widens as shadow SaaS adoption grows. Teams should move to continuous discovery and lifecycle review for connectors rather than relying on periodic vendor assessments.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, the operational lesson is clear: discovery without revocation leaves the organisation exposed. That same logic applies to SaaS integrations, where stale scopes and orphaned automations remain active long after their business justification has expired. The next control maturity step is to measure how quickly a team can find, classify, and disable risky connections.

Practitioners should align SaaS integration governance with the OWASP Non-Human Identity Top 10 and the NHI lifecycle model, then test whether their programme can answer three questions in real time: who owns the connection, what data can it reach, and how fast can it be turned off. For broader NHI threat patterns, the 52 NHI Breaches Analysis remains a useful reference point for root-cause thinking.

For practitioners

• Map every SaaS-to-SaaS connection Build an inventory of OAuth grants, API integrations, automations, and add-ons across core SaaS platforms. Include owner, scope, data access, and last use date so the organisation can identify shadow connections and orphaned permissions.
• Classify integrations by privilege and data reach Assign risk tiers based on the data each connection can read or write, whether it can create new tokens, and whether it can trigger downstream actions. Use the result to prioritise revocation reviews for the highest-blast-radius connections.
• Add revocation playbooks for compromised tokens Predefine who can disable an integration, how fast tokens are revoked, and which business teams must validate service impact. Fast containment matters because SaaS compromise often spreads through legitimate delegated access.
• Integrate SaaS permissions into access review cycles Extend periodic access reviews beyond human accounts to service connections and automations. Reconfirm business need, scope, and ownership for the integrations that hold access to CRM, cloud, and collaboration data.
• Correlate integration telemetry with threat signals Monitor unusual cross-app activity, unexpected scope expansion, and abnormal token use alongside threat intelligence and incident alerts. This is the control layer that can reveal a compromised integration before it becomes a cascading breach.

Key takeaways

• SaaS supply chain risk concentrates in the connection layer, where OAuth grants and API integrations behave like non-human identities with delegated authority.
• Traditional VRM, SBOM, and CI/CD controls are necessary but incomplete because they miss live permissions, data flows, and shadow integrations.
• The practical response is continuous discovery, scoped access, and fast revocation for every active SaaS connection that can move sensitive data.

Key terms

• SaaS-to-SaaS Integration: A SaaS-to-SaaS integration is a connection that lets one cloud application access another through OAuth, API tokens, webhooks, or automation. In security terms, it is a delegated access relationship with its own scope, lifecycle, and blast radius, not just a convenience feature for users.
• Shadow SaaS: Shadow SaaS is any cloud application or integration that exists outside formal security oversight. It often appears when users connect tools themselves, creating hidden permissions and data flows that bypass normal inventory, review, and revocation processes.
• Integration Risk Management: Integration risk management is the discipline of discovering, classifying, monitoring, and removing risky SaaS connections. It focuses on the permissions and data flows between applications, which often matter more than the vendor’s public-facing posture when attackers exploit delegated access.
• OAuth Scope: OAuth scope is the set of permissions an application receives when it is authorized to act on a user’s or service’s behalf. Broad scopes can expose data and trigger actions across systems, so they should be treated as privileged access, not as a default technical setting.

Deepen your knowledge

SaaS supply chain security and non-human identity 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 grants, API integrations, and shadow SaaS from the same starting point, it is worth exploring.

This post draws on content published by Obsidian Security: Understanding every layer of your SaaS supply chain security. Read the original.