Start from what your project actually calls, not from the count of advisories. Reachability analysis checks whether your code can reach the vulnerable function, so you can fix reachable findings first and schedule the rest. ML projects benefit because their dependency trees are wide and much of each library goes unused.
Why ML trees are noisy
A single framework install brings dozens of packages. Add data tools, plotting libraries, experiment trackers and a notebook server, and the tree grows quickly. Each package has its own advisory history, and a scanner will report all of it.
Many of those findings sit in code your project never runs: an image decoder in a text only service, a plotting backend on a headless server. Sorting them by severity alone puts equal pressure on all of them.
A four question method
- Is the package in the shipped runtime? Training only libraries in a build stage may not ship.
- Does your code call the affected function? This is the reachability question.
- Can an attacker control the input? A parser fed only your own files is lower exposure than one that handles user uploads.
- Is a fix available, and what does it cost to adopt? Some upgrades are a patch bump, others change an API.
| Answer pattern | Priority |
|---|---|
| Reachable, attacker controlled input, fix available | Fix now |
| Reachable, internal input only | Fix in the next cycle |
| Not reachable, in runtime | Track, fix with routine updates |
| Not in runtime | Remove or ignore with a note |
Do not skip the artifacts
Reachability covers libraries. It does not cover the pickle checkpoint someone downloaded or the notebook with an install cell. Keep those in the inventory too. See our guide to building an ML dependency inventory.
A note on what is and is not a vulnerability
PyTorch's security policy is a good reminder that the framework's own maintainers draw lines. It says that using PyTorch securely is not itself a vulnerability, and that crashes from invalid inputs, denial of service through resource consumption and similar issues should be filed as regular bugs. When you read an advisory for any framework, check which category the maintainers put it in before you decide how urgent it is.
Record the decision
For each finding you defer, write down why. A short line such as "not reachable, confirmed 19 October, revisit on next framework upgrade" saves the next person an hour and gives an auditor something to read.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list of findings shrinks once reachability is applied, and notice which ones remain.
Where Safeguard fits
Safeguard offers dependency scanning with reachability analysis, SBOM generation and policy gates. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can I ignore every unreachable finding forever?
No. Code changes can make a path reachable later. Keep a note and re-check when you upgrade or refactor.
Does reachability apply to model files?
It applies to code in libraries. Model artifacts need their own review, such as source, format and hash.
Sources
Last reviewed: 19 October 2026.
