Your model weights and internal CLI binaries are signed in the registry, but nothing checks the signature before they run. How do you close that?

## The missing chokepoint Almost every mature verification story leans on one property: there is a single place the artifact must pass through, and you can enforce a check there. For container images that place exists — something pulls the image and decides whether to run it, and it does so for every workload, so one control covers the estate. Non-image artifacts break that assumption, and this is the whole point of the leaf. A model checkpoint is opened by application code deep inside a serving process. An internal CLI binary is fetched by an engineer running a one-line command. A firmware blob is written by a device with no operator watching. There is no shared gate, so **the signature exists and nobody is on the other end of it**. Signing without verification changes nothing: it is a preventive control only when a consumer refuses to proceed without it. ## Move the check into the consuming path The general shape is to find the last step before use and make verification part of it, so the unverified route stops being available rather than merely discouraged. - **Fetch-and-verify as a separate step.** An init step downloads the artifact by digest, checks the signature and the expected identity of the publisher, and only then places the bytes where the process reads them. The process itself stays unchanged, and its start-up simply fails if the step failed. This works well for weights consumed by a serving pod. - **Verification inside the client.** If a shared internal library or SDK does the fetching, put the check there and give it no bypass flag. One implementation then covers every consumer, and adoption becomes a version-bump problem rather than a per-team project. - **A distribution channel that verifies for you.** For developer tooling, shipping through a package mechanism that already performs signature verification on install beats writing your own check into a shell snippet — the win is that the verifying path is also the convenient path. ## Fail closed, and pin the digest Two details decide whether any of this is real. **Fail closed.** A verifier that logs a warning and continues is a metric, not a control. The failure modes have to be explicit: signature invalid, unexpected signer, no signature at all, verifier unreachable. Each has to stop the load. Teams resist this because a bad rollout now takes down start-up — which is the correct behaviour and needs to be agreed before, not during, an incident. **Pin the digest at the consumer.** The reference the consumer holds should be content-addressed, recorded in the config or code that ships with the workload. Then the fetch itself is tamper-evident and the signature check is over a known digest rather than over whatever a mutable name resolved to a moment ago. ## The bootstrapping problem A fetch-and-run one-liner is the sharpest version of this: the script that would do the verifying is itself downloaded and executed before anything has been verified. Transport security proves you talked to the right host, not that the host is honest or uncompromised, so this is trust on first use with extra steps — and the asset at risk is developer laptops and the deploy credentials they hold. So the public keys or trust roots must arrive by a different route than the artifacts: baked into a base image, provisioned into a device at manufacture, distributed with the managed developer environment. Whatever route you choose becomes the thing you must protect hardest, because everything else hangs off it. The same reasoning applies to a constrained consumer such as a device: it has no policy engine and no operator, so the check has to be cheap and local — a key provisioned before deployment, a signature checked over the artifact's digest before the blob is written or booted, and a safe state to fall back to when the check fails. ## Know what you have and have not bought Even with verification everywhere, be exact about the claim: a signature says **who vouches for these bytes**, and a digest says **which bytes**. If someone with legitimate publish rights signs a malicious artifact, verification passes. That is why the second half of the answer is publishing controls — narrow the identities that can push, require review or a second identity for artifacts production consumes, and log every publish so the attribution the signature gives you is actually usable. Finally, treat adoption as the real deliverable. Verification that a third of consumers run is a control you cannot claim. Measure which fetches went through the verifying path, alert on the ones that did not, and remove the unverified route once the verified one works.