To build a dependency scanning lab, create a small project with a few packages, run the audit command your package manager provides, then cross-check results against a public advisory database. Record what you find, fix one issue, and rerun. The whole loop fits in an afternoon on a laptop.
What you need
- A laptop and a text editor.
- A language runtime you know, such as Node.js or Python.
- A throwaway project folder that holds no real secrets.
- A notes file where you log each finding.
Step 1: create a small project with real dependencies
For Node.js, run npm init, then install three or four common packages. For Python, create a virtual environment and a requirements file with a few pinned older versions. Older pins make the exercise more interesting because they are more likely to appear in advisories.
Step 2: run the built-in audit
In a Node.js project, npm audit sends a description of your dependencies to your default registry and asks for a report of known vulnerabilities. If it finds any, it calculates their impact and a remediation. By default it exits with a non-zero code when vulnerabilities are found, which is how CI jobs use it.
npm audit
In a Python project, pip-audit scans environments and requirements files for packages with known vulnerabilities. Its README says it analyzes dependency trees, not code, and it uses the PyPI advisory data by default or OSV if you ask for it.
pip-audit -r requirements.txt
Step 3: understand what the tools do not see
pip-audit does not detect transitive vulnerabilities in non-Python shared libraries, according to its own documentation. npm audit reports only what its advisory source knows. Write one line in your notes about each tool's blind spot. That habit is what separates a lab from clicking a button.
Step 4: cross-check with a database
OSV aggregates vulnerability databases that use the OpenSSF vulnerability format and offers an API and a first-party scanner. Run a second tool on the same project and compare the lists. Differences teach you more than agreement does.
Step 5: fix one finding and prove it
Pick one finding with a fixed version listed. Upgrade, rerun the audit, and confirm the entry is gone. Then run your tests, because a fix that breaks the app is not a fix. Note that the automatic fix in npm, without extra flags, will not change dependency ranges, and forcing it can install major version updates, so read the diff first.
Step 6: record it
For each finding, log the package, the installed and fixed versions, the advisory ID, and one sentence on whether your project calls the vulnerable code. That last field is the skill employers care about.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can run a free scan on your lab project to compare its output with your audit results.
Try it yourself
Open the demo to see how a dependency inventory is built and how each package is linked to its advisories.
Click through it at your own pace, or open it full screen.
Quick check
Is it safe to run these audits on any project?
Yes for projects you own or have permission to scan. Note that npm audit sends your dependency list to the registry.
Why did two tools give different results?
They use different advisory sources and matching rules. Compare both and investigate the gaps.
Sources
Last reviewed: 19 October 2026.
