Updating a Ship at Sea: Trusted Software Delivery and Knowing What’s Inside

Software is never finished. Bugs are found, improvements are made, and — crucially for security — new vulnerabilities are discovered that need patching. For an ordinary computer this is routine: it downloads an update over the internet and installs it. For an autonomous vessel, this everyday task becomes surprisingly hard, and getting it wrong opens one of the most dangerous doors of all.

Two problems at once

Delivering software to a fleet of vessels combines two awkward challenges. The first is connectivity. Vessels at sea often have slow, expensive or intermittent links, and some operate for long stretches with no connection at all. You can’t assume a vessel will simply reach out and download the latest version whenever you release it; it may not be reachable for days.
The second problem is trust, and it is the more serious of the two. A software update is, by its nature, new code that the vessel will run with full authority. If an attacker could slip their own code into that update channel, they wouldn’t need to fight through the vessel’s other defences — they’d simply have the vessel install their attack for them and run it willingly. The update mechanism is a master key, and it has to be protected accordingly.

Proving an update is genuine

The cornerstone of safe updates is the same idea we met with commands: cryptographic signing. Before any software is sent out, it is signed by MindChip using a key that only we hold. The vessel carries the matching public counterpart, which lets it verify that signature. When an update arrives, the vessel checks the signature before installing anything. If the software wasn’t signed by us — or if a single byte has been altered since we signed it — the signature won’t match, and the vessel refuses to install it.
The elegance of this approach is that it doesn’t depend on the delivery route being secure. The update could travel over an untrusted network, sit on a memory stick, or pass through several hands — it doesn’t matter. Tampering breaks the signature, and unsigned software is rejected. Trust is anchored in the cryptography, not in the courier.

Knowing exactly what’s inside

Modern software is assembled from many building blocks, often written by other people — open-source components, libraries, tools. This is normal and efficient, but it means a vulnerability discovered in some widely used component can suddenly affect thousands of products that quietly depend on it. Nobody sets out to ship a vulnerable component; they ship a component that was fine on Tuesday and had a serious flaw published on Wednesday.
To manage this, MindChip maintains what is essentially an ingredients list for every piece of software — a detailed inventory of every component and version it contains. In the industry this is called a software bill of materials, or SBOM. With that inventory in hand, when a new vulnerability is announced in some common component, we can answer a vital question in minutes rather than weeks: does this affect us, and which vessels? Before any software is packaged for delivery, it is also automatically scanned against databases of known vulnerabilities, so that problems are caught and fixed on our side long before the software ever reaches a vessel.
This is also, increasingly, not optional. The EU Cyber Resilience Act sets vulnerability-handling obligations on manufacturers of products with digital elements, and knowing your own software composition is the foundation of all of them.

Delivering to the reachable and the unreachable

Because vessels differ in how well-connected they are, safe delivery needs more than one route. A vessel with a good link can receive updates through the fleet’s command systems, brokered securely so that the vessel never needs to hold sensitive access credentials of its own. A vessel that is offline needs another path entirely: verified, signed software can be carried physically and applied during a port call, with the vessel performing all its integrity checks locally, without needing to phone home. In every case the vessel does the same fundamental thing before trusting new code — it verifies the signature. The route in changes; the discipline does not.