Security assessment of SBOM

[samiralavi]

Describe your idea

In recent years, many countries have required cybersecurity assessments for device manufacturers. If someone wants to use ESPHome in the ESP-based devices, they need to understand the vulnerabilities in the project dependencies and track them over the lifetime of their devices and provide remote updates to address those vulnerabilities. I would like to see the SBOM (Software Bill Of Materials) analysis report as part of the CI/CD workflow for ESPHome. The report can be publicly available or provided to people with a subscription to a mailing list. So every time a new release is created, the security report gets generated, and in the future, when vulnerabilities are found in a former release, they get notified to figure out a solution.

Why is this exciting?

This is exciting because it brings a level of security transparency to ESP-based open-source projects that has traditionally only been available through expensive commercial tools. By automatically generating SBOMs and continuously monitoring vulnerabilities for every release, ESPHome and related projects can offer device makers a level of assurance that normally requires significant investment. It dramatically lowers the barrier for manufacturers—large or small—to meet emerging cybersecurity regulations and confidently ship products built on open-source firmware.

What makes this idea game-changing is that it turns long-term security maintenance into an effortless, automated process. Instead of scrambling when a new CVE appears, maintainers and users get immediate visibility and actionable information. It transforms ESPHome from just a powerful firmware builder into a security-aware platform that supports real-world product lifecycles. Bringing this kind of supply-chain clarity to the open-source ESP ecosystem elevates the entire community and makes open-source firmware more viable for professional, commercial, and regulated environments.

Potential use cases

Automated SBOM generation and vulnerability tracking would be especially valuable for anyone building devices on top of ESPHome. A manufacturer that ships thousands of ESP-based devices often needs to prove compliance with security regulations, understand which components are inside their firmware, and know when new vulnerabilities appear in older releases. With automatic SBOM reports created for every release and ongoing monitoring against new CVEs, both maintainers and users gain immediate visibility into newly discovered risks. This makes it far easier to provide OTA updates, meet certification requirements in regions like the EU and US, and maintain devices in the field for many years.

Anything else?

I’m developing a free/open-source SBOM security assessment tool specifically for ESP-based firmware. Before I finalise the design for the first version (which I hope can be integrated into ESPHome), I’d like to understand whether this is something maintainers find useful and gather your feedback on the ideal workflow.

[nagyrobi]

Technically I agree with all the above, except one thing: if there's a company who makes its own profit bigger by saving software development costs using open source software ready as off the shelf in their products, let them pay at least the costs of SBOM.

[samiralavi]

@nagyrobi thanks for your support. The problem here is not cost and who to cover it, though, because collecting SBOM itself should be alright, and ESP-IDF itself provides basic functionality to export dependencies in SPDX format. The problem here is that ESPHome users need to be aware of when and which dependencies can be problematic to take the necessary action, for example, updating the version.

[nagyrobi]

Ok, but your argment is based on manufacturer that ships thousands of ESP-based devices… which in that case leverages that responsibility to that manufacturer and not the end users, nor the ESPHome devs or contributors (who do most of their contribution to the project for free, in their free time).
If you know what I mean.