
UpTrajectory Review
The security industry's obsession with endpoint detection has left a blind spot right where small development teams actually work: inside GitHub itself. Researchers Yossi Weizman and Mor Weinberger demonstrated at Black Hat USA 2026 that the platform generates its own equivalent of EDR telemetry—webhooks, API events, authentication logs—that remains largely untapped by defenders. Their open-source GitHub Threat Detector tool, with 22 production rules and 12 in beta, treats the repository platform as a security sensor rather than merely a code host. This reframing matters because supply-chain attackers have learned to operate where conventional tools do not look, exploiting the gap between 'GitHub knows what happened' and 'the security team never saw it.'
For small dev shops and the businesses that depend on them, this is not an enterprise luxury. The Shai-Hulud, Trivy, and Megalodon attacks all followed recognizable patterns— forged commit metadata, poisoned tags, workflow abuse, OIDC token theft, evidence destruction—that left traces in GitHub's own event stream. A three-person shop shipping critical infrastructure code has no SOC analysts parsing endpoint telemetry at 3 AM, but they do have GitHub webhooks they are probably ignoring. The researchers' compound detection approach—correlating individually weak signals into actionable alerts—is specifically designed for resource-constrained environments where false positives bury teams and missed positives bury companies.
What deserves scrutiny is the claim that 'you're just not listening.' The framing implies negligence, but the reality is structural: GitHub's telemetry is fragmented across webhooks, audit logs, GraphQL APIs, and repository metadata with no unified query interface. Small teams lack the engineering hours to build correlation engines. Weizman and Weinberger's tool addresses this, yet their presentation also reveals how much GitHub itself could do but has not—why does the platform not natively flag when commit author metadata diverges from authenticated pusher identity? The gap between available data and accessible detection is a product decision as much as a security failure.
The downstream effects split unevenly. Attackers who counted on GitHub's opacity will adapt, likely shifting toward techniques that leave fewer platform-native traces or that exploit detection rule gaps. Meanwhile, the tool's open-source release creates a defensive commons that benefits small teams disproportionately—if they can deploy and maintain it. There is a real risk of two-tier security: organizations with DevOps bandwidth gain compound detection while others face the same exposure with new awareness but no operational capacity. The OIDC theft vector is particularly concerning here, as it bridges GitHub compromise into cloud infrastructure in ways that outpace most small teams' incident response.
Watch whether GitHub responds by integrating native behavioral detection or whether this remains a third-party responsibility. The platform's incentives are mixed: native detection might reduce enterprise demand for GitHub Advanced Security add-ons, yet inaction invites regulatory attention as supply-chain attacks escalate. For operators, the immediate move is audit your GitHub audit log access—most teams have never exported it—and test whether you can answer basic questions: who pushed this commit, did the author match the authenticator, which workflows executed with elevated permissions? The Threat Detector tool offers a starting point, but the harder work is building the organizational habit of questioning repository events that look technically valid but behaviorally anomalous.
The deeper lesson is about platform dependency. Small dev shops consolidated on GitHub for velocity and network effects; they now discover that concentration creates systemic risk the platform does not fully mitigate. The researchers' work is valuable precisely because it treats GitHub as infrastructure to be instrumented rather than a service to be trusted. That mindset shift—from 'GitHub handles security' to 'GitHub generates evidence'—is the lasting takeaway, and it applies wherever platform convenience outpaces operational visibility.
Takeaway: Export your GitHub audit logs today and verify you can spot when commit authors don't match authenticated pushers—this single check catches a common attack pattern.
Excerpt from the original — InfoWorld
Many of the recent supply-chain attacks could have been caught earlier if defenders looked closely at the telemetry GitHub already provides, researchers said.
At their Black Hat USA 2026 presentation, researchers Yossi Weizman of Microsoft and Mor Weinberger of Echo argued the case, saying, “GitHub can tell you’re being hacked. You’re just not listening.”
The duo described an EDR-style detection approach built from GitHub’s own event stream rather than relying solely on conventional endpoint or network telemetry.
After studying recent supply-chain attacks, including Shai-Hulud, Trivy, and Megalodon, the researchers found that seemingly different incidents repeatedly used the same techniques, from forged commit identities and poisoned tags to workflow abuse, OpenID Connect (OIDC) theft, and attempts to erase evidence.
They said they turned those recurring techniques into …