Your GitHub activity logs are a smoke detector you forgot to switch on
Two researchers showed at Black Hat USA 2026 that the evidence needed to catch software supply-chain attacks has been sitting inside GitHub all along. Their open-source tool turns that evidence into working alerts.
Key points
- Microsoft researcher Yossi Weizman and Echo researcher Mor Weinberger presented at Black Hat USA 2026, arguing that GitHub's own event data can detect supply-chain attacks before they cause serious damage.
- The researchers studied attacks on real projects including Trivy, TanStack, Megalodon and Red Hat, finding each attack reused the same small set of techniques.
- Their open-source tool, GitHub Threat Detector, ships with 22 production detection rules and 12 beta rules, tested against 52 simulated attacks.
- Git metadata such as author name and email can be faked, but GitHub separately records who actually pushed the code, creating a gap defenders can watch.
- The tool has real limits: webhooks can be disabled, GitHub's API applies rate limits, and some checks are not instant.
Software supply-chain attacks, where criminals quietly slip malicious code into a trusted open-source project so that every organisation using it is automatically infected, have been a growing problem for years. The common assumption is that catching them early is hard. Weizman and Weinberger disagree.
Presenting this month at Black Hat USA 2026 in Las Vegas, and first covered by CSO Online, the pair argued that GitHub, the website where most open-source code lives and is managed, already records enough activity to flag these attacks. The problem, they said, is that almost nobody watches the right signals. Given that CISA published its open-source security playbook for federal agencies on 30 July 2026, the question of who is actually watching GitHub logs has never felt more pointed.
How do supply-chain attackers actually get in?
Every attack the researchers studied relied on the same short list of tricks. The most important: faking a commit identity.
A commit is a saved change to a piece of software. Git, the underlying version-control system most projects use, lets anyone set whatever name and email they like on a commit. Criminals use this to make a harmful code change look as if it came from a trusted project maintainer.
Here's the catch GitHub doesn't advertise. GitHub separately logs the account that was actually authenticated when the code was pushed. If the stated author and the authenticated pusher don't match, that gap is a red flag sitting in GitHub's event logs, waiting to be read.
The researchers also found attackers reusing the same fake email addresses across multiple projects. Searching GitHub for a single address can therefore connect incidents that looked unrelated into a single campaign.
| Technique | What it means in plain English | Seen in |
|---|---|---|
| Forged commit identity | Fake author name and email on a code change | Trivy, tj-actions, Megalodon, TanStack, Red Hat |
| Mass tag poisoning | Moving release labels onto malicious code so users auto-download it | Multiple campaigns |
| Workflow abuse | Hijacking the automated scripts that build and publish software | Several incidents |
| OIDC token theft | Generating short-lived cloud access passes from inside a compromised build | Observed across campaigns |
| Evidence erasure | Deleting logs or reverting changes to hide the intrusion | Multiple incidents |
What does GitHub Threat Detector actually do?
The tool works like endpoint detection software, a program security teams run on company computers to spot suspicious behaviour, except here it watches GitHub instead of laptops.
It pulls in live event feeds from GitHub (called webhooks), activity data from GitHub's programming interface (its API), and direct inspection of code repositories. A PostgreSQL database stores this history so the tool can spot patterns across days or weeks, not just single moments.
Twenty-two production rules and 12 beta rules were tested against 52 reproduced attack scenarios, including recreations of the Trivy, TanStack and Bitwarden CLI incidents. The tool deliberately combines several weak signals into one stronger alert, cutting the false alarms teams would otherwise drown in.
It's not perfect. GitHub can be configured to disable the event feeds the tool relies on. The API imposes request limits. Some checks aren't instant. Weizman and Weinberger were upfront about all of this.
What should organisations using open-source software do?
If your organisation builds software using open-source libraries hosted on GitHub, these steps are practical without specialist knowledge.
First, turn on GitHub audit logging and actually review it: many organisations enable logs and never look at them. Second, watch for any mismatch between the stated author of a code change and the account that pushed it. Third, check whether your build pipelines pin to a specific fixed version of a dependency rather than a floating tag like @v1, which attackers can silently redirect. Fourth, review which automated workflows have permission to generate cloud access credentials and remove that permission where it isn't needed.
GitHub Threat Detector is open source and free to inspect and use for teams that want a more automated approach.
The blunt assessment from this beat: the techniques Weizman and Weinberger catalogued aren't novel, and the evidence they need has always been there. What's been missing is anyone bothering to look. That's a process failure, not a technology gap, and a new tool won't fix it if audit logs keep sitting unread.
