Hi HN, I built CloneGuard after a fake recruiter had me run a “take-home” codebase on a call. I ran it once, stopped it, and later asked an AI tool to explain the code. It was a stealer going after SSH and AWS keys. I reported it to IT immediately, but it made me realize I had no quick way to vet a repo before touching it.
In these attacks the payload is often not the app itself. It’s an npm install script or a .vscode/tasks.json task that runs the moment you open the folder. So CloneGuard looks for exactly that kind of thing.
It’s a single Go binary with no dependencies, and it is read-only. It never runs, installs or imports anything from the project.
reads of SSH keys, cloud credentials (AWS, GCP, Azure, kube), browser data, wallets
connections to raw IPs, webhooks, pastebins, tunnels
download-and-run patterns (eval, curl | sh)
auto-run hooks (npm scripts, VS Code tasks, setup.py)
obfuscated code and committed binaries
A file that both reads secrets and talks to a suspicious server is escalated to “critical”. Exit codes (0-3) make it easy to drop into a script or git hook. The demo/ folder has a deliberately malicious sample you can try it on.
Limitations: it’s regex and heuristic based, so a determined attacker can evade it, and legitimate code (a password manager, for instance) can trigger false positives. “Clean” doesn’t mean safe. For code from strangers, still use a throwaway VM.
I’d love feedback on techniques it misses, false positives you hit, and rules you’d want added.
Hi HN, I built CloneGuard after a fake recruiter had me run a “take-home” codebase on a call. I ran it once, stopped it, and later asked an AI tool to explain the code. It was a stealer going after SSH and AWS keys. I reported it to IT immediately, but it made me realize I had no quick way to vet a repo before touching it.
In these attacks the payload is often not the app itself. It’s an npm install script or a .vscode/tasks.json task that runs the moment you open the folder. So CloneGuard looks for exactly that kind of thing.
It’s a single Go binary with no dependencies, and it is read-only. It never runs, installs or imports anything from the project.
cloneguard clone https://github.com/someone/demo-app cloneguard scan ./some-folder
What it flags:
reads of SSH keys, cloud credentials (AWS, GCP, Azure, kube), browser data, wallets connections to raw IPs, webhooks, pastebins, tunnels download-and-run patterns (eval, curl | sh) auto-run hooks (npm scripts, VS Code tasks, setup.py) obfuscated code and committed binaries
A file that both reads secrets and talks to a suspicious server is escalated to “critical”. Exit codes (0-3) make it easy to drop into a script or git hook. The demo/ folder has a deliberately malicious sample you can try it on.
Limitations: it’s regex and heuristic based, so a determined attacker can evade it, and legitimate code (a password manager, for instance) can trigger false positives. “Clean” doesn’t mean safe. For code from strangers, still use a throwaway VM.
I’d love feedback on techniques it misses, false positives you hit, and rules you’d want added.
cool, now they know how to hide better.
why not improve tooling on how to run untrusted code in isolated environments? this covers wider range of applicable situations.