Every SaaS application in your environment now inherits risk from somewhere else.The OAuth app connecting your CRM to your marketing platform. The marketplace plugin syncing data to your analytics tool. The browser extension your sales team installed to streamline workflows. Each one creates a dependency chain that most security teams have never systematically mapped.We call this the configuration supply chain. And it’s growing faster than anyone’s tracking it.How Configuration Risk Became TransitiveWhen you approve a third-party integration, you’re not just adding a feature. You’re creating a privileged identity with its own data flows.That integration gets a long-lived token. It can read files, access email, manage calendars. It sits in the middle of critical workflows across CRM, collaboration tools, and support systems.Here’s what makes this different from traditional security models: the risk doesn’t stay contained.A single compromised OAuth app can access multiple core systems simultaneously. Because it’s using legitimate integrations and valid tokens, it bypasses the controls designed to catch suspicious human logins. The activity looks like normal app-to-app sync traffic.In August 2025, attackers exploited the Salesloft-Drift OAuth integration to compromise over 700 organizations’ Salesforce instances. One integration. Hundreds of downstream organizations affected.That’s transitive risk at scale.The Ghost Integration ProblemMost organizations discover the scope of this problem during their first full integration audit.You run discovery across your major SaaS platforms. Suddenly you see hundreds of third-party apps and tokens where the installing user is disabled, the project is long dead, but access is still live with broad read/write permissions.These are ghost integrations. They persist because no one treats them like accounts that need lifecycle governance.When an employee leaves, HR triggers offboarding and IAM disables the user. But the OAuth app or marketplace plugin they installed? It’s not automatically removed. The token remains valid against the SaaS APIs, still holding the original scopes.The integration has no active human owner in your directory, but it’s still an authorized client with privileged access to data.Studies estimate organizations waste up to 30% of SaaS spend on unused seats and integrations. But the security cost is harder to quantify. Each orphaned integration extends your attack surface well beyond the life of the employee’s actual account.Why Traditional Security Models Miss ThisYour security stack is optimized to detect weird logins. New devices, geolocation anomalies, impossible travel, MFA fatigue. The detection logic assumes threat equals person doing something unusual at sign-in.But integrations don’t trigger those alarms.Once an OAuth app is approved and its token is issued, its API calls originate from known IPs, use TLS, hit documented endpoints, and follow regular schedules. This is exactly the pattern most tools consider low-risk system activity.The integration already sits on a high-trust allowlist. Sanctioned SaaS talking to sanctioned SaaS over official APIs with valid tokens. There’s no perimeter crossing to flag. No user session to score as anomalous.Security stacks rarely model non-human identities or app-to-app relationships as first-class entities. They don’t build attack paths across those trusted connections.When an integration starts pulling more data, touching new objects, or fanning out to additional systems, it’s treated as business-as-usual sync rather than lateral movement.The Shift Required: From App-Centric to Ecosystem-CentricMost security teams are still organized around protecting individual applications. You have a Salesforce admin, a Google Workspace admin, separate tools for each.This structure creates ownership gaps.Each admin only sees their side. The Salesforce admin sees an app with scopes in Salesforce. The Google Workspace admin sees a different connector there. But no one is chartered to own the combined behavior of that integration across both.When you ask who is responsible for the blast radius if this connector is compromised across CRM, marketing, support, and storage, the answer is usually unclear.Risk assessments stay per-app. Each team rates an integration in isolation. A central hub connector can look low-risk in every individual tool while its combined attack path is extremely dangerous.The fix requires treating your SaaS environment as a graph of identities and connections, not a flat list of apps.Every OAuth app, marketplace plugin, and automation becomes its own identity node with edges to the SaaS tenants, data domains, and user groups it touches. You track scopes, data volume, object types, and call patterns along those edges.Risk assessment changes. You stop asking only “is this app risky in isolation?” and start asking “if this app is compromised, how many systems and datasets does that risk propagate to?”Blast radius and centrality become core risk factors alongside permissions.What Managing Configuration Dependencies Actually RequiresOrganizations that have made this shift treat integrations like privileged employees.When someone wants to add a marketplace app or OAuth connector, there’s a clear path. It gets discovered automatically, routed to an identified owner, scoped and risk-scored against the integration graph, and either approved with constraints or rejected.That decision is traceable later.In meetings, people talk about integrations the same way they talk about users and vendors. Who owns it? What systems and data does it touch? What’s its blast radius if it’s compromised? When’s its next recertification?There’s a live dashboard that can answer those questions in seconds instead of ad-hoc digging across siloed app admins.This requires three structural changes:Establish a clear owner for non-human identities. Usually a joint mandate between security and a central SaaS platform team that is explicitly accountable for app-to-app risk across all systems.Build and maintain an integration graph. A live inventory of every OAuth app, plugin, and automation, showing what data it touches, which systems it connects, and its blast radius and centrality scores.Standardize lifecycle playbooks. Approval, owner assignment, periodic re-certification, and structured offboarding for integrations, just like you do for human accounts and critical services.The Mental Model BarrierThe core barrier isn’t technical. It’s conceptual.The whole industry was trained to see apps as functionality and identities as users. Integrations live in a blind spot between the two.Most standards, audits, and tooling evolved around securing tenants and human accounts. Security leaders feel they’re covering SaaS once each major app has SSO, MFA, and basic posture checks.Integrations are treated as a UX convenience, not a new identity class.App stores and OAuth flows are designed for frictionless adoption. Click to connect. Traditional SaaS management tools often stop at simple discovery, without mapping scopes, app-to-app relationships, or non-human identities.The real risk never becomes visible enough to force an operating model change.Without a strong external push (breach, audit finding, or explicit SaaS supply chain requirements), it’s hard to justify reorganizing around a threat surface that isn’t yet quantified in dashboards or frameworks.As long as integrations don’t show up as first-class objects in org charts, policies, and risk reports, they default to being “just plugins.”Even though, in practice, they behave like high-privilege, long-lived identities woven through the entire SaaS stack.What Comes NextConfiguration supply chains will keep growing. More integrations, more marketplace apps, more AI agents moving data between systems.The organizations that get ahead of this are the ones mapping these dependencies now. Building the graph. Assigning ownership. Treating every new integration request like onboarding a privileged employee.The shift from app-centric to ecosystem-centric security isn’t optional anymore. It’s the logical next phase of SaaS security maturity.Because configuration risk is transitive. And one bad integration weakens multiple systems.Start by asking: do you know every OAuth app and integration currently active in your environment? Do you know who owns each one? Do you know what happens to them when the installing user leaves?If the answer is no, you’re not alone. But you’re also not protected.Map the configuration supply chain. Treat integrations as identities. Manage dependencies, not isolated apps.That’s where SaaS security is heading.Sources and Further ReadingSaaS Security and OAuth RisksObsidian Security: The New Attack Surface: OAuth Token AbuseObsidian Security: SaaS Attack Techniques Threat ActorsObsidian Security: OAuth Phishing Threat: Exploiting SaaS Integration PlatformsObsidian Security: A Guide to SaaS Supply Chain SolutionsObsidian Security: SaaS Supply Chain Security vs. Software Supply ChainRecent Security IncidentsCSO Online: OAuth Token Compromise Hits Salesforce Ecosystem Again, Gainsight ImpactedSISA InfoSec: Salesforce OAuth BreachThe Hacker News: SaaS Breaches Start with Tokens: What You Need to KnowGrip Security: SaaS Breach Surge: Attack PatternsOrphaned Access and Ghost IntegrationsTorii: Orphaned Access in SaaSCyberArk: Digital Ghosts: How to Find and Fix Orphaned Accounts Before Attackers DoThe Hacker News: Who’s Really Using Your SaaS? The Rise of Non-Human IdentitiesOAuth Token SecurityAppOmni: OAuth Token Security RisksMicrosoft Tech Community: Protect SaaS Apps from OAuth ThreatsSaaS Security StrategyAppOmni: Why Your SaaS Security Strategy Is Incomplete Without SSPMReco: The Hidden Risk Inside Your SaaS Stack: How SaaS-to-SaaS Connections Expose Sensitive DataDarktrace: Top Eight Threats to SaaS Security and How to Combat ThemSpin.AI ResourcesSpin.AI: Why Integration Attacks Succeed Despite Security InvestmentsSpin.AI: SaaS Application Security Risk Assessment and ModelingSpin.AI: SaaS Misconfigurations: Silent Security ThreatSpin.AI: Multi-SaaS Security That WorksSpin.AI: Risk Assessment for Apps & ExtensionsSpin.AI: SaaS Application Risk ReportSpin.AI: SaaS Application Risk Report (PDF) Share this article Share this post on Linkedin Share this post on X Share this post on Facebook Share this post on Reddit Was this helpful? Yes No What was missing / how can we improve? Submit Cancel