Patch first where four things line up: the vulnerable component is in a shipped release, the vulnerable code is reachable in how the device runs, the device is exposed to the network or attacker, and there is evidence of active exploitation. Findings that fail the first two tests can usually wait or be marked not affected.
Definitions
Present means the component is in the release SBOM. Reachable means your code calls the vulnerable function or path. Exposed means an attacker can get to it, through a network service, a local interface, or a connected app. Exploited means a trusted source reports active attacks.
Why firmware needs this
Firmware images pull in whole libraries to use one function. A scanner that matches versions will list every advisory for the library. Most are in code your device never runs. Without a reachability test, your queue is long and the real risks are buried.
Triage order
| Step | Question | If no |
|---|---|---|
| 1 | Is it in a release still in the field? | Close |
| 2 | Is the vulnerable code compiled in? | Document as not affected |
| 3 | Is it reachable from your code? | Lower priority, add a review date |
| 4 | Is the device exposed to it? | Lower priority |
| 5 | Is it known to be exploited? | Normal cycle, otherwise emergency |
Steps
- Take the affected releases from your SBOM lookup.
- For each, check build flags and configuration: many embedded libraries have optional modules that are compiled out.
- Run reachability analysis on your source and the dependency to see whether a path exists.
- Add exposure from your device documentation: open ports, services, radio interfaces.
- Record the decision with a reason and a date. For not affected decisions, use a standard exploitability statement so customers can read it.
- Revisit when the code changes, since reachability is not permanent.
Caveats
Reachability tools are weaker on firmware written in C with heavy macros and function pointers, so treat a negative as a strong hint and not a proof. For high impact components, confirm with a test or a code review. Also, compiled out is different from unreachable: say which one applies.
Keep the reasons
Write down why each finding was ranked as it was: compiled out, reachable, exposed, or exploited. Later, when a customer asks why a listed library was not patched, you can answer with facts. When code changes and a not reachable decision no longer holds, the stored reason tells you which assumption broke. Reasons also help new team members learn how your devices actually use their dependencies.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability filtering. The gap is the queue you do not have to work today.
Safeguard offers reachability analysis and dependency scanning on SBOMs. Try gold.safeguard.sh/scan.
Quick check
Is a library listed in the SBOM always a risk?
No. The vulnerable part may be compiled out or never called. Check before ranking it.
Can I trust a not reachable result for C firmware?
Treat it as strong evidence and confirm for high impact components by test or review.
Last reviewed: 19 October 2026.
