Why do third-party integrations create so much exposure in modern supply chains?

Why Third-Party Integrations Create So Much Exposure

Third-party integrations are risky because they turn one approval into many inherited trust relationships. A vendor app, plugin, package, or API connector can gain access to source code, data stores, CI/CD runners, chat tools, and secrets vaults without being governed like a human user. Once that trust is granted, it is often left in place long after the original business need changes.

NHIMG’s analysis of real-world incidents shows how quickly this becomes systemic. In the 52 NHI Breaches Analysis, credential misuse and over-permissioned machine identities repeatedly appear as breach accelerants, especially where integration scope was never revalidated. That pattern matters because integrations rarely fail in isolation. They fail as trust chains, where one compromised token can unlock downstream access that no single team fully owns.

The operational problem is not just “too many vendors.” It is that security teams often approve access at onboarding but do not continuously reassess what the integration can actually reach. In practice, many security teams encounter lateral movement through a trusted integration only after sensitive data has already been accessed, rather than through intentional access review.

How Integrations Expand the Attack Surface in Practice

Modern supply chains are built on machine-to-machine trust. A third-party service may authenticate with OAuth, API keys, service accounts, webhook signatures, or short-lived tokens, then operate across multiple internal systems. If those credentials are broad, static, or poorly scoped, the integration becomes a durable bridge into environments that were never meant to be exposed together.

The exposure increases when secrets are embedded in code, configuration files, chat threads, or build pipelines. NHIMG has documented this pattern in incidents such as the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens and the Shai Hulud npm malware campaign, where trusted automation paths became secret exfiltration paths. GitGuardian and CyberArk report that organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, and that the average time to remediate a leaked secret is 27 days. That gap gives attackers time to pivot before defenders revoke access.

• Inventory every integration and map its actual data reach, not just its approved purpose.
• Scope tokens to a single function, environment, or tenant wherever the platform allows it.
• Prefer short-lived credentials and automated revocation over shared static secrets.
• Log and review non-human access separately from human user activity.

Current guidance suggests that continuous validation should be treated as a control, not a monitoring extra. The OWASP Non-Human Identity Top 10 and NHI breach research both point to the same operational failure: integrations are commonly trusted more broadly than their actual business function requires. These controls tend to break down in fast-moving CI/CD environments because access is granted by automation faster than it can be reviewed by humans.

Where the Standard Answer Breaks Down

Tighter integration control often increases operational overhead, requiring organisations to balance velocity against assurance. That tradeoff becomes visible when product teams depend on dozens of SaaS connectors, AI tools, and build-time plugins that change weekly. In those environments, full manual review is rarely realistic, so best practice is evolving toward policy-based approval, periodic re-certification, and runtime detection rather than one-time trust decisions.

There is no universal standard for this yet, especially for agentic tools that chain actions across multiple services. The most mature organisations treat each integration as a non-human identity with its own lifecycle, owner, and rollback path. They also assume compromise is possible and design for blast-radius reduction, not perfect prevention. That mindset aligns with the Klue OAuth Supply Chain Breach and the Vercel Context.ai OAuth Supply Chain Breach, where one integration decision created broad downstream exposure.

For organisations using AI-assisted workflows, the risk compounds further because tools may request new permissions dynamically. Anthropic’s report on the first AI-orchestrated cyber espionage campaign shows why autonomous tooling changes the threat model: once a system can decide what to call next, static access assumptions stop being reliable. The safest posture is to assume every third-party integration is a potential trust boundary, not a convenience feature.

Related resources from NHI Mgmt Group

• Why do software supply chains create so much exposure in modern application environments?
• Why do third-party and service identities create so much PHI exposure risk?
• Why do trusted third-party updates create such a dangerous failure mode in software supply chains?
• Why do third-party integrations create access control and governance challenges in modern applications?