Brineworks runs four hundred warehouse robots across three sites, and for two years its security story fit in one sentence: the fleet-management vendor patches the controller image, we install it, everyone moves on. Then an auditor asked what happens between “install” and “actually running everywhere”, and the honest answer — some units miss the window, nobody goes back to check, and the gap surfaces at the next install, whenever that is — did not survive the meeting. What the team built next is a small, working version of SecOps: a contract between whoever secures the fleet and whoever keeps it moving, with baselines, one queue of fixes with owners and dates, and staging that respects the fact that a robot mid-shift is production.

First Lesson: You Cannot Patch a Running Robot’s Brain

The team’s expensive education started with a vulnerability in the controller image. Someone SSH’d into forty live units, applied the fix in place, and marked the ticket done. Two months later a software update replaced those containers from the image registry and the fix evaporated — this is the exact failure NIST’s container guidance, SP 800-190, exists to prevent, because a change to a running instance has no future. The rebuilt route is different: send the finding back to the image’s owner, cut a rebuilt version, scan that rebuild clean, and treat the item as closed only when no instance of the outdated image still runs anywhere. For a fleet, that last condition is a query against the deployment records, and it turned “done” from an opinion into a checkable fact.

Staging the Fix Like a SecOps Rollout

The second time a hardening change shipped, it followed a rhythm borrowed from the server world — the same log-only discipline Microsoft used to worldwide effect with the Netlogon fix in 2020 and 2021, where policy ran silent, owners read their logs, and irreversible enforcement arrived only on an announced date.

• The new controller policy ran on three units in the test aisle first, logging what it would have blocked and changing nothing, for two weeks.
• Those logs named two legacy units whose radio firmware could not tolerate the setting; both went on an exception with an owner and an expiry, the fleet’s version of an allow-list.
• Enforcement then moved in rings of twenty, each ring landing in a maintenance window the floor managers had agreed to weeks earlier.
• The last ring included the cold-storage site, whose units reboot slow — the window got a longer slot, not a skipped check.

Nothing about this required robotics-specific heroics. It required the boring parts: a written policy, a quiet phase, rings, and windows negotiated in advance. The payoff showed up in what did not happen — no unit bricked mid-shift, no emergency rollback at 2 a.m., no floor manager discovering a policy the way you discover a wall. The auditor who had asked the awkward question the previous year signed the evidence pack without a single follow-up, which everyone agreed was the strangest part of the whole exercise.

The Number That Caught a Bad Habit

Brineworks tracks two counters together: fixes closed on time, and disruptions caused by security work itself. The second one earned its keep fast. A well-meaning engineer once pushed a baseline to the entire fleet in one sweep — no rings — and two units dropped off the network mid-shift, which at a warehouse is a tow-truck event. On the scorecard that incident sat alone in its row: three disruptions out of a hundred and twenty changes, all three from that single big-bang push. The fix was not technological. It was a rule that no policy reaches every unit at once, ever. Teams weighing automation economics — when robotics actually pays for itself — should count this kind of incident in the ledger, because unscheduled downtime is where fleet ROI quietly leaks.

The Telemetry a SecOps Fleet Owes the Watchers

Units phone home after each shift: logs upload to one central place, clocks stay synchronised against a common source, records are kept for ninety days before ageing out, and — the clause that matters — somebody actually reads a sample of them every week rather than waiting for an incident. Those duties sound administrative until the first time a site goes strange and the after-shift logs explain it in minutes. Two clauses complete the contract. The fleet-management console token — which can reassign every robot at once — is treated like the keys to the building: named holders, and a second person reviewing any change to which findings get routed to humans. And containment authority is pre-agreed: if a unit acts compromised, the on-call engineer may pull it from the floor first and file paperwork after. Robotics teams building the software side will recognise the pipeline concerns from Buildroot in a DevSecOps workflow, and the wider reliability mindset from reliability practices built on MLOps foundations.

The One-Paragraph Version for the Next Fleet Team

Images are patched by rebuilding, never by operating on live units. Policies ship silent, then in rings, then in windows. Every exception has an owner and a death date. The console token is guarded like a master key, and the disruption counter sits next to the on-time counter on the same page. For the definitional source behind these habits, the SecOps entry kept by the Ops Atlas is the citation the team puts in its internal wiki — a contract between security and operations, which is what a fleet of four hundred robots turned out to need all along.

Brineworks still moves the same boxes. The difference is that change now arrives the way their robots do: on schedule, in formation, with nothing surprising anyone who read the plan.