Secure by Design: Enhancing Embedded Firmware Resilience with SBOM-Driven Security Analysis

Modern products are no longer built from a single codebase. They are assembled from thousands of open-source, commercial, and third-party components — often spanning multiple suppliers and jurisdictions. Managing this complexity is no longer just a security task. It is a compliance imperative. As embedded devices continue to permeate critical applications, ensuring their security from the earliest stages of development has never been more essential.

This talk explores practical strategies for building ESP32-based products that are “secure by design,” with a focus on integrating Software Bill of Materials (SBOM) practices into the firmware lifecycle. Attendees will learn how SBOM security analysis tools can uncover hidden vulnerabilities, strengthen supply-chain trust, and streamline compliance efforts. In this talk, Linusent Aura™ SBOM analysis and monitoring software is introduced.  Linusent Aura™ automatically generates accurate, machine-readable SBOMs, including direct and transitive dependencies. It supports industry standards such as SPDX and CycloneDX and consolidates SBOM data from internal systems, suppliers, and external partners into a unified compliance view. 

Using real-world examples from ESP32 firmware development, the session demonstrates how developers can incorporate automated analysis, dependency tracking, and continuous security validation to deliver robust and resilient embedded systems.

What this presentation is about and why it matters

How do you keep embedded firmware trustworthy when dependencies, vendor binaries, and vulnerabilities keep changing after release? Amir Alavi approaches that tension through a practical talk about SBOM-driven security analysis in embedded development, using ESP-IDF, CI/CD, and firmware supply chain workflows as the anchor. He moves from standards and lifecycle concerns to an example of generating and analyzing SBOMs, then shows how continuous monitoring changes the release story. This is especially useful if you work on connected devices, build pipelines, or compliance-heavy products, and want a clearer way to connect firmware development with ongoing security maintenance.

Who will benefit the most from this presentation

• Firmware engineers shipping connected devices who need to track third-party dependencies over time
• Build and release engineers who own CI/CD pipelines for embedded products
• Security engineers or product owners dealing with vulnerability management and compliance
• Embedded developers using ESP-IDF or similar SDKs and wanting SBOM generation in the workflow
• Team leads at vendors or device makers who need a way to bridge build-time and field-time security

What you need to know

Some familiarity with embedded firmware development and software supply chains will help. The talk moves quickly through standards, build workflows, and vulnerability analysis, so it is easier to follow if these terms are already part of your day-to-day work.

• Basic embedded development concepts, including SDKs, dependencies, and firmware builds
• General awareness of CI/CD pipelines
• Comfort reading about security terms such as CVE, vulnerability management, and compliance reporting
• Useful, but not required, exposure to ESP-IDF or SBOM concepts

Glossary (terms used in this talk)

• SDLC (Software Development Life Cycle): A structured process for planning, designing, implementing, testing, deploying, and maintaining software.
• RTOS (Real-Time Operating System): An operating system designed to provide predictable timing behavior for real-time applications.
• Software supply chain: The set of external and internal components, libraries, build inputs, and transitive dependencies that influence a software artifact. It matters because risk can enter through code that is not written in house and may change independently of the final product.
• Reachability analysis: A method for checking whether a known issue in a dependency can actually affect a released artifact, based on how code and symbols are used in the build. It helps separate actionable findings from unrelated noise.
• Vulnerability mapping: The process of linking components or versions to known vulnerabilities in external databases or feeds. It is a core step in turning inventory data into security insight.
• Bluetooth: A short-range wireless communication standard and protocol stack used by many embedded devices.
• LoRaWAN: A low-power wide-area networking protocol for long-range embedded and IoT connectivity.
• SBOM: Software Bill of Materials. A machine-readable inventory of components, dependencies, versions, suppliers, and licenses that comprise a software artifact.

Toolbox (mentioned in this talk)

• GitLab: A web-based DevOps platform for source control, CI/CD, and project collaboration.
• GitHub: A web-based platform for hosting Git repositories and collaborating on software development.
• FreeRTOS: A widely used real-time operating system for embedded systems. It is commonly integrated as a library that the application initializes and then starts scheduling tasks.
• Zephyr RTOS: A scalable real-time operating system for connected and resource-constrained devices. It often owns much of the system startup flow, including hardware initialization and thread setup.
• ESP32: A low-cost family of Wi-Fi and Bluetooth-enabled microcontrollers widely used for embedded networking and real-time control. It includes integrated wireless connectivity and is supported by a broad software ecosystem.
• CMake: A cross-platform build system generator that helps define and drive builds across different compilers, IDEs, and platforms.

Final thoughts

Practical and workflow-oriented, this session gives you a way to think about firmware security as something that lives alongside the build, not just inside the code review. The value is a clearer mental model for how dependency inventory, vulnerability intelligence, and release operations fit together, especially when binaries and vendor components are involved. It will help firmware teams, release managers, and security owners who need a more durable handle on embedded risk. The talk’s spirit is simple: security work does not end when the firmware compiles.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.