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.
Even that is not guaranteed to keep you safe 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. I am not being HN-paranoia-brained when I say it is the bare minimum for installing any software that comes from someone else, Github or an easily-compromised supply chain today.
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.