The GitHub OAuth attack exposed a security blind spot in the ever-growing web of permissions spanning developers, service accounts, and third-party OAuth apps. Here’s how to address it.
In early 2025, GitHub lit up with confusion and more than a little panic. Thousands of developers found suspicious issues posted in their public repositories, flagged with a GitHub-style “Security Alert: Unusual Access Attempt” warning. The problem? It wasn’t GitHub. It was an attacker masquerading as GitHub support, luring developers into authorizing a malicious OAuth app (gitsecurityapp) under the guise of incident response.
No zero-day. No credential theft. Just OAuth abuse, at scale.
This wasn’t the first OAuth-based exploit to hit the software supply chain, but it might be the loudest. The attackers knew the ecosystem. Because developers trust GitHub’s UI, they often skip reading OAuth scopes, and few organizations have real guardrails around what third-party apps can do once connected.
You can read the full technical breakdown on the Veza blog. I’ll cover the high points here.
The real problem: visibility, not vulnerability
OAuth is baked into how developers work. GitHub Actions, CI/CD pipelines, repo syncs, cloud IDEs—all of it runs on OAuth tokens and API scopes. But unlike SAML (Security Assertions Markup Language) or OIDC (OpenID Connect) flows, which are tied to policy, logging, and governance, OAuth apps often fly under the radar. That’s exactly what the attackers counted on.
Once users clicked “Authorize,” the malicious app inherited repo-level permissions, including access to:
- Source code (obviously)
- GitHub Actions secrets and automation tokens
- Linked infrastructure provisioning (Terraform, Pulumi, etc.)
- Hard-coded API keys and credentials
- Read/write org-level metadata in some cases
From there, attackers could pivot laterally across repos, leak code, plant backdoors, and poison builds. This wasn’t just a repo hygiene issue. It was an identity perimeter failure.
The identity security blind spot in devops
Traditional identity and access management (IAM) tools weren’t designed to handle this. Cloud security posture management (CSPM) platforms don’t watch GitHub OAuth. CI/CD security tools focus on build-time issues, not identity relationships. Single sign-on providers might enforce login policy, but OAuth apps are often granted access after authentication, outside of those controls.
That’s the gap attackers walked right through.
The GitHub incident exposed what security teams already suspect—that devops is running headlong into an identity sprawl problem. Identities (human and non-human) are multiplying, permissions are stacking up, and third-party apps are the new soft underbelly.
This is where identity security posture management (ISPM) steps in. ISPM takes the principles of cloud security posture management (CSPM)—continuous monitoring, posture scoring, risk-based controls—and applies them to identity. It doesn’t stop at who can log in; it extends into who has access, why they have it, what they can do, and how that access is granted, including via OAuth.
Visibility through identity security posture management
Modern identity security platforms are stepping in to close this gap. The leading solutions give you deep visibility into the web of permissions spanning developers, service accounts, and third-party OAuth apps. It’s no longer enough to know that a token exists. Teams need full context: who issued the token, what scopes it has, what systems it touches, and how those privileges compare across environments.
With the right platform in place, security teams can:
- Inventory and monitor all authorized OAuth applications, complete with scopes and usage context.
- Detect permission drift between human and non-human identities, so that temporary access doesn’t turn into persistent exposure.
- Enforce least privilege principles across developer tools and CI/CD pipelines, without blocking velocity.
- Create reusable access guardrails (sometimes called access profiles) to baseline what “good” looks like in production.
- Continuously monitor identity posture, surfacing risky over-permissioned paths or broken-glass misconfigurations before adversaries exploit them.
This is the heart of what analyst firms like Gartner now classify as identity security posture management (ISPM): proactively securing the perimeter where identity meets access, especially in developer environments, where the stakes (and the sprawl) are highest.
GitHub OAuth governance: A critical ISPM use case
GitHub has evolved far beyond version control. It’s now one of the most identity-dense platforms in the modern enterprise. And with that growth comes risk. OAuth apps, in particular, are a hidden minefield—often overprivileged, loosely monitored, and ripe for abuse.
From an ISPM lens, this isn’t just a configuration hygiene issue. It’s a real posture control gap. Modern identity security platforms are starting to close that gap by continuously mapping the relationship between GitHub identities (users, service accounts, teams) and the OAuth scopes they’ve authorized. The goal? Uncovering posture drift before it turns into breach material.
Key capabilities in these platforms typically include:
- Real-time mapping of authorized OAuth apps, scopes, and target repos.
- Drift detection, such as apps granted write or admin scopes that exceed baseline policy.
- Attribution clarity, answering questions like who approved what, when, and why.
- Policy enforcement to flag or block overly permissive apps based on least-privilege guardrails.
Rather than relying solely on periodic audits or manual repo reviews, these solutions integrate posture assessments directly into the devsecops life cycle, surfacing issues early, enforcing policy continuously, and keeping developer velocity high without sacrificing control.
GitHub OAuth governance has become a front-line ISPM use case. If you’re not watching those scopes, someone else eventually will.
A word about developer experience
Let’s be real. Developers aren’t asking for more security tools, policies, or friction. What they want is clarity, especially if it helps them stay out of the next breach postmortem. That’s why visibility-first approaches work. When security teams show developers exactly what access exists, and why it matters, the conversation shifts from “Why are you blocking me?” to “Thanks for the heads-up.”
Modern ISPM platforms that prioritize access intelligence and transparency make this collaboration possible. By surfacing access risks in GitHub, and mapping them to real-world OAuth scopes, users, and repos, these tools give developers the context they need without slowing them down.
This isn’t about controlling developers. It’s about making risk visible, actionable, and easy to fix before it shows up on the front page.
Get ahead of the next identity-linked attack
As the GitHub OAuth campaign demonstrated, credentials are no longer the only gateway. Identity is the new perimeter, and that perimeter extends deep into the developer stack—beyond traditional IAM controls and into OAuth scopes, CI/CD pipelines, and service connections.
It’s time to bring platforms like GitHub into your identity security strategy. ISPM offers the framework to do just that, combining access visibility with posture management across human and non-human identities.
This isn’t just a GitHub issue, but a wake-up call for every security team managing modern infrastructure. If it has access, it has risk. Identity-first security isn’t optional anymore—it’s foundational.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
