On May 19, a supply chain worm called Mini Shai-Hulud tore through the npm registry and compromised 639 package versions across 323 unique packages in under an hour. TanStack, Mistral AI SDKs, Guardrails AI, echarts-for-react, and dozens more. The worm's trick was novel: it generated cryptographically valid Sigstore provenance attestations, so every poisoned package showed a green verified badge and passed standard integrity checks.
If your vessel runs any Node.js-based system (guest portal, bridge dashboard, monitoring tool, entertainment platform), this is your wake-up call.
How the worm spread
The attack, attributed to a group called TeamPCP, propagated automatically through dependency graphs. Compromise one popular package, and the worm injected itself into every downstream project that pulled it during a CI build. No human operator needed. The malware then read GitHub Actions runner process memory and scraped 100 hardcoded credential paths: cloud provider secrets, SSH keys, container registry tokens, Git configs, cryptocurrency wallets, AI tool API keys, VPN configurations, shell history.
One compromised dependency. Hundreds of infected projects. Every secret on the build machine exfiltrated.
This is the third major supply chain attack on a public package registry in one week. The pace is accelerating, and the economics favor the attacker.
Why vessels are uniquely exposed
Most shore-side development teams have a playbook for this: rotate secrets, audit lockfiles, wait for the remediation advisory, patch. It is uncomfortable but manageable when you can push a hotfix in twenty minutes.
On a vessel, that playbook falls apart. You cannot push a hotfix to a guest portal running on a ship in the middle of the Caribbean. The satellite link may be degraded. The vessel's IT staff (if there is one) may not have the access or expertise to hot-swap a compromised dependency. And if the worm already ran during a build that produced the software image currently deployed on board, the credentials it stole may include keys to the vessel's own management systems.
This is not a theoretical scenario. If you are running Node.js on a vessel today and your build pipeline pulls from the public npm registry at build time, you were in the blast radius on May 19. Whether you were hit depends on whether any of your transitive dependencies included one of those 323 packages.
The fix is architectural, not procedural
The standard advice after a supply chain attack is "pin your dependencies, enable lockfile verification, audit your SBOMs." That is all correct. It is also insufficient for a vessel environment where the time between "vulnerability disclosed" and "patch installed" is measured in weeks, not hours.
The sovereign AI approach treats this as a design problem. On-vessel software environments should never pull live from a public registry. The pattern we use:
- Curated mirrors. Every dependency gets pulled into a private, version-locked registry that is validated and scanned before a controlled sync window. The vessel's build environment never touches npmjs.com directly.
- Air-gapped image builds. Software images destined for vessel deployment are built in isolated environments with no live internet access during the build. If a dependency is not in the curated mirror, the build fails. That is the point.
- Controlled sync windows. New dependencies get pulled during scheduled port calls or planned maintenance windows, not on every
npm install. The sync process includes automated scanning, SBOM generation, and human review for anything flagged.
This is the same principle behind the zero-trust network architecture we recommend for vessel networks: assume the external environment is hostile, and design your trust boundaries accordingly. The difference is that the trust boundary extends to the software supply chain itself, not just the network perimeter.
What APT28 taught us (and what this confirms)
When APT28 targeted maritime supply chains earlier this year, the attack vector was nation-state malware aimed at logistics infrastructure. Mini Shai-Hulud is a different beast: financially motivated, automated, and indiscriminate. It does not care whether you are a defense contractor or a yacht running a guest Wi-Fi portal. If your dependency graph touched one of those 323 packages, you were a target.
The common thread is the same one that runs through every deployment we design: the cloud is a dependency, not a guarantee. A live connection to a public package registry is a dependency. A CI pipeline that pulls from the open internet at build time is a dependency. Every dependency you do not control is one that can be turned against you.
Sovereign AI on a vessel means controlling the full stack, from the model weights and inference hardware to the software supply chain that puts code on the machine. The knowledge ark only works if nobody can poison its foundations. When the next worm hits the registry (and there will be a next one), vessels running curated, air-gapped pipelines will not notice. Vessels pulling live from npmjs.com will find out the hard way.
Evaluating your vessel's software supply chain? Talk to us. We build deployment pipelines that are air-gapped by design, not patched after the breach.