You can start with free tools: pip-audit for Python, OSV-Scanner for many other lock file types, CISA's KEV catalog for known exploited issues, and EPSS for likelihood. A monthly hour of work with these covers the dependency layer of most lab projects.
What each free piece does
| Piece | What it does | Limit |
|---|---|---|
| pip-audit | Audits Python environments and requirements files, can output CycloneDX | Python packages only, not non-Python libraries |
| OSV-Scanner | Reads many lock files and can scan container images | Conda is not listed among supported lock files |
| CISA KEV catalog | Lists vulnerabilities exploited in the wild | One input, not the whole process |
| EPSS | Probability of exploitation in the next 30 days | A probability, not a guarantee |
pip-audit says it is not a static analyzer or a defense against malicious packages. OSV-Scanner's documentation lists lock files for languages including Python, R, Go, Rust, Java, JavaScript and Ruby, and says container image scanning also covers installed artifacts.
The one hour routine
- Collect (10 minutes). For each active project, make sure a lock file or pinned list is committed.
- Scan (10 minutes). Run the auditor per project and save the output.
- Filter (15 minutes). Check findings against the KEV catalog and sort by EPSS score within each project.
- Decide (20 minutes). For each top finding: update, defer with a reason, or accept.
- Record (5 minutes). Put decisions in a shared file with dates.
pip-audit -r requirements.txt
osv-scanner scan source -L package-lock.json
What this routine does not cover
Be clear about gaps, because free tools leave some.
- Servers and operating system patching, which need your IT team.
- Configuration problems and weak passwords.
- Secrets accidentally committed to repositories. Check with your hosting platform's own features.
- Custom code flaws, which need code review or a separate scanner.
- Software with no lock file, which you must first inventory by hand.
When free stops being enough
You will likely feel it when the project count grows past what one person can read, when results need to be shared with a funder, or when the same finding appears in dozens of repositories and you need to see them together. At that point, a platform that aggregates and prioritizes saves time.
Making the results useful to others
A funder, collaborator or institutional security office may ask what you do about vulnerabilities. A shared file with the monthly decisions answers that without a meeting. Keep three columns: finding, decision, date. Add the CycloneDX output from pip-audit if you want a machine readable record to attach.
Avoid chasing a zero finding count. A reasoned list of decisions is a better measure of a healthy lab than an empty report, because an empty report usually means the tool did not see something.
Where to put the effort first
If an hour a month feels like too much, start smaller. Scan only projects that run as services or that other labs download, since those have outside users. Add the rest once the first routine is working. Small, steady habits find more over a year than one large audit that nobody repeats.
Keep the commands in a short script in the repository so a new student can run the routine without asking. Version the script with the code.
Where Safeguard fits
Safeguard's free scan lets you try dependency scanning with reachability on one project at no cost, and compare it to your manual routine.
Quick check
Can free tools replace a security team?
No. They cover the dependency layer. Operating systems, configuration and incident response still need people.
Which project should I scan first?
The one with a public facing service or the most users, since exposure drives risk.
Sources
- pip-audit project page
- OSV-Scanner supported languages and lockfiles
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS
Last reviewed: 19 October 2026.
