Start with an inventory, not a scanner. List what the lab runs, from analysis scripts to web portals to cluster tools, record each dependency version, then match that list against public vulnerability data and fix by exposure. Anything reachable from the network goes first.
Why labs are different from companies
A research lab rarely has a security team. It has a principal investigator, a few graduate students who rotate every few years, and software that outlives the people who wrote it. Code is often written to produce a result, then reused for the next paper.
That creates three recurring gaps. Nobody owns patching. Dependencies were installed once by hand and never recorded. And a server set up for one project quietly stays on the network for years.
A scan is only useful if it covers these gaps, so the first job is finding what exists.
Step 1: build the inventory
Walk through four places and write down what you find.
| Place | What to record |
|---|---|
| Code repositories | Language, manifest or lock file, who last committed |
| Shared servers and VMs | Operating system, exposed services, owner |
| Containers and environments | Base image, Conda or virtual environment name |
| Web apps and notebooks | URL, who can reach it, who can log in |
A spreadsheet is fine at this stage. The point is that every item has a named owner, even if the owner is a postdoc about to leave.
Step 2: scan what you can name
For each repository, scan the dependency manifest or lock file. Public vulnerability databases such as OSV are built for this: they collect records from many sources in one open format. The OSV project describes its goal as helping developers find known vulnerabilities in the third-party open source dependencies they use.
For servers, scan the operating system packages and any service that listens on a port. Ask your campus IT group first, because many institutions require approval before anyone scans network ranges.
Step 3: sort by exposure, not score
A high severity finding in a script that runs once on a laptop matters less than a medium one in a web service open to the campus. Sort in this order:
- Internet or campus facing services
- Shared systems with many users
- Code that handles sensitive or human subject data
- Everything else
CISA advises organizations to use its Known Exploited Vulnerabilities catalog as an input to prioritization, not the whole process. Check your findings against it, then work down your exposure list.
Step 4: decide what you will not fix
Some lab software cannot be upgraded without breaking a published method. That is a legitimate choice if it is written down. Record the finding, the reason, the compensating control (for example, no network access), and a review date.
Try it yourself
Open the dependency inventory demo and look at how a single project expands into direct and transitive packages. Notice how many entries you never chose yourself.
Click through it at your own pace, or open it full screen.
Safeguard can build a dependency inventory from your repositories and flag known vulnerable packages. You can try a free scan on one project to see what a first pass looks like.
Quick check
Do we need a paid tool to start?
No. An inventory spreadsheet and an open database lookup are enough to begin. Tooling helps once the list is too long to track by hand.
Can a student scan the campus network?
Not without approval. Ask your IT or security office first, and keep scans limited to systems your lab owns.
Sources
Last reviewed: 19 October 2026.
