Your security team approved an OAuth app six months ago. The publisher's domain is now parked. The app still has read access to your company's Google Drive.
This isn't a hypothetical. An OhAuth audit of Google Workspace and GitHub Marketplaces found 206 apps with dead publisher domains—89 of those domains available for purchase. The question facing security teams: Should you rely on marketplace verification processes, or build your own continuous monitoring layer?
Trusting Marketplace Verification
The argument for trusting marketplace verification is straightforward: Google and GitHub have dedicated security teams that vet apps. They verify publisher identity, review requested permissions against app functionality, and remove apps that violate policies.
For security teams with limited resources, this verification offers a baseline protection you don't have to build yourself. Your security engineer can focus on internal controls instead of auditing every third-party integration. The approval process also creates a documented trail for auditors when addressing third-party risk management.
Marketplace operators have a vested interest in maintaining trust. A breach traced to a malicious marketplace app damages their platform. They invest in automated scanning, abuse detection, and publisher verification because their business model depends on it.
In practice, most security teams can't audit every OAuth integration deeply. A developer needs a Slack integration to post build notifications. You review the permissions (post messages, read channel names), confirm it's verified, and approve it. Building custom integrations for every tool isn't feasible.
The Need for Continuous Monitoring
The OhAuth audit reveals why one-time verification is insufficient. Of the apps examined, 918 (32 percent) had at least one structural exposure signal. Marketplace verification doesn't adapt to changing circumstances.
Consider permission creep: 677 apps request at least one permission exceeding their stated function. An app marketed as a "meeting scheduler" requests full Gmail access. Marketplace verification caught the technical implementation but missed the functional mismatch. Your team approved it based on the description, not the actual permission scope.
Dead publisher domains create another risk. The marketplace verified the publisher when they submitted the app. Two years later, the startup folds. The domain expires. A malicious actor buys it, now controlling the email addresses associated with the OAuth app. They can't push updates through the marketplace, but they can potentially access support channels, reset passwords, or social engineer users who contact the "publisher."
The audit found these 89 purchasable domains represent apps with a combined footprint of 1.82 billion potential exposures. Even a fraction of that represents substantial risk.
Continuous monitoring addresses what verification can't: ongoing changes in risk posture. You track when publisher domains go offline. You flag when an app's actual permissions diverge from its stated purpose. You detect when an app hasn't been updated in 18 months while the underlying APIs have changed three times.
Practical Approaches
Most security teams operate in the middle. You don't ignore marketplace verification, but you don't trust it completely.
A baseline approach: Require apps to be marketplace-verified AND implement quarterly access reviews. Your identity team exports all active OAuth grants. Security reviews the list for unfamiliar apps, excessive permissions, or apps your team doesn't remember approving. You revoke anything that can't be justified.
More mature programs add automated monitoring. You integrate with your identity provider's API to track OAuth grants in real-time. When a new app requests permissions, your security tool checks: Is the domain active? When was the app last updated? Do the requested scopes match similar apps in this category? You're not re-doing the marketplace's verification—you're adding context they don't have about your environment.
The technical implementation varies. Some teams build dashboards in their SIEM. Others use dedicated OAuth security tools. The common pattern: verification is your starting gate, monitoring is your ongoing control.
Conclusion
Marketplace verification solves the wrong problem. It ensures apps work as implemented—the OAuth flow is secure, the permissions are technically valid. It doesn't ensure apps are trustworthy over time.
Your security program should treat marketplace verification as input data, not a security control. When a developer requests an OAuth app, you check:
- Is it marketplace-verified? (Required, but not sufficient)
- Does the permission scope match the stated function? (Manual review for high-privilege apps)
- Is the publisher domain active and owned by a legitimate entity? (Automated check)
- When was the app last updated? (Red flag if >12 months for actively maintained APIs)
Then you monitor quarterly at minimum. Export your OAuth grants. Flag apps where the publisher domain returns 404 or shows a parking page. Review apps with sensitive scopes (calendar write, email read, drive full access) even if nothing else looks suspicious.
The OhAuth audit makes the tradeoff clear: Relying solely on marketplace verification means accepting that 32 percent of your approved apps carry structural exposure signals. Building continuous monitoring requires engineering time and tooling investment. But the alternative—discovering an abandoned app still has access to your email after the domain gets bought by an attacker—is worse.
Verification tells you an app was safe when published. Monitoring tells you if it's safe right now. You need both.
