Secure SDLC for Embedded Devices

Embedded devices ship with software that may remain in the field for a decade or more. A vulnerability left in firmware at the time of manufacturing can become a critical security incident years after a product reaches consumers. Unlike web applications, embedded software rarely receives automatic updates, and the consequences of a breach often extend beyond data loss to physical safety, operational disruption, or regulatory action. This reality makes a structured secure SDLC essential for any organization building connected hardware, embedding security controls at every stage of development rather than treating them as an afterthought.

For product security, PSIRT, and compliance teams working in IoT, OT, automotive, or medical device manufacturing, the challenge is applying a secure development lifecycle to environments that combine custom hardware constraints, third-party components, and binary firmware blobs. This guide explains what software development lifecycle security means in that context, how it compares to DevSecOps, which practices matter most for firmware-based products, and how purpose-built tooling can make the entire process measurable and defensible.

Key Takeaways

• Define security requirements and threat models before code is written, examining physical interfaces, network services, update mechanisms, and cryptographic implementations
• Embed security throughout implementation via secure coding standards, static analysis, and software composition analysis integrated into the build pipeline
• Conduct comprehensive verification including fuzz testing, hardware-in-the-loop testing, and penetration testing with documented evidence of security requirement fulfillment
• Establish post-market monitoring processes to continuously track released firmware components against vulnerability databases and meet regulatory notification timelines like the Cyber Resilience Act's 24-hour reporting requirement
• Generate accurate Software Bills of Materials using binary analysis to capture all components—including third-party binaries and statically linked modules—that build system manifests often miss

What Is a Secure SDLC?

A secure SDLC (secure software development life cycle) is a development process that builds security into every phase of software creation, from requirements to post-release maintenance. It adds threat modeling, secure coding, security testing, and vulnerability management to the standard SDLC. The goal is to find and fix vulnerabilities early, when fixes cost less. For embedded devices, a secure SDLC also covers firmware, third-party components, and products that stay in the field for years.

SDLC, in its most basic form, describes the structured sequence of phases a development team follows to design, build, test, and maintain software. A secure development lifecycle extends this model by integrating security objectives, controls, and verification activities into each phase rather than running a single security review at the end of development.

In a conventional software development lifecycle without explicit security integration, vulnerabilities are often discovered late, when remediation is expensive and time-consuming. Embedding security from the requirements phase means that threat models inform design decisions, secure coding standards govern implementation, and automated scanning catches issues before code reaches production firmware. The result is a measurable reduction in the vulnerability density of released products and a defensible process that regulators and customers increasingly expect to see documented.

For embedded device manufacturers, a secure development lifecycle must address concerns that traditional software development teams rarely face. Firmware often incorporates open-source libraries, commercial off-the-shelf components, and binary blobs from chipset vendors. The supply chain is complex, and the SDLC framework must account for inherited vulnerabilities from upstream components, not just code written in-house. Standards such as IEC 62443-4-1 for industrial automation and ISO/SAE 21434 for automotive have codified these expectations, making a documented secure development lifecycle a compliance requirement rather than simply a best practice.

A secure SDLC typically covers five phases:

• Requirements gathering: Defining security objectives alongside functional ones before any code is written.
• Design: Using threat models to inform architectural decisions and security controls.
• Implementation: Applying secure coding standards and automated scanning during development.
• Verification: Testing against defined security requirements before release.
• Deployment and maintenance: Monitoring shipped products for newly discovered vulnerabilities over their full lifespan

Secure SDLC vs. DevSecOps

The terms secure SDLC and DevSecOps are often used interchangeably, but they describe related rather than identical concepts. A secure development lifecycle is a framework: a defined set of phases, activities, and gates that govern how software is developed from conception through retirement. DevSecOps is a cultural and operational model that applies security practices continuously within an agile or CI/CD pipeline, using automation to shift security left and integrate it into every commit, build, and deployment.

In practice, DevSecOps tools such as static analysis scanners, software composition analysis platforms, and container security tools are the mechanisms through which software development lifecycle security is implemented in a fast-moving development environment, and managing a firmware SBOM in DevSecOps is a critical part of making that process accurate and continuous. DevSecOps operationalizes the SDLC framework. Organizations that adopt DevSecOps without an underlying framework often have continuous scanning but lack the structured threat modeling, security requirements, and post-market monitoring processes that a complete lifecycle demands.

For embedded device teams, the distinction matters because firmware development cycles frequently do not resemble a typical web application pipeline. Build times are longer, hardware-in-the-loop testing introduces delays, and release gates are more formal given regulatory requirements. A well-defined SDLC framework gives teams the structure they need to satisfy regulators such as the European Cyber Resilience Act, while DevSecOps tooling helps automate the security activities within that structure. Both are necessary, and neither is sufficient alone.

The Phases of a Secure Development Lifecycle

Applying security controls across a full development lifecycle requires adapting each phase to the realities of firmware, constrained hardware, and long product lifespans.

Requirements and Threat Modeling

Security requirements must be defined before a single line of code is written. At the requirements phase, teams identify the assets the device must protect, the threat actors most likely to target those assets, and the security properties the product must demonstrate. These requirements feed directly into design decisions and provide the baseline against which later testing is measured. Without them, security activities later in the lifecycle lack a clear target.

Threat modeling formalizes the process of identifying how an attacker might compromise a device, and understanding the role of threat modeling in the SDLC is essential for teams working with complex, multi-interface embedded products. For an embedded device, this means examining:

Design decisions made at this stage, such as secure boot implementation, memory protection unit configuration, and encrypted storage layout, are far cheaper to get right early than to retrofit after silicon is taped out. Teams that treat security requirements as optional or defer threat modeling to later phases consistently find themselves redesigning hardware or accepting known risks in shipped products.

