When to run it
A CVE in an RTOS, network stack, crypto library or vendor SDK that ships inside deployed devices.
A CVE hits your fleet.Patch, prove, and roll out.
Patching a firmware CVE and shipping it over the air
The playbook in one paragraph
A vulnerability lands in a component your devices ship. Ana finds every affected firmware build from the SBOM, patches and tests it, and stages an OTA rollout that stops itself if devices misbehave.
Works with
- Firmware SBOMs
- Build systems (CMake, Yocto, Zephyr west)
- HIL test rigs
- OTA platform
What Ana needs from you
- Affected component and advisory
- Device fleet segmentation
- Rollout policy and health signals
How Ana runs it
Step by step.
5 steps from trigger to done - each one visible to your team as it happens.
- 01
Find exposure
Ana searches firmware SBOMs for the affected component and versions and checks whether the vulnerable code is compiled in and reachable on each product.
- 02
Patch
Ana applies the upstream fix or backports it to the version you ship, and rebuilds every affected variant.
- 03
Regression test
Unit, SIL and HIL suites run on every variant, plus a test that exercises the vulnerability.
- 04
Stage the rollout
Ana prepares a staged OTA rollout - internal devices, a small cohort, then the fleet - with automatic halt on health-signal regressions.
- 05
Document
The advisory, exposure analysis, patch, test results and rollout record are packaged for your security and regulatory files.
Who approves what
Approval gates
- Patch merge
- Embedded lead
- Each rollout stage
- Release owner
- Customer advisory
- Product security / legal
What you get
Deliverables
- 01Exposure analysis per product
- 02Patched builds for every variant
- 03HIL-verified test results
- 04Staged OTA plan and rollout record
What usually goes wrong
And how Ana handles it.
Risk
Bricking devices with a bad update
Staged cohorts and automatic halt on health signals limit the blast radius.
Risk
Missing a variant
Exposure is computed from SBOMs across every build, not from memory.
FAQ
Common questions.
Ana prepares and stages the rollout through your OTA platform; each stage is approved by your release owner.
Keep going
Related playbooks.
Embedded
From DOORS requirements to verified firmware
A new feature arrives as a set of requirements. Ana designs the change, writes the firmware, runs it through unit, SIL and HIL tests, and keeps a trace from every requirement to the code and test that satisfy it.
Read the playbook →Software
Upgrading a framework across dozens of services
A major framework or runtime version is going end-of-life and it touches every service. Ana plans the migration, upgrades each service in its own branch, fixes what breaks, and hands your team small, tested pull requests instead of one terrifying diff.
Read the playbook →Software
Burning down a stale bug backlog
Every team has a backlog of real but low-priority bugs that never win a sprint. Ana triages them, reproduces the ones that are still real, fixes them with tests, and closes the rest with evidence.
Read the playbook →See it in your stack
Run this playbook on your systems.
Thirty minutes, your repositories and cloud, one real instance of this job.