Why I Built repyy

I kept seeing posts on LinkedIn about developers receiving take-home assignments from interviewers—or people pretending to be interviewers—that contained malicious code or suspicious packages.

That stuck with me. A coding assignment is supposed to show how you think and build things. But the instructions often start with something familiar: clone this repository, install the dependencies, and run the app.

When you’re focused on making a good impression, it’s easy to treat those steps as routine. I wanted a way to pause before that point and ask: what am I actually about to run?

That’s why I built repyy .

The part before “it works on my machine”

The problem isn’t limited to the application code you eventually open in your editor. An unfamiliar repository can include install hooks, build scripts, editor tasks, unusual dependency sources, and instructions that ask you to run something you haven’t reviewed.

Looking at the homepage or skimming a few components doesn’t tell you much about those parts.

I wanted something that could read the repository first and point me toward things worth investigating. Something I could use before installing its dependencies or starting its development server.

What repyy actually does

repyy is a local, read-only malware and supply-chain scanner. It combines static checks, heuristics, and known indicators to identify suspicious patterns in source code and repository configuration.

Some of the things it looks for include:

• Execution paths: dynamic execution, process spawning, and download-to-execute chains.
• Install and build behavior: package lifecycle hooks and scripts that run during setup.
• Obfuscation: decoding and other techniques that can hide what code is doing.
• Sensitive access: patterns involving credentials, wallets, environment collection, and outbound transfers.
• Repository configuration: editor tasks, agent hooks, containers, and CI workflows that can introduce execution paths outside the main application.

Those are review signals, not automatic conclusions. A build script can be legitimate. A network request can be expected. The question is what the code does, where it runs, and whether that behavior makes sense for the project.

The coverage guide  documents the checks and their limits. I want those limits to be visible, because a scanner that sounds more certain than it is would miss the point.

The workflow I wanted

With repyy installed separately from its official releases , scanning a local checkout looks like this:

repyy scan ./unfamiliar-repository --format html --output repyy-report.html

That gives you a self-contained HTML report you can open locally. Displaying the report makes no network requests; clicking a source link can open the provider’s website.

I would start by checking whether the scan completed, then review the findings and their locations. The useful part is having a smaller set of concrete questions to investigate instead of guessing where to start.

If a rule needs more context, the CLI can explain its rationale and legitimate-use cases:

repyy rules explain RULE-ID

Replace RULE-ID with the identifier from a finding. The goal is to understand the result, not just react to its severity label.

“No findings” is not “safe”

This is probably the most important part of the project.

Heuristics can miss malicious behavior. They can also flag legitimate code. repyy doesn’t execute the target, resolve every dependency, or prove what the application will do at runtime.

It also isn’t a replacement for tools such as npm audit or other ecosystem vulnerability checks. Those answer a different question about known vulnerabilities in dependencies. repyy focuses on suspicious source and repository behavior before execution.

Why keep it local?

An interview assignment might contain private code. So might a repository you’re reviewing for work. I didn’t want reviewing it to require uploading its contents to another service.

Scans run locally without contacting package registries or uploading repository data. Updating the offline intelligence snapshot is a separate, explicit operation. That separation matters to me: reading a repository should not quietly become sharing it.

Reports can contain sensitive details from the code being reviewed, so I treat them as private review material too.

A small pause worth building

I didn’t build repyy because I think every assignment is malicious. I built it because the step between receiving unfamiliar code and running it deserves more attention.

For me, the useful outcome is a better question: why does this assignment need that install hook, that command, or access to those files?

If you’ve had the same hesitation when opening an unfamiliar project, you can find repyy on GitHub  or read the docs . It’s open source, and there’s plenty to improve. But the reason for building it is straightforward: I want to take a closer look before I run someone else’s code.