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.

How about we don't run code we do not trust. There is enough rogue code running around on a laptop. Also, to people making interviewees run untrusted code, give a 3rd party desktop access, why don't you imbeciles figure out how to TALK to people and look at their experience and figure out a hiring process like any regular business not run by inept anti-environment, anti-human psychopathic CEOs. It's really not that hard to discuss pseudocode, discuss project history and design, and figure out someone's problem solving skills.

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.