Treat an Unfamiliar Repository as Untrusted Code

A repository can look legitimate, build correctly, and still execute code you did not intend to trust.

Goal

Practice pre-execution inspection before running an unfamiliar development project.

Activity

Use an instructor-provided benign sample repository. Do not use known malware.

1. Read the README without executing anything.
2. Inspect package.json, especially scripts, dependencies, and development dependencies.
3. Identify which commands would execute during common steps such as install, start, build, or test.
4. Look for shell commands, downloaded binaries, post-install hooks, encoded data, unexpected network access, or scripts that reach outside the project directory.
5. Decide what isolation you would use before running the project: disposable VM/container, low-privilege account, no production credentials, restricted network, or another control.
6. Only after review, run a safe instructor-approved command if the lab environment permits it.

Deliverable

Write a short pre-execution risk assessment: what you inspected, what would execute, what you still do not know, and what control would reduce the remaining risk.

Discussion

Why is “it came from GitHub” not a security assessment?

Source material

First spotted in PTIR: July 30, 2026, Morning Briefing.

Elastic Security Labs documented a campaign in which working coding-challenge repositories concealed malware chunks inside SVG files. Normal-looking npm start/dev workflows reconstructed credential theft, file theft, remote-access, and clipboard-stealing components. The durable teaching point is that a repository’s appearance, host, or ability to run successfully does not establish trust; execution paths and package scripts need inspection first.

Consult the Elastic Security Labs report