To test a new package safely, install and run it in an isolated environment with no real secrets, watch its network connections, file changes and processes, and only then add it to your project. The OpenSSF evaluation guide recommends this practical testing step for catching behavior such as data exfiltration.
What the guide asks for
Under practical testing, the guide says to add the dependency in an isolated environment and watch for malicious behavior, such as data exfiltration. In its code evaluation section it lists inspecting installation scripts, data exfiltration, obfuscated code and recent commits, and running the software in a sandbox to detect malicious behavior.
This matters because reading code takes time and malware can hide. Observing behavior is quicker and catches different things.
Set up the sandbox
Use something disposable. A fresh virtual machine, a container with no mounted secrets or a throwaway cloud workspace all work. The rules:
- No real credentials, tokens, SSH keys or cloud profiles in the environment.
- No access to internal networks.
- A way to see outbound connections, such as a firewall log or a packet capture.
- A snapshot you can discard.
The routine
- Create the sandbox and a blank project.
- Look first, install second. Read the package manifest for install or post install scripts, since those run during installation.
- Install the package with scripts visible. Where your package manager lets you disable install scripts, try that first and see what breaks.
- Watch for unexpected outbound connections during install and during a basic run.
- Check files written outside the project folder, new scheduled tasks, and changed shell startup files.
- Run the package's own tests and a small example of your use case.
- Delete the sandbox.
What to watch
| Observation | What it may mean |
|---|---|
| Network call to an unrelated host at install | Possible exfiltration, investigate |
| Reads of credential files or environment variables | Red flag unless clearly needed |
| Obfuscated or encoded install script | Strong warning |
| Writes outside the project directory | Look at why |
| Large binary download at install | Check source and checksum |
| Quiet install, expected calls only | Consistent with a normal package |
What the sandbox will not catch
Malware can wait. Some code only activates after a delay, on a certain date, or on a certain environment such as a CI runner with real tokens. A sandbox with no secrets may never trigger it. So treat the sandbox as one layer, not a pass certificate.
Pair it with the other checks: confirm the name, look at who publishes it and when, and review recent commits. For the fuller routine, see the 10 minute checklist before adding a dependency.
After adoption
Pin the version, commit the lockfile and review changes on each upgrade. The point of a sandbox is to make the first adoption safer, but a later release can behave differently from the one you tested.
Quick check
Is it safe to test a suspicious package on my laptop?
Not if the laptop holds real credentials. Use a disposable environment without secrets or internal network access.
If the sandbox shows nothing odd, is the package safe?
Not necessarily. Some malicious code delays or targets particular environments, so combine it with other checks.
Safeguard's policies, gates and guardrails can enforce rules on dependency changes, and its SBOM and dependency scanning tracks what you adopted. Try the free scan.
Sources
Last reviewed: 19 October 2026.
