For the past three years, whenever we’ve talked about supply chain security in trainings and conference talks, one slide always stood out: the risk of developer workstation compromise. Among the easiest and most valuable loot from such an incident? SSH keys. With a single stolen key, an attacker can often pivot into private repositories, escalating from one developer’s machine to the entire organization.
This idea has been floating around in theory for years. Today, we’re releasing keychecker — a tool that automates what we’ve been teaching manually: taking a suspicious key, validating where it works, and mapping its scope of impact.
Why keychecker?
The concept is simple:
- SSH connections leak metadata — even without full access, they can expose the associated username.
- Running
git ls-remoteagainst a private repo can confirm whether a key is valid for that target.
These two primitives form the backbone of the tool. keychecker just makes them repeatable, automatable, and extendable.
Currently, the tool supports six SaaS services (see README) through a plugin-based architecture, meaning it can be extended to support more providers in the future.
This isn’t rocket science. It’s just codifying the obvious so teams can move past the idea of “keys get stolen” and start validating the impact of that theft.
A Tool With Two Audiences
For Red Teamers
Red teamers know that post-exploitation is about showing impact. Looting a developer machine and finding SSH keys is one thing; demonstrating that those keys open doors into sensitive repos is what gets executive attention.
With keychecker, you can:
- Test stolen or simulated keys against multiple SaaS providers.
- Automate brute-forcing repository access without guesswork.
- Turn raw loot into a clear story: “Here’s the blast radius of this one stolen key.”
For Blue Teamers
Blue teams rarely get the chance to ask: “If one of our developer’s keys were stolen, what could it actually reach?”
keychecker provides a way to:
- Validate the scope of exposure tied to a key.
- Run internal simulations to identify weak points before attackers do.
- Build more realistic threat models around key compromise scenarios.
In other words, it’s both a scope identifier and a gap-finder.
The Telemetry Blind Spot
One reason this problem has persisted is the lack of visibility. GitHub, GitLab, Bitbucket, and others don’t consistently expose failed SSH key attempts in their logs. For defenders, that means there’s almost no telemetry around brute-force attempts. <https://github.com/settings/security-log> is the security log that is offered by github and it doesnt list ssh key attempts.
Attackers operate in this dark space. keychecker shines a small light by making the testing process transparent and reproducible for defenders as well.
Responsible Use
Like most post-exploitation helpers, this is not a tool for opportunistic abuse. It’s meant for:
- Red team engagements (to demonstrate impact).
- Incident response (to scope blast radius of stolen keys).
- Defensive validation (to proactively understand risks).
Use it in controlled environments, not against random targets.
What’s Next
keychecker is only one piece of the puzzle. Developer workstation compromise often comes with more loot than just keys: API tokens, cached credentials, internal documentation (Confluence, Jira, etc.). Future iterations of the tool could integrate these data points to simulate real-world lateral movement more fully.
But for now, it closes a gap that has existed for far too long.
Get the Tool
If you’re training, red-teaming, or building defenses against software supply chain risks, keychecker is a small but sharp addition to your toolkit.
<SelfPromotion>
Software Supply Chain is one of our core research areas and we offer various trainings on this Domain. Below are some of our upcoming trainings.
</SelfPromotion>