The ones in code that handles untrusted input or student records and that your app actually calls: file and document parsers, authentication and session libraries, export tools, and anything that logs request data. A high score on a package your app never executes matters less than a moderate one on your upload path.
Why raw scores mislead
Scanners report every known flaw in every package in your tree. A typical project has far more findings than any small team can fix in a week. Severity ratings describe the flaw in general, not in your product. Three questions turn a list into a plan:
- Is the vulnerable component in the build that ships?
- Does your code, directly or through other libraries, call the vulnerable function?
- Could an attacker reach that path, and what would they gain?
The second question is reachability. It is the difference between a theoretical risk and one on your request path.
Where to look first in a student platform
| Area | Why it ranks high |
|---|---|
| Upload handling (images, documents, spreadsheets) | Takes files from users, often students or parents |
| Authentication and session libraries | A flaw can expose accounts across schools |
| Report and export generation | Bundles many student records into one file |
| Template and rendering engines | Often process user supplied text |
| Logging and error reporting | May capture student fields in request bodies |
| Roster and gradebook import tools | Parse files from school systems |
Where to look later
- Build and test tools that never ship to production. They matter for supply chain safety, but a flaw in them rarely exposes student data directly.
- Packages present in the lockfile but not imported by any code path.
- Findings that need local access or settings you do not use.
Later does not mean never. Schedule them.
A simple scoring routine
For each finding, add a point for each yes:
- Present in the production build.
- Called by your code or a library you call.
- Reachable from the internet or from a user upload.
- Touches student records or credentials.
- A fix or workaround is available now.
- Known exploitation is reported by a trusted source.
Fix the highest scores first and record why you deferred the rest. That written reason is useful if a district asks.
Keep it small
Remove packages you do not use. Every removed library is a set of findings you never have to triage. This is the cheapest security work available to a small team.
Try it yourself
Open the demo and compare the full list of findings with the list after reachability is applied. Notice how many fall away, and which ones remain.
Click through it at your own pace, or open it full screen.
Safeguard offers reachability analysis along with dependency scanning, and the free scan can show findings for a repository.
Quick check
Should we ignore findings that are not reachable?
Deprioritize, record, and recheck. Code paths change, so a finding that is unreachable today can become reachable after a refactor.
Is severity score useless?
No. It is one input. Combine it with presence, reachability, and the data involved.
Last reviewed: 19 October 2026.
