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 their findings 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 at least five real projects, including Trivy, TanStack, Megalodon, and Red Hat, finding that 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 by attackers, but GitHub separately records who actually pushed the code, creating a gap that 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 that project is automatically infected, have been a growing problem for several 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.
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, email, and timestamp 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 is the catch GitHub does not advertise. GitHub separately logs the account that was actually authenticated, meaning logged in and verified, when the code was pushed. If the stated author and the authenticated pusher do not 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/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 database running PostgreSQL, a common open-source database engine, stores this history so the tool can spot patterns across days or weeks, not just single moments.
The 22 production rules and 12 beta rules were tested against 52 reproduced attack scenarios, including recreations of the Trivy, TanStack, Megalodon, and Bitwarden CLI incidents. The tool deliberately combines several weak signals into one stronger alert, reducing the number of false alarms teams would otherwise drown in.
It is not perfect. GitHub can be configured to disable the event feeds the tool relies on. The API imposes request limits. Some checks are not 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 and achievable 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 software 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 in your repositories have permission to generate cloud access credentials, and remove that permission where it is not needed.
The GitHub Threat Detector tool is open source, meaning free to inspect and use, for teams that want a more automated approach.
