Review unfamiliar repositories without giving them your credentials

Treat the request as a capability decision

A repository can arrive through a job interview, a plugin suggestion, a customer sample or an AI agent’s generated solution. None of those contexts makes its contents trusted automatically. Before running anything, state the task you actually need to complete. Reading a few files may be enough to answer a design question. Building the project may require more authority. Connecting it to production is another decision again. This guide proposes a defensive review sequence; it does not provide malware execution instructions or promise that a simple sandbox can contain every program.

Verify the source through a separate channel

Confirm who requested the task and whether the repository location matches the legitimate project’s published references. Avoid relying entirely on the same message that supplied the link. Recruitment threats described in the joint WaterPlum advisory show why a coding task can be an entry point rather than merely an assessment. That campaign is an example, not a reason to suspect a person based on nationality or remote-work status. A consistent verification process protects legitimate collaborators as well as the organization receiving their code.

Inspect the execution surface before the application

Read the package manifest, installation hooks, build scripts and configuration before following the quick-start command. Look for steps that download and execute additional code, request credentials, alter shell profiles or access unexpected directories. Also inspect editor and development-environment configuration that might trigger actions when a project opens. The immediate aim is to understand what would run and under whose authority. A familiar framework or a successful static scan is useful context, but neither explains every script that a setup process can invoke.

Keep the review environment free of valuable access

Use an environment appropriate to the organization’s threat model and the code’s risk. It should not inherit production credentials, a personal browser profile, SSH agents, wallet material or broadly mounted host directories. Restrict network access and administrative capabilities to what the approved test needs. A container with a sensitive host mount or a privileged control socket may expose much more than its label suggests. For high-risk material, involve a qualified security team instead of trying to improvise containment from a short tutorial.

Handle secrets as explicit inputs

OWASP’s secrets guidance supports treating credential access as a managed capability with ownership, scope and lifecycle. A review task usually needs synthetic values rather than a real provider key. If an integration genuinely requires credentials later, use narrowly scoped test access through the approved storage mechanism and define revocation. Do not paste secrets into source files, issue comments, screenshots or model prompts. A program that refuses to demonstrate basic behavior without unrestricted access deserves further explanation before that access is granted.

Separate dependency presence from dependency trust

Third-party code can execute in a browser, a build process or a server, with different consequences in each place. Review why a dependency is needed, how it is obtained and what permissions it receives. Pinning a version improves reproducibility but does not establish that the version is safe. Likewise, a clean package audit answers only the checks represented in that audit. The practical objective is to reduce unnecessary code and authority, then make the remaining assumptions visible rather than replacing review with a single green badge.

Use an evidence ladder for execution

If execution is justified and authorized, define a bounded input, an expected output and the files or connections the process may create. Prefer synthetic fixtures and a fresh environment. Observe the result and keep a record that excludes secrets. Label untested paths honestly: a local parser check does not verify a cloud provider, a harmless fixture does not exercise every branch and a successful run does not prove absence of malicious behavior. These distinctions matter when an AI assistant summarizes its work or hands the project to another developer.

Stop when the requested authority grows

A setup that unexpectedly asks to disable protection, expose credentials or connect unrelated accounts has changed the review scope. Pause that dependent step, preserve the evidence and seek a technical explanation through a verified channel. Continue any safe reading or analysis that does not require the new authority. The desired result is a reviewable decision about the code’s intended use, not a contest to make every unfamiliar project run. Keep the smallest useful capability and the unresolved limitations explicit.

Sources and reading

• OWASP Secrets Management Cheat Sheet (accessed 2026-10-16)
• OWASP Third Party JavaScript Management Cheat Sheet (accessed 2026-10-16)
• Joint WaterPlum advisory: recruitment-code risk (2026-09-22)