When skimming a dependency's source, look for install scripts, obfuscated or encoded code, outbound network calls that do not fit the package's purpose, many TODO markers, weak input handling and suspicious recent commits. You cannot review everything, but this short pass catches the obvious problems.
What the guide says to check
The OpenSSF evaluation guide's code evaluation section lists several items: look for signs of incomplete or insecure code, such as many TODO statements; inspect installation scripts, data exfiltration, obfuscated code and recent commits; look for evidence of secure coding, such as input validation and parameterized statements; review the top problems reported by static analysis tools; and run the project's tests to confirm they pass.
Seven things to scan for
- Install hooks. Files that run at installation, such as lifecycle scripts in a manifest, execute with your privileges. Read them first.
- Encoded or obfuscated blobs. Long strings of base64, hex or minified code in a source library with no reason for it deserve a question.
- Unexpected network calls. A formatting library that opens a connection to a remote host is odd. Search for HTTP clients, sockets and DNS lookups.
- Reads of secrets. Code touching environment variables, credential files, browser stores or SSH keys needs a clear reason.
- Dynamic execution. Calls that evaluate strings as code, spawn shells or download and run content are higher risk.
- Sloppy input handling. String built queries or commands from user input, and missing validation on parsers.
- Fresh, odd commits. A recent commit that adds a dependency, changes the build or touches install hooks, from a contributor you do not recognize, is worth reading line by line.
A quick method
- Clone the repository and use a search tool for the patterns above.
- Read the diff of the last few releases, not just the latest code.
- Compare the published package contents with the repository. Differences between what is in the repository and what is in the registry artifact are a reason to dig.
- Run a static analysis tool and look at the top findings, as the guide suggests.
- Time box it. Twenty minutes is enough for a first pass.
Reading the results
| Finding | Response |
|---|---|
| Obfuscated install script | Stop, do not adopt |
| Network call with clear, documented purpose | Fine, note it |
| Many TODOs in core paths | Lower trust, check tests |
| Weak input handling | Wrap it or choose another library |
| Registry package differs from repo | Ask the maintainer, consider avoiding |
Note that a clean skim is not clearance. It reduces the chance of an obvious problem, and it works best with a sandbox run and publisher checks.
Where to spend the effort
You will not skim everything, so choose. Prioritize packages that handle untrusted input, run at install time, touch secrets, or sit in your authentication and payment paths. Packages that are only used in a build step on an isolated machine can get less.
Try it yourself
Open the demo and look at the inventory of packages. Decide which rows deserve a skim first.
Click through it at your own pace, or open it full screen.
Quick check
Why compare the registry package with the repository?
Because the code you install comes from the registry artifact. If it contains files that are not in the repository, you cannot rely on what you reviewed.
Are TODO comments a security problem?
Not on their own. The OpenSSF guide lists many TODO statements as a sign of incomplete or insecure code, so treat a lot of them in core paths as a prompt to look closer.
Safeguard's SBOM and dependency scanning finds known vulnerabilities in the packages you use, and its policy gates can enforce rules on dependency changes in pull requests. Try the free scan.
Sources
Last reviewed: 19 October 2026.
