Topic starter
16/01/2026 3:31 pm
TL;DR: SaaS supply chain attacks exploit OAuth tokens, API keys, service accounts, and shadow integrations to move through trusted SaaS links, and Obsidian Security says integration counts rose 123% while AI agents rose 223%. The governance gap is no longer perimeter defense but continuous control over non-human identities and inherited trust.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “The rise of SaaS Supply Chain attacks: Why you aren’t safe from the next Salesloft-Drift attack”.
By the numbers:
- The number of SaaS integrations and AI agents created have increased by 123% and 223% respectively, according to Obsidian Security.
Key questions
Q: What breaks when a third-party SaaS integration is compromised in a CRM environment?
A: A compromised integration can bypass normal user controls and give an attacker direct access to data stored in the connected tenant.
Q: Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?
A: A compromised integration can inherit trusted access and reach many downstream tenants without re-authenticating each one.
Q: How can security teams tell whether delegated SaaS access is over-extended?
A: Look for integrations that can reach more data, more functions or more systems than their business purpose requires.
Practitioner guidance
- Map delegated SaaS trust relationships Build an inventory of OAuth grants, API keys, service accounts and automated workflows, then link each one to the apps, vendors and data it can reach.
- Review effective permissions, not just app approvals Check inherited roles and default scopes for each integration to find access that exceeds the stated business function.
- Create lifecycle ownership for non-human identities Assign an owner for installation, scope changes, renewal, revocation and offboarding so each credential has a named governance path.
Bottom line: SaaS supply chain attacks work because trusted integrations can be abused without breaking each target system individually.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
08/10/2026 4:52 pm
Inherited trust is the core governance failure in SaaS supply chain attacks. The article shows that the security problem is not isolated credential theft, but the way OAuth grants, service accounts and API keys extend trust across systems without continuous re-justification. That makes the supply chain itself the control plane, which is exactly where identity governance is weakest. Practitioners should treat every delegated SaaS relationship as an active governance object, not a static configuration.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own the risk when a SaaS integration is compromised?
A: Ownership should sit with the team that approved the integration and the business function that depends on it, not just with security operations. They must be able to answer who can revoke the token, how scope is reviewed, and when access expires. Without explicit ownership, connected-app risk becomes everyone’s problem and nobody’s responsibility.
👉 Read our full editorial: SaaS supply chain attacks are exposing NHI governance gaps