Triage by exposure and fix speed, not by team. Usually the backend comes first because you can patch it in hours, then the app because users must update it, then firmware because it is slowest to ship. If the firmware is the one place the flaw is reachable from the internet, move it up.
Three parts, three speeds
| Part | How fast can you fix? | Why |
|---|---|---|
| Backend | Hours to a day | You control the deploy |
| Companion app | Days to weeks | Store review, then users must update |
| Firmware | Weeks, sometimes longer | Test on hardware, staged rollout, device must be online |
Fix speed tells you what to start early. Exposure tells you what to do first. A flaw reachable from the open internet on your backend beats a flaw that needs physical access to a device.
The triage questions
- Is the vulnerable component in each part? Use the SBOM for each. A single library may be in two or three.
- Is the vulnerable code reachable? A function you never call is a lower priority than one on a network path.
- Who can reach it? The internet, a nearby radio, a paired phone, someone with a cable.
- Is it being exploited? If yes, the order changes and the timeline shortens. The Commission says reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, so involve counsel.
- Is a mitigation available? A config change or feature flag can buy time for the slower parts.
A worked pattern
Suppose an advisory names a parsing library used in your backend and your firmware. The backend takes untrusted uploads, the firmware parses data from a paired app. Patch the backend today. Ship the app update if it bundles the library. Schedule the firmware fix for the next staged release, with a mitigation that tightens pairing in the meantime. Write down why.
Watch for the slowest path
Firmware is slow, so start its work in parallel rather than after the backend is done. On day one, ask the firmware owner to check whether the component is present and to prepare a bench build. If the answer is that it is not reachable, you saved time. If it is reachable, you are already a few days ahead on the longest task.
Keep the decision record
For each advisory note the date, the component, which parts are affected, the exposure and the decision. It becomes your answer to a buyer who asks how you handle vulnerabilities, and your evidence during an audit.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how reachability moves a finding up or down your list.
Safeguard's reachability analysis and dependency scanning cover the backend and app repositories you connect, which speeds up the first two questions above. Vendor binaries in firmware still need your own record.
Quick check
What if firmware is the most exposed part?
Then start there, and use mitigations in the backend and app to reduce exposure while the firmware fix is tested.
Do we need three separate processes?
One process with three owners works better. A single decision record avoids contradictory answers.
Sources
Last reviewed: 19 October 2026.