• Physical interfaces such as JTAG and UART that provide low-level hardware access.
• Network-facing services exposed over Wi-Fi, Ethernet, Bluetooth, or cellular connections.
• Update mechanisms that could be exploited to deliver malicious firmware.
• Cryptographic implementations where weak algorithms or key management flaws create systemic risk.

Implementation, Verification, and Release

During implementation, secure coding standards define how developers write and review code. For embedded C and C++, this means enforcing rules around memory management, integer overflow handling, and safe use of external libraries. Static analysis tools integrated into the build pipeline catch common vulnerability classes automatically, reducing the burden on code review while creating an audit trail that satisfies compliance documentation requirements.

Verification covers both dynamic testing and binary analysis. The following activities all belong at this phase:

For products subject to IEC 62443-4-1 or the Medical Device Regulation, the verification phase must produce documented evidence that security requirements have been met. Test cases derived from the original threat model close the loop between what was planned and what was tested.

Release gates enforce a minimum security posture before firmware ships. This typically includes a clean software composition analysis report, a complete and accurate Software Bill of Materials generated with a reliable SBOM management tool, and sign-off on any accepted residual risks. Automating these gates within a CI/CD pipeline reduces the friction of compliance while ensuring that no release bypasses the required checks. Release is also the point at which post-market monitoring processes are initialized, establishing the baseline for vulnerability tracking against the shipped SBOM.

• Fuzz testing of network interfaces and parsers to surface unexpected input-handling failures.
• Hardware-in-the-loop testing of update mechanisms under realistic conditions.
• Penetration testing of exposed services to validate real-world attack resistance.

Post-Market Monitoring

For embedded devices, shipping firmware is not the end of security responsibility. Products remain in the field for years, and new vulnerabilities are discovered in third-party components on a continuous basis. Post-market monitoring means actively tracking the components in every released firmware version against vulnerability databases such as the National Vulnerability Database, and triaging new CVEs as they are published against the device's known component inventory.

An effective post-market monitoring process depends on the accuracy and completeness of the SBOM generated at release, and automated vulnerability management against that inventory is what makes continuous post-market oversight operationally feasible at scale. If the SBOM does not accurately reflect what is inside the firmware binary, vulnerability matching will produce both false positives and false negatives. Automated binary analysis tools that extract component data directly from firmware images, rather than relying solely on build system metadata, provide the level of accuracy that effective post-market monitoring requires.

The Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities within 24 hours and to notify of security incidents within 72 hours. Meeting these obligations without a structured post-market monitoring process is operationally very difficult. Teams that have built monitoring into their SDLC framework from the start are in a far stronger position to meet these timelines than those attempting to reconstruct component inventories after a vulnerability is published.

Secure SDLC Best Practices for Firmware

Firmware introduces constraints that make several standard software development lifecycle security practices harder to apply and several others more important.

Analyzing binaries without source code is a routine challenge for embedded security teams. Third-party components, chipset vendor libraries, and legacy modules frequently arrive as compiled binaries with no accompanying source. Traditional static analysis tools cannot analyze these components directly. Binary analysis techniques, including binary Software Composition Analysis and symbolic execution, extract component identities, version strings, and known-vulnerable code patterns from compiled firmware images without requiring access to source code.

Generating a Software Bill of Materials for every release is now an explicit requirement under multiple regulatory frameworks. The SBOM must capture:

For firmware, this requires analysis of the binary image itself because build system manifests often miss components that are statically linked or embedded without explicit dependency declarations. An SBOM generated from binary analysis reflects the true composition of the shipped product rather than what the build system believes it contains.

CRA and IEC 62443-4-1 compliance expectations converge on several key requirements:

IEC 62443-4-1 defines a Security Development Lifecycle for industrial products that maps closely to the phases described in this guide. The CRA extends similar requirements to virtually all connected products sold in the European Union. Teams that have implemented a documented SDLC framework are far better positioned to demonstrate compliance with both standards than those relying on informal processes.

• First-party components developed internally, including version and build metadata.
• Open-source libraries integrated directly or transitively into the firmware image.
• Third-party binaries and statically linked modules that build system manifests often miss.
• Documented security requirements established before development begins.
• Structured threat analysis using recognized methodologies such as STRIDE or TARA.
• Vulnerability management processes covering both development and the post-market phase.
• A defined coordinated vulnerability disclosure policy that meets regulatory notification timelines.

How ONEKEY Supports the Secure SDLC

ONEKEY is a firmware analysis platform built specifically for the security requirements of embedded device manufacturers. It automates the analysis of firmware binaries, extracting detailed component inventories, generating SBOMs, and mapping discovered components against known vulnerabilities from multiple threat intelligence sources. This capability addresses the single most common gap in embedded secure SDLC implementations: the inability to accurately assess what is inside a firmware binary without source code access.

Within the implementation and verification phases, ONEKEY integrates with CI/CD pipelines to provide automated firmware analysis at every build. Security teams receive a structured vulnerability report and SBOM for each firmware version, creating a continuous record of the security posture of every release candidate. Release gates can be configured to block firmware builds that exceed defined vulnerability thresholds, enforcing security requirements automatically rather than depending on manual review.

For post-market monitoring, ONEKEY continuously tracks the component inventory of released firmware versions against updated vulnerability intelligence. When a new CVE is published against a library version present in a shipped product, security teams are alerted immediately with context about affected products and severity. This capability directly supports the notification timelines required by the Cyber Resilience Act and provides the documented evidence of ongoing vulnerability management that IEC 62443-4-1 and ISO/SAE 21434 require. ONEKEY makes the secure SDLC operational for teams building complex, multi-component firmware products in regulated markets.