Why do SaaS supply chain attacks keep succeeding even when organisations have vendor review processes?

Why SaaS supply chain attacks keep slipping past vendor review

Vendor review processes are built for governance cadence, not attacker cadence. They can confirm paperwork, security posture, and contractual expectations, but they rarely see the live state of trial tenants, embedded integrations, delegated admin roles, or the token sprawl that accumulates after procurement. That makes the control surface larger than the review surface, especially when the SaaS product sits inside another SaaS product or depends on external identities and API access. A useful external reference on the broader mechanics of machine and non-human access is OWASP Non-Human Identity Top 10.

Organisations often assume a vendor questionnaire proves operational safety, but the real exposure is usually not in the stated controls. It is in the unreviewed paths between procurement, provisioning, and day-to-day use, where access can be created quickly and forgotten just as quickly. In practice, many security teams encounter the abuse only after the vendor review has already been filed away, rather than through intentional oversight of active access.

How the attack path works across SaaS vendors and customers

saas supply chain attacks succeed when an attacker can compromise a less-protected relationship that still has enough trust to reach the target environment. That may be a subcontracted service, a support channel, a browser extension, an OAuth integration, a billing or admin workflow, or a long-lived token granted during onboarding. The attack does not need to defeat the headline vendor’s public posture if it can reach the customer through a trusted edge in the service chain.

Vendor review processes usually focus on static assurances: security attestations, policy documents, and questionnaire responses. Those artifacts matter, but they do not continuously validate who currently has access, what integrations are active, or whether old privileges were removed after a pilot ended. The gap widens when access is granted to speed deployment. Trial apps, temporary admins, and service accounts can become permanent if no one owns their retirement.

• Review may approve a vendor before the integration design is final, leaving the real access model unexamined.
• Access can persist through tokens, API keys, delegated OAuth grants, and partner permissions that outlive the review cycle.
• Attackers often prefer the smallest trusted dependency with the broadest downstream reach.
• The customer side frequently lacks continuous inventory of what third-party access actually exists today.

This is why a vendor can pass governance and still be exploitable in practice. The control answers “Should we trust this supplier?” but the attacker asks “Which trusted route is easiest to abuse right now?” Where organisations have strong joiner-mover-leaver discipline for employees but weak lifecycle control for SaaS integrations, the attacker inherits the imbalance. The guidance breaks down when the environment has no authoritative inventory of active integrations, owners, and tokens.

When vendor review is not enough

Tighter supplier governance often increases review overhead, requiring organisations to balance assurance against the speed at which integrations are created and changed. That trade-off matters because a fully manual review model cannot keep pace with software that is provisioned, connected, and extended in minutes. The question then becomes not whether a vendor passed review, but whether the specific access path remains justified and observable.

There is some industry consensus that questionnaires alone are insufficient for SaaS risk, but less consensus on the exact control stack that closes the gap. In practice, the most reliable signal is whether the organisation can show current ownership, current scope, and current revocation authority for each active integration. If those three elements are missing, the review process is only proving historical diligence, not present-day containment. For a broader threat-model view of how these abuse paths are structured, MITRE ATT&CK Enterprise Matrix is useful for understanding common post-compromise behaviours.

Edge cases matter. A well-governed enterprise SaaS app may still be exposed if a smaller downstream app inherits delegated access from a parent tenant. Conversely, a risky-looking vendor may be harmless if it has no standing privileges, no persistent tokens, and no route to sensitive data. The operational judgment is to assess the actual trust path, not the procurement badge. SaaS supply chain risk becomes materially different once automation, delegated access, or third-party app marketplaces are in play.

Practitioner Guidance

What to prioritise: Treat active access inventory as the control objective, not the vendor questionnaire. The first question is which third parties can still reach production data, admin functions, or user sessions today.

What to verify: Confirm who owns each integration, how it is revoked, and whether the revocation path actually works without waiting for a procurement cycle. If no one can answer that quickly, the organisation does not yet control the exposure.

Decision rule: If the relationship depends on standing tokens, broad delegated permissions, or unclear admin ownership, classify it as a live operational risk rather than a reviewed supplier and escalate accordingly.

What practitioners underestimate: The most dangerous gap is often between “approved” and “currently active.” Review evidence ages quickly, while attacker access can be established and abused within the same business day.

Practitioner takeaway: Vendor review is necessary for governance, but SaaS supply chain resilience depends on continuous control of the actual access paths that survive after the review is complete.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of webhook-driven SaaS supply chain attacks?
• What breaks when organisations rely on package review alone to stop supply chain attacks?
• Why do supply chain, OAuth phishing, and access token attacks keep working against mature organisations?
• Why do SaaS supply chain attacks evade traditional IAM and CASB controls?