Topic starter
07/03/2026 1:30 am
TL;DR: SaaS supply chain attacks exploit OAuth tokens, API integrations, and delegated trust in production SaaS, while software supply chain attacks target code, build pipelines, and dependencies. Obsidian Security cites 15% of SaaS breaches as third-party or supply chain related, showing why IAM and NHI governance now need separate controls for code and connection risk.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “SaaS Supply Chain Security vs Software Supply Chain Security: What CISOs Need to Know”.
By the numbers:
- 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.
- Open-source malware detections surged 73% in 2025 compared to the prior year, highlighting escalating risks in the software supply chain.
Key questions
Q: What breaks when SaaS supply chain controls treat OAuth integrations like ordinary app approvals?
A: The trust assumption breaks first.
Q: When should teams prioritise token governance over software supply chain hardening?
A: They should prioritise token governance whenever the primary exposure is production SaaS data, third-party integrations, or connected customer tenants.
Q: What are the signs that a trusted SaaS tool or integration is being misused as an attack path?
A: Warning signs include unusual tool versions, unexpected export activity, abnormal token generation or reuse, and administrative actions that do not match normal approval patterns.
Practitioner guidance
- Map the SaaS trust graph Inventory OAuth grants, API integrations, third-party apps, and the downstream SaaS instances they can reach.
- Separate build and connection controls Use one control set for software supply chain integrity and a different one for SaaS token governance.
- Add behavioural monitoring to integration discovery Track unusual token usage, abnormal data exports, and off-hours API activity for approved apps.
Bottom line: SaaS supply chain security is a trust-governance problem, not just a vendor-risk problem, because OAuth grants and API integrations can become active breach paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/10/2026 6:46 pm
Two supply chains, two governance models: Software supply chain risk and SaaS supply chain risk are related but not interchangeable. Code integrity problems live in build systems and artefacts, while SaaS compromise lives in delegated runtime trust. Teams that collapse both into one programme will miss the controls that actually matter for each domain, so the governance model must separate provenance from authorisation.
A few things that frame the scale:
- 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: How should security teams respond when a trusted SaaS integration is compromised?
A: Start by revoking the compromised token, then inventory every related credential, service principal, API key, and downstream system that the app could reach. After that, review scopes, reissue credentials from trusted environments, and monitor for unusual API activity. The goal is to close the trust chain, not just the first entry point.
👉 Read our full editorial: SaaS supply chain security gaps expose OAuth trust relationships