OWASP NHI3: third-party integration access review

Updated October 5, 2026. The previous version of this article offered hypothetical breaches but no documented case. OWASP NHI3 is more concrete: a vendor application or extension can hold an identity that reaches your systems. If the vendor is compromised, the access you granted may become an attacker’s path into your data.

What NHI3 covers

OWASP includes IDE extensions and SaaS integrations in NHI3:2025. A third-party tool may receive an API key, SSH key, OAuth grant or another credential to do its job. The risk depends on where that credential is held, the permissions and resources it reaches, and whether the organization can see and revoke its use. NHI3 does not mean that every vendor connection is compromised.

A documented case: Salesloft Drift

Google Threat Intelligence Group reported that UNC6395 used compromised OAuth tokens associated with the Salesloft Drift application to export data from Salesforce customer instances between August 8 and at least August 18, 2025. Its later update said Drift Email integration tokens were also compromised and used to access a small number of configured Google Workspace accounts. Salesforce said the issue was with the Drift connection credentials, not a vulnerability in its core platform.

This is the access boundary to inspect: a customer authorizes an integration; the provider holds or uses a credential; the source service accepts requests within that grant. The same provider incident can involve more than one destination, while a customer without a particular integration may have a different exposure. The affected organization still needs its own connection list and source-side logs to determine impact.

Make one integration reviewable

Record the vendor and application, the internal sponsor, the destination service, who approved the connection, the credential or grant type, the permissions and selected resources, where activity is logged, and exactly where access can be suspended or revoked. Keep the revocation owner and a contact at the provider. This is an inventory entry for a real connection, not a claim that a scanner can reconstruct the whole vendor estate.

For example, GitHub lets organization owners review each installed GitHub App’s permissions and repository selection, narrow its repository access, or suspend or remove the installation. A request for all repositories or new write permissions is a review decision, not evidence of compromise. Other SaaS platforms have their own authorization and revocation controls; check them at the source.

If the provider reports a compromise

Start with the specific integrations and tokens that could have been held by that provider. Coordinate with service owners to revoke or replace grants at each issuing service, then test legitimate workflows before restoring access with narrower permissions. Review retained source-side authentication and data-access logs for the relevant period. If exported records contained secondary credentials, identify and rotate those at their issuers too. A revoked integration token does not invalidate secrets that were copied out of accessible data.

Cremit can find credential patterns in configured, supported sources and check supported issuer types. It cannot see a vendor-held OAuth token solely because the vendor has a grant, inventory every external integration, read every SaaS activity log, or revoke a provider’s access. Those tasks belong to the SaaS and integration owners. Source scanning can still help find secondary credentials that were stored in a connected repository or document.