The Firmware Update That Bricked Forty Pumps
A team maintains firmware for irrigation controllers sold to 40 schools. Controllers run unattended and open valves on a schedule. The team added a remote update feature that downloads a signed firmware image over HTTPS and installs it automatically on boot if the version differs from the installed one. The signing key is stored in the build server's environment variables and is also committed to the repository in a deploy/ folder so that "new developers can build releases." Update images are not versioned beyond a single integer, and there is no rollback path: if the new image fails to start, the controller retries the same download on the next boot. Last month a bad image caused all 40 controllers to loop, and a school's beds went unwatered for two days. The team's proposed fix is to add a longer retry delay.
1. Identify the security and reliability weaknesses in this design, and evaluate the proposed fix.
Read the worked answer
Several distinct weaknesses compound here.
Key management. A signing key committed to the repository is compromised by definition - anyone with repository access, or anyone who obtains a clone or backup, can sign firmware. The key should live only in a secrets manager, be inaccessible to ordinary developers, and ideally be held in hardware or an offline signing step. The "new developers need to build" justification confuses building with signing; builds do not require the release key.
No anti-rollback or version pinning. A single integer version with automatic install on any difference means a controller can be pushed backwards or loop on a bad image. There should be a monotonic version, a minimum-acceptable version, and a refusal to install anything older.
No rollback or fail-safe. A controller that fails to start should fall back to the last known-good image, not retry the same broken one. This is the reliability defect that actually caused the outage: the system had no way to recover without a human.
Unattended automatic install. For life-supporting equipment (plants, but also in principle any physical process), updates should be staged: a canary group first, then wider rollout, with a health check and an automatic halt.
The proposed fix is inadequate. A longer retry delay slows the loop but does not break it; the controllers still never recover, and the outage merely becomes slower. It treats a symptom of a missing rollback path.
The right fix is layered: protect the key, add a last-known-good fallback, stage rollouts, and only then adjust retry timing.
2. Recommend a staged rollout and recovery design, and discuss the ethical and legal responsibilities the team owes the schools.
Read the worked answer
Rollout design.
- Canary. Update one controller, require it to report healthy for 24 hours before proceeding. Health means: booted, reached the network, and opened a valve on schedule at least once.
- Wave. Update 10% of controllers, then 50%, then all, with an automatic halt if the health rate falls below a threshold.
- Recovery. Keep two firmware slots. On boot, if the new image fails its self-test, revert to the previous slot and report the failure. Never retry a known-bad image.
- Versioning. Use a monotonic version with a minimum-acceptable floor; refuse downgrades.
- Manual override. Provide a documented local recovery path so a technician can restore a controller without network access.
Ethical responsibilities. The team deployed code that could affect a physical process without a tested recovery path. The ethical duty is to anticipate failure modes proportional to harm - here, crop loss and wasted water - and to be transparent when something goes wrong. That means notifying affected schools promptly, explaining what happened, and not quietly patching and moving on. Honesty about the key exposure is also required: schools should be told the signing key was in the repository so they can assess risk.
Legal responsibilities. The controllers were sold, so the team has contractual and consumer-protection obligations: goods must be fit for purpose and durable, and a remote update that can disable a device may breach those obligations. Depending on jurisdiction, there may be data-protection duties if controller logs contain identifiable information, and product-safety rules may apply to remotely updatable devices. The key in the repository may also be a security incident requiring disclosure under applicable breach-notification rules.
The judgement being tested is that reliability engineering and ethical duty are the same conversation when software controls physical equipment.