RepoSafety

Safely inspect untrusted repositories before you run them.

A lightweight safety layer for coding-interview repositories and AI coding workflows.

RepoSafety combines existing repository-analysis and security tools into a focused workflow for inspecting unfamiliar code before you execute it.

View on GitHub → See a real analysis ↓
/interview-repo-safety

Code you didn’t write deserves a second look.

Coding assignments increasingly arrive as complete repositories. Before reviewing them, you may clone them, install dependencies, run setup scripts, start development servers, execute tests, or ask an AI coding agent to work inside them.

The repository is code, and code can execute.

  1. Clone repository
  2. Install dependencies
  3. Run scripts
  4. Start application
  5. AI agent modifies / executes code

Every step crosses a trust boundary.

Don’t trust the repository. Inspect it first.

RepoSafety adds an inspection step between receiving an unfamiliar repository and running it.

UNTRUSTED REPOSITORY
↓
RepoSafety
↓
  • repository structure
  • dependencies (incl. devDependencies)
  • lifecycle scripts
  • hooks and IDE auto-run
  • network / C2 indicators
  • credentials and git history
  • dynamic execution patterns
↓
HUMAN REVIEW
↓
RUN / DON’T RUN

One command. Several checks. One report.

  1. 01

    Inspect

    Read manifests, lockfiles, hooks, IDE tasks, and repository structure. Identify executable surfaces without running them.

  2. 02

    Analyze

    Apply static detection rules and, when available, Sonatype dependency intel and Opsera security-scan. Never install the target to analyze it.

  3. 03

    Correlate

    Classify packages against the assignment, collect IOCs, and emit one categorical verdict with confidence.

  4. 04

    Review

    The developer decides what to run. Optional Phase 2 install uses a Docker jail (reposafety-run), not the host. RepoSafety does not make the decision for you.

This is what happens when you run it.

A real coding-interview repository analyzed with /interview-repo-safety. The target was not installed or executed.

Interview repository
↓
/interview-repo-safety
↓
Repository inspection
↓
Execution surfaces
↓
Findings
↓
Human review
Interview Take-home Security Audit branch original
VERDICT
DO NOT INSTALL / RUN
CONFIDENCE
HIGH
assignment
Presented as “Proof of Dev” (Next.js, wallet/RainbowKit, Alchemy). README: npm install && npm run dev.
mismatch
Animation/PostCSS stack is not required for that product story. It is the delivery path.
decoy
animatecss-tailwind-adapter@2.0.6 — direct devDependency, required from apps/web/tailwind.config.ts
dropper
@aaron205whitmore/postcss-animate-utils@1.0.2 — private scope, restricted publish; lockfile-resolved
execution
Import-time / Tailwind plugin evaluation. No install lifecycle script required. npm run dev is enough.
dynamic
Obfuscated host → POST /debugCheck → base64 payload → new Function('require', …)(require)
network
http://153.75.81.2:1224/debugCheck (raw IP HTTP)
credentials
.npmrc npm _authToken (CRITICAL, value redacted). Same class in git history at 3c6624c.
hooks / IDE
None found (non-sample). Risk is npm install / dev, not Git hooks.
sonatype
not verified / unavailable on this run
opsera
not verified / incomplete on this run
recommendation
DO NOT RUN. Phase 2 sandbox refused for this verdict.

What was inspected

Manifests and a 1251-package lockfile, tailwind.config.ts, .npmrc, git history, .git/hooks, IDE/devcontainer surfaces, lifecycle script flags, and static JS for the decoy/dropper path. Nothing in the target was executed.

What was found

A committed registry token, a decoy Tailwind plugin in devDependencies, and a private-scoped package that talks to a raw-IP host and evaluates the response. The animation stack does not fit the stated assignment.

Why it matters

Following the README (npm install && npm run dev) is enough to fetch the restricted package and reach RCE. Git hooks were clean. The trap is the install/dev path the candidate is told to run first.

What happens next

The skill reported DO NOT INSTALL / RUN and refused sandboxed execution. It does not automatically declare a repository safe. A human reads the report and decides. If this assignment already ran elsewhere, treat that machine as compromised.

Read the full report →

Built for the agentic coding workflow.

RepoSafety is designed to sit at the beginning of an AI-assisted coding workflow, before an agent starts executing unfamiliar repository code.

Candidate repository
↓
/interview-repo-safety
↓
Safety analysis
↓
Human review
↓
Coding agent
/interview-repo-safety

Phase 1 is always static. Announce: static-only audit, no install/run of the target. Phase 2 runs only if you ask and the verdict is SAFE TO INSTALL or REVIEW BEFORE INSTALLING. It uses a Docker jail with folder-only filesystem access and default-deny egress (registry.npmjs.org until you whitelist another host). A block refuses install; observe-in-jail is a separate explicit request.

What RepoSafety checks

Categories below are surfaces the current skill actually inspects. Optional tools appear in the report only when they return data.

Repository structure

Languages, package managers, workspaces, containers, custom registries, private scopes, Git/tarball/file dependencies.

Dependencies

Direct and transitive, including devDependencies. Unusual names, unexpected private scopes, assignment mismatch.

Scripts

preinstall, install, postinstall, prepare, and other lifecycle keys. App scripts that would load a decoy on npm run dev.

Process execution

Dynamic eval (new Function), obfuscated loaders, child_process in context of the assignment.

Network

Domains, URLs, raw IPs, and remote payload fetch mechanisms. Recorded as IOCs. Payloads are not fetched.

Git hooks and IDE auto-run

Non-sample hooks, global hooksPath, .vscode / .devcontainer / .idea tasks that run on open.

Credentials

.npmrc, .env, CI, and secrets in git history. Values redacted. TYPE / FILE / LOCATION / SEVERITY only.

Optional tool reuse

Sonatype dependency intel and Opsera security-scan when those tools are already available. Gaps are reported as not verified.

Not another scanner. A layer around the tools that already exist.

RepoSafety does not attempt to replace mature security and static-analysis tools. It provides a focused workflow for applying them to one specific problem: understanding an unfamiliar repository before executing it.

RepoSafety
↓
  • static checks + helper scripts
  • Sonatype (when available)
  • Opsera security-scan (when available)
  • Phase 2: Docker jail + egress proxy
↓
Unified review

Know what it can — and cannot — tell you.

RepoSafety can help identify

  • Malicious or high-risk dependencies, including decoys in devDependencies
  • Committed registry tokens and secrets in git history
  • Remote fetch plus dynamic execution (C2-style) in package code
  • Assignment vs dependency mismatch
  • Git hooks and IDE auto-run surfaces
  • Where optional scanners were unavailable, so you do not over-read the report

RepoSafety cannot guarantee

  • that a repository is safe
  • absence of malware
  • absence of unknown vulnerabilities
  • safety against every obfuscated technique
  • runtime behavior that static analysis cannot observe

The goal is risk reduction and informed review — not a guarantee of safety.

Small surface. Composable architecture.

Repository
↓
Static inspector (no install / no run)
↓
  • inventory-node.mjs
  • scan-surfaces.sh
  • hash-hooks.sh
  • Sonatype · Opsera, if present
  • policy + detection rules
↓
Finding model → safety report
↓
Human review
↓
Phase 2: reposafety-run (Docker jail + allowlist proxy)

Read the implementation.

RepoSafety is intended to be understandable, inspectable and useful as a developer tool. The implementation and methodology are available on GitHub.

View the repository → Install the Cursor skill →

Before you run unfamiliar code, take a look under the hood.

Run /interview-repo-safety against the repository first.

View RepoSafety on GitHub → Read the real analysis