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.
In this day and age this is a bit like bringing a knife to a biocybernetic nanomaterial mimic fight. You will have much better results, with all software, instead of putting trust in a regex filter, asking any recent AI agent “I’m about to clone this repo, can you scan it for anything malicious/suspicious, phone-homes, possible hidden payloads, or secret update/c&c pathways?” even that is not guaranteed depending on the model used and the sophistication of the malware but you’ll at least have a much better chance than a filtering tool.
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.
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.
WTF. Is that really a thing?
autorun.inf called, it wants their method back.
why not improve tooling on how to run untrusted code in isolated environments? this covers wider range of applicable situations.