The Configuration Supply Chain Nobody’s Mapping
- How Configuration Risk Became Transitive
- The Ghost Integration Problem
- Why Traditional Security Models Miss This
- The Shift Required: From App-Centric to Ecosystem-Centric
- What Managing Configuration Dependencies Actually Requires
- The Mental Model Barrier
- What Comes Next
- The Role of SaaS Security Posture Management
- Sources and Further Reading
Every SaaS application in your environment now inherits risk from somewhere else.
Take the OAuth app connecting your CRM to your marketing platform, or the browser extension your sales team installed last quarter to streamline their outreach. Each one creates a dependency chain that most security teams have never systematically mapped.
This is the configuration supply chain, and most security teams have no inventory of it.
How Configuration Risk Became Transitive
When 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.
Unlike a compromised user account, the risk doesn’t stay contained to a single system.
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 Problem
Most 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 This
Your 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-Centric
Most 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 damage done 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 Requires
Organizations 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, integrations come up the same way users and vendors do. Who owns it? What data does it touch? How far does the damage reach if it’s compromised? When’s the next review?
There’s a live dashboard that can answer those questions in seconds instead of ad-hoc digging across siloed app admins.
Getting there requires a few structural shifts that most teams haven’t made yet.
Ownership is the obvious starting point. Someone has to be explicitly accountable for app-to-app risk across all systems, not just within one platform. In practice, this tends to be a shared mandate between security and a central SaaS platform team, but the key is that it’s named, not assumed.
From there, you need visibility into the actual shape of your integration environment. That means a live inventory showing not just what’s connected, but what data each integration touches, which systems it links, and how much damage a compromise would propagate. The teams that have done this work often describe it as the first time they could actually see their environment.
Finally, integrations need the same lifecycle discipline as human accounts. Approval workflows, assigned owners, periodic re-certification, and a clean offboarding process when a connector is retired. None of this is especially complicated, but it has to be deliberate — it won’t happen as a byproduct of managing apps in isolation.
The Mental Model Barrier
Most security leaders genuinely believe they’ve addressed SaaS risk once SSO, MFA, and a CASB are in place. The problem is that none of those controls were designed with integrations in mind.
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 Next
Configuration 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 by building the graph, assigning ownership, and treating every new integration request like onboarding a privileged employee.
Security teams that have been organized around individual applications are going to find this uncomfortable. The Salesforce admin, Google Workspace admin, and Okta admin each own a piece of the picture. But the attack paths that matter most now run between those pieces, and someone needs to own the seams.
Because configuration risk is transitive, and one bad integration weakens multiple systems.
A useful first test: pull a list of every OAuth app and marketplace integration currently active in your environment. Check how many have an owner who still works at the company. Check how many were installed by someone who left six months ago.
Most teams that run this exercise for the first time are surprised to find the gap in their coverage.
Mapping the configuration supply chain isn’t a one-time project, though. It’s an ongoing commitment to treating integrations with the same rigor as the human identities they sit alongside.
The Role of SaaS Security Posture Management
If you’re ready to address these issues effectively, you can also leverage an automated tool that will monitor your configurations, flag and manage changes, and assess risk for all OAuth apps integrated to your mission critical SaaS. The truth is that managing these tasks in an ongoing way is too time consuming for most teams to handle manually and can be addressed by a SaaS security posture management solution that provides continuous monitoring, app risk assessment, and remediation.
Sources and Further Reading
Recent Security Incidents
- CSO Online: OAuth Token Compromise Hits Salesforce Ecosystem Again, Gainsight Impacted
- SISA InfoSec: Salesforce OAuth Breach
- The Hacker News: SaaS Breaches Start with Tokens: What You Need to Know
Orphaned Access and Ghost Integrations
- Torii: Orphaned Access in SaaS
- CyberArk: Digital Ghosts: How to Find and Fix Orphaned Accounts Before Attackers Do
- The Hacker News: Who’s Really Using Your SaaS? The Rise of Non-Human Identities
OAuth Token Security
Spin.AI Resources
- Spin.AI: Why Integration Attacks Succeed Despite Security Investments
- Spin.AI: SaaS Application Security Risk Assessment and Modeling
- Spin.AI: SaaS Misconfigurations: Silent Security Threat
- Spin.AI: Multi-SaaS Security That Works
- Spin.AI: Risk Assessment for Apps & Extensions
- Spin.AI: SaaS Application Risk Report
- Spin.AI: SaaS Application Risk Report (PDF)
