A fake recruiter’s demo app inspired CloneGuard, a scanner that reads code before it runs
Tharun’s small Go utility checks install hooks and editor tasks, with documented blind spots that matter as much as its warnings.
The interview assignment wanted access to SSH and AWS keys. Apparently “tell us about yourself” now includes a request for the credentials that let somebody else impersonate you on a server.
The CloneGuard README says the tool was built after a fake recruiter’s demo app tried that theft. Its response is a small Go command-line scanner that reads a repository before its target opens the project in an editor or starts installing dependencies. The tool’s promised restraint is useful: the thing inspecting a suspicious package should not begin by giving that package a turn at the wheel.
The dangerous moment can arrive before the app’s launch button. The maker describes install scripts and editor tasks as possible triggers. A take-home exercise can look like unfinished work while its setup instructions do the attacker’s actual work (very efficient hiring).
CloneGuard checks package install hooks and VS Code tasks configured to run when a folder opens. It also looks for credential-file access, suspicious network destinations, downloaded code being executed, obfuscation and compiled binaries checked into the repository. Those are clues a candidate can investigate without first agreeing to every instruction in the project’s README.
The scanner raises the severity when risky behaviors occur in the same file. Reading a key and contacting a suspicious server together earns more attention than either finding on its own. A password manager can legitimately read sensitive data; a credential reader with an unexpected delivery address deserves a much longer conversation.
The repository’s sample output identifies a file and line for each finding, prints the suspicious snippet, and explains the concern. Its bundled demonstration combines a fake stealer with an auto-running editor task. That makes the warning something a human can inspect, rather than a red badge demanding blind faith in a different piece of software.
A JSON mode exposes the findings to other tools. Exit codes distinguish no detected flags, medium findings, high findings, critical findings and an error. That last distinction matters in an automated check: unreadable files need an error result, so a broken scan cannot quietly graduate to “nothing to see here” on the strength of its terminal colors.
Its limitations are refreshingly specific. The scanner uses line-level regular expressions and file checks. Documentation and lockfiles are excluded from text rules, dependency folders are skipped by default, and files above the configured size limit are skipped. Each choice limits noise or work, and each also limits what a clean result can claim.
The README states, “not proof of safety,” about finding no red flags. That sentence deserves to survive every screenshot of the verdict. Determined attackers can evade pattern checks, and legitimate projects can trip them. A reassuring badge cannot tell a candidate what the skipped files contained or whether the attacker used a trick outside the rules.
The project requires Go 1.24 or later to build, has no third-party dependencies, and carries an MIT license. Those are the maker’s published properties; this article does not claim an independent malware-detection benchmark or a hands-on scan of a real recruiter’s payload. Whether the next convincing demo app uses a recognizable trick remains unresolved.
The useful future for a tool this small is earlier scrutiny: before the install command, before the editor task, before the candidate feels rushed into making the demo work. Employers with real assignments can make that easier by accepting review and isolation as normal preparation.
Credentials aren’t a job qualification.