Building Security into the Firmware SDLC
Security bolted on at the end of a project is expensive, incomplete, and resented. Building it into the firmware development lifecycle from the start is cheaper, more effective, and far less painful. The idea is simple: make security a consideration at every stage rather than a gate at the end. Here is what that looks like for firmware, stage by stage.
Why Bolt-On Security Fails
The common pattern is to build the product, then run a security test near the end and scramble to fix whatever it finds. This fails for predictable reasons: the expensive mistakes, the ones baked into the hardware and architecture, are already locked in, and the cheap window to fix them has closed. A test at the end finds problems when they are most costly to address.
Building security in throughout is the same shift that quality went through decades ago: you cannot test quality in at the end, you have to build it in. Every stage of the firmware lifecycle has a security activity that, done then, prevents a class of problems that would otherwise surface expensively at the end or in the field.
Design: Threat Model First
The lifecycle starts at design, and so does security, with a threat model. Before the architecture is set, identify the assets, the attackers, and the threats, and let that analysis shape the design decisions that are about to become permanent: where keys live, whether there is a hardware root of trust, how the device boots and updates.
This is the highest-leverage security activity in the whole lifecycle, because design decisions are the hardest to change later. A threat model done now, when the architecture is still fluid, costs a few sessions and prevents the structural flaws that no amount of later testing can fix cheaply. Skipping it is how teams end up with keys in flash and no way to lock debug.
Requirements: Write Security Down
The threat model’s output becomes security requirements, written and testable, that sit alongside the functional ones. Each threat gets a requirement that mitigates it, specific enough to implement and verify, and anchoring them in a standard like the OWASP ISVS gives a vetted baseline to build on. The requirements document is the contract that makes security a deliverable, traceable from the threat that motivated it to the test that confirms it, which is what keeps it from being dropped under schedule pressure.
Implementation: Secure Coding and Reuse
During implementation, security means safe coding patterns for memory and input handling, treating every input that crosses a trust boundary as hostile, and careful handling of reused code. Third-party and SDK code, often the bulk of an embedded image, is where many vulnerabilities hide and where teams have the least visibility, so maintaining a software bill of materials, knowing exactly what components and versions are in the image, is what lets you respond when one of them has a vulnerability disclosed instead of not knowing whether you are affected.
Build: Automate the Checks
The build pipeline is where security checks become automatic and consistent: static analysis catches dangerous patterns, dependency scanning flags known-vulnerable components, and build-time rules can fail the build if debug services survive into a release image.
# example CI security gates for a firmware build
- run: cppcheck --enable=warning,portability --error-exitcode=1 src/
- run: scan-build make # static analysis on the build
- run: dependency-check --failOnCVSS 7 # flag known-vulnerable components
- run: ./ci/assert-no-debug-services.sh release.bin # no telnetd or debug in release Gates like these catch whole classes of mistakes before they ship, at no per-release human cost. The build that strips debug services, fails on a high-severity dependency CVE, and rejects dangerous code patterns is doing security work continuously, which is exactly the kind of consistent enforcement humans are bad at and automation is good at.
Test: Verify against the Requirements
The testing stage verifies the security requirements rather than testing security generically. Each requirement, secure boot rejects unsigned images, the debug port is locked, updates enforce anti-rollback, has a test that confirms it, and those tests run as part of the release process. Fuzzing the input parsers belongs here too, finding the memory bugs before an attacker does.
Tying tests to requirements gives traceability and coverage: every identified threat has a requirement and every requirement has a passing test. A dedicated penetration test still has value as an independent check, but it should confirm a product that was built securely, not discover that it was not, which is the difference between a clean test and a fire drill.
Release: Sign and Document
At release, the security-critical steps are signing the firmware so devices can verify it, and capturing the evidence, the SBOM, the test results, the version, that supports both verification and future vulnerability response. This is also where provisioning meets the lifecycle: the keys that sign the release have to be protected, ideally in a hardware security module and a controlled signing service, because a release process that signs from a key on a developer’s laptop has undermined the verified boot the whole design relied on.
Post-Release: Handle Vulnerabilities
The lifecycle does not end at release, because vulnerabilities will be found in fielded devices. A mature process includes a way to receive reports, a coordinated disclosure practice, the ability to assess and communicate risk, and a path to deliver fixes through the secure update mechanism the design built in. This postmarket capability is increasingly a regulatory expectation, and it is what makes the earlier investment in a deliverable update mechanism pay off.
Where You Stand: A Maturity Self-Check
Teams often want to know where they stand before overhauling anything. Walk each lifecycle stage and rate whether the security activity happens not at all, informally, or consistently. The stage that scores lowest is usually where the next incident is incubating.
| Stage | The question to ask |
|---|---|
| Design | Is a threat model produced and actually used? |
| Requirements | Are security requirements written and traced? |
| Build | Static analysis and dependency scanning running in CI? |
| Test | Requirements verified and input parsers fuzzed? |
| Release | Firmware signed and an SBOM captured? |
| Post-market | Vulnerability disclosure and an update path in place? |
A row rated none is a concrete starting point, and design or post-market are the most common gaps, exactly the two stages that prevent the most expensive failures.
Start Small, Add Gates over Time
Adopting a full secure lifecycle at once is daunting, and teams that try tend to bounce off it. The practical path is incremental: add one automated build gate this release, write a threat model for the next new feature, introduce a requirements doc for the next product. Each addition is small, each prevents a class of problems, and the team experiences each gate catching real issues rather than being handed a heavy process to resent. Over a few release cycles the gates accumulate into a genuine secure development lifecycle, grown rather than imposed, which is the version that survives contact with deadlines.
Where This Fits
Helping teams build security into their firmware development lifecycle, from threat modeling through postmarket response, is the secure-development side of what I do. If you want to build security into your process rather than bolt it on at the end, that is the kind of work we do at Berkner Tech.
