Yes. A connected device is a system of firmware, a companion app and a cloud backend, and a flaw in any of them can expose customers. Put the backend's dependencies, container images and build pipeline in the same inventory as the firmware, and review all three when an advisory lands.
The three parts of a connected product
| Part | Typical dependencies | Who usually watches it |
|---|---|---|
| Firmware | RTOS or Linux base, vendor SDK, libraries | Embedded team |
| Companion app | Mobile libraries, analytics, crash tools | App team |
| Backend | Web framework, database drivers, container base images, cloud SDKs | Web or platform team |
In many startups the third row has the least attention from a hardware-minded security effort, yet it often holds the most data and the most internet exposure.
Why the backend matters to the device
The backend usually decides which devices may connect, hands out update metadata and stores customer information. If an attacker controls the update service, a signed-image check on the device is your last defence. The Update Framework lists attacks such as freeze, where an attacker keeps serving the same file so you never learn of an update, and rollback, where they serve an older insecure version. Defending against these needs both a careful device and a backend that cannot be quietly changed.
What to inventory
- Application packages in each backend service, with exact versions from lockfiles.
- Container base images and what they contain.
- Cloud SDKs and infrastructure code, including modules pulled from public registries.
- Build and deploy tooling, because it can touch production.
- Device identity and certificate tooling you run yourself.
A routine for one engineer
- Weekly: review new advisories against the backend inventory.
- Per release: block a deploy if a dependency has a critical, reachable issue with a fix available.
- Quarterly: remove packages you no longer use. Each dependency is an exposure you carry.
- On every advisory: write down whether the issue touches firmware, app, backend, or none.
Why one inventory helps
A shared component, such as a JSON or TLS library, can appear in the firmware and the backend. When one advisory names it, a single view tells you every place it lives. Three separate spreadsheets rarely stay accurate.
A short example
A team patches a TLS library in its firmware after an advisory, and moves on. The same library, in an older version, sits in a backend service that terminates device connections, because a different engineer set it up. Nobody connected the two. A single inventory that lists both places would have shown it within minutes. This is the practical argument for one view across all three parts of the product.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are grouped and prioritised in one place.
Safeguard's SBOM and dependency scanning, plus reachability analysis, work across the app and backend repositories you connect. Try a free scan on one repository to see the output.
Quick check
Is the backend really part of the supply chain?
Yes. Your backend pulls in third-party code, images and tooling, and customers trust it with device control and data.
Where should a two-person team start?
With the backend repository that handles device authentication and updates, because it is the most sensitive.
Sources
Last reviewed: 19 October 2026.
