Check dependencies in this order: components in internet facing or shipped products, components whose vulnerable code is reachable, unmaintained or archived projects, unidentified components, and last, everything else. A triage order turns a thousand line inventory into a one page list.
The problem with raw inventories
A typical application inventory runs to hundreds or thousands of entries, most of them transitive. Reading top to bottom wastes the review. You need a rule for what to read first.
Triage order
| Priority | Group | Why first |
|---|---|---|
| 1 | Components in products customers use or that face the internet | Highest exposure |
| 2 | Components with a known vulnerability whose code is actually called | Real, not theoretical |
| 3 | Components that are archived or unmaintained | Nobody will fix future issues |
| 4 | Components with no identifiable source or license | Cannot be reviewed at all |
| 5 | Everything else | Sample, do not read |
Using reachability
A vulnerable function that the application never calls is a different case from one on a hot path. The OpenVEX specification has a justification label for exactly this, vulnerable_code_not_in_execute_path, meaning the vulnerable code cannot be executed as used by the product. Reachability analysis produces evidence for such statements. Ask the seller whether they have any, and check them rather than accepting them.
Using maintenance signals
The OpenSSF Scorecard Maintained check scores a project on recent activity: an archived project receives the lowest score, and at least one commit per week over the previous 90 days earns the highest. It labels the risk as high because of possibly unpatched vulnerabilities. It is a signal, not a verdict. A small, finished library can be stable and quiet. Look at the dependency's role: a stable parser deep in the stack is a different case from an abandoned authentication library.
A one page output
Produce this for the deal team:
- Top ten components by exposure with one line each.
- Count of unmaintained components and which ones sit in shipped code.
- Count of unidentified components.
- Known vulnerabilities with reachable code, and their status.
- What you did not check.
Item five matters. Naming what was out of scope protects the reader from assuming coverage.
Common mistakes
- Sorting by severity score alone. A critical score on unreachable code can outrank a moderate one on a login path only if you ignore context.
- Ignoring transitive dependencies because they are not in the manifest.
- Treating a quiet repository as dead without reading why.
Safeguard's reachability analysis and vulnerability management view are built for this sorting. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability is applied.
Quick check
Is an unreachable vulnerability safe to ignore?
Not forever. Code paths change. Record it with a reason and a review date.
How many components can one reviewer cover?
Triage reduces the list to what one person can read in a day. Sample the rest rather than reading it.
Sources
Last reviewed: 19 October 2026.
