To review a new dependency in 30 minutes, try it in an isolated environment, read its install scripts, scan the most recent commits for anything suspicious, and check what extra packages it pulls in. These steps come from the practical testing and code evaluation sections of the OpenSSF evaluation guide.
Definition
A dependency review is a short, structured look at code you did not write before it enters your build. It does not replace automated scanning. It catches things scanners may miss, such as an install routine that reads environment variables.
The 30 minute plan
| Minutes | Step | What to look for |
|---|---|---|
| 0 to 5 | Confirm identity | Right name, right repository, no lookalike with higher popularity |
| 5 to 10 | Isolated trial | Add it in a sandbox or throwaway environment and watch behavior |
| 10 to 15 | Install routines | Scripts that run at install time |
| 15 to 22 | Recent commits | Changes made lately, by whom |
| 22 to 27 | Dependency impact | Unexpected or unnecessary indirect packages |
| 27 to 30 | Record | Decision, owner, date |
What the guide asks for
Behavior testing. Try adding the dependency as a test, preferably in isolation. Does it try to exfiltrate sensitive data?
Dependency impact. Does it bring unexpected or unnecessary indirect dependencies into production, for example ones only needed at development or test time? Every new dependency is a potential support problem or supply chain attack.
Malicious code check. The guide points to analyzing installation scripts, checking for data exfiltration from the SSH directory and environment variables, and looking for encoded or obfuscated values that get executed. It also says to examine the most recent commits, since an attacker may have added code recently.
Code completeness. Evidence of insecure or incomplete software, such as many TODO statements.
Sandbox testing. Consider running the software in a sandbox to try to trigger malicious behavior.
Steps in practice
- Open the registry page and the repository side by side, and confirm they point to each other.
- In a disposable container or VM with no real credentials, install the package.
- Read the install scripts and any post install hooks.
- Skim the last month of commits and the list of people who made them.
- List the full dependency tree before and after adding it.
- Search the source for encoded blobs and calls that read environment variables or key files.
- Write the result in your approval record.
Limits
Thirty minutes will not find a well hidden backdoor. It raises the cost for crude attacks and surfaces poor hygiene. Pair it with the maintenance questions in the OpenSSF evaluation guide and with advisory data.
Never run the trial on a machine that holds production secrets. Use a clean environment that you can destroy.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the direct and indirect components, which is the step where unexpected extras show up.
Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a 30 minute review enough for a critical dependency?
No. It is a screen. Critical components deserve deeper review and ongoing monitoring.
Where should I run the trial install?
In a sandbox or disposable environment with no real credentials.
Sources
Last reviewed: 19 October 2026.
