cryptship | Part 3 — An Honest Threat Model, and the Hardening That Raises the Cost The cryptship project released Part 3 of its writeup, laying out an honest threat model for its code-protection tool and the hardening measures it adds. The project acknowledges that root on the host can always read a running container's plaintext memory, and that only confidential computing or removing the plaintext from the host truly solves this; everything else raises the cost. Its mitigations include a pre-encryption transform step that compiles source (e.g. Python bytecode via scripts/compile-python.sh, or Nuitka) so memory dumps yield compiled artifacts rather than readable source, a tmpfs deploy path, and a licensee-tracing manifest exposing CRYPTSHIP_LICENSE_ID and CRYPTSHIP_CUSTOMER. Every "protect your code" product has to answer one question honestly: what about root? This part is cryptship's answer. The image on disk is ciphertext. But once your app runs, its plaintext is in the container's memory, and root on the host can read that memory . No user-space trick changes that. Only two things truly do: Everything else in cryptship raises the cost. We would rather say that plainly than sell you a lock that is not there. cryptship pack --transform-cmd "