SBOMs for PLCs and HMIs: What’s Realistically Possible

The Software Bill of Materials (SBOM) is becoming a cornerstone of cybersecurity transparency — listing every component and dependency within a product. But applying SBOM principles to PLCs, HMIs, and embedded controllers isn’t straightforward.

Why SBOMs Matter in OT

• Provide visibility into firmware components and third-party libraries.
• Enable faster vulnerability triage when new CVEs are published.
• Support NIS2, IEC 62443-4-1, and U.S. Executive Order 14028 compliance.

Challenges in Industrial Devices

• Proprietary firmware: Vendors rarely disclose full dependency lists.
• Legacy devices: Older PLCs predate secure development requirements.
• Offline environments: Dynamic SBOM updates can’t reach air-gapped systems.

Practical Approaches

• Request component-level SBOMs from vendors during procurement.
• Use firmware analysis tools (Syft, Binwalk, CycloneDX) to generate partial SBOMs.
• Correlate library fingerprints (OpenSSL, BusyBox, libc) to known CVEs.

Example Scenario

A manufacturer created SBOMs for its HMIs using firmware extraction and SPDX tagging. When CVE-2023-0464 (OpenSSL) emerged, affected units were isolated in under an hour.

Related Articles

• Prioritizing Patches in OT: Risk, Windows, and Rollback
• Vuln Scanning without Breaking the Plant: Safe Methods
• Asset Inventories That Stay Up-to-Date in OT

Conclusion

SBOMs in OT aren’t perfect — but partial visibility is better than none. Even a basic inventory of third-party libraries can dramatically improve patch prioritization and vendor accountability.