SBOM has become a baseline requirement, but it still does not answer all the risk questions that matter for connected devices.
An SBOM tells you what software components are present. That is valuable, but it is only one part of the picture. In IoT and embedded environments, security decisions depend on where software runs, how the device is built, and what remediation paths are actually possible.
What SBOM does well
SBOM gives teams a structured inventory of software components and versions. It helps answer important questions like:
- What third-party software is in this release?
- Which versions are present?
- Which known vulnerabilities may be relevant?
That makes SBOM an essential input to vulnerability management. But it is still an input, not the full operating model.
Where SBOM alone falls short
- Hardware architecture can change exploitability.
- Some vulnerabilities are only relevant on specific processing units.
- Mitigation feasibility depends on firmware update capabilities and component role.
- Risk decisions require lifecycle context, not just a static inventory.
For example, the same vulnerable library can create very different risk depending on whether it runs on an externally exposed Linux-based MPU, an isolated microcontroller, or a component that is not reachable in the deployed architecture.
Why device context changes the decision
Security teams do not just need to know whether a component exists. They need to know whether the vulnerability is applicable, exploitable, reachable, and meaningful in the real device.
That requires context around the full device model: hardware modules, processing units, operating systems, firmware layers, interfaces, and how those elements interact.
Without that context, teams often end up with long vulnerability lists but weak prioritization. They see findings, but not enough operational truth to decide what must be fixed first.
Why lifecycle matters too
IoT security is not a one-time inventory exercise. Devices evolve through firmware releases, component replacements, configuration changes, and end-of-life decisions.
A useful vulnerability-management process must track what changed between versions, which vulnerabilities remain relevant, and which findings can be closed because components were updated or removed.
SBOM on its own does not provide that continuous lifecycle view. It needs to be part of a broader system that supports versioning, monitoring, and traceable decisions over time.
What teams actually need
Effective vulnerability management for devices usually requires:
- SBOM for software visibility
- HBOM or device-model context for hardware and execution environment
- vulnerability intelligence for exploitability and prioritization
- lifecycle tracking for changes across releases
- documented workflows for triage, remediation, and auditability
How ARIANNA approaches it
ARIANNA addresses this by linking SBOM and HBOM in one device model and continuously correlating them with vulnerability intelligence.
That gives teams a more accurate basis for prioritization, because findings can be evaluated in the real context of the product rather than as isolated software records.
Final takeaway
SBOM is necessary, but it is not enough on its own for IoT security.
Real vulnerability management depends on combining software inventory with hardware context, lifecycle awareness, and practical operating workflows. That is what turns a list of components into decisions a security team can actually trust.