Can software be verified without trusting the platform that built it?

Two meanings of trust

The first question is operational: does verification require an account, API or connection to the producer’s system? With the necessary records, files and keys, some checks can run locally.

The second concerns the truth of the record: did the process accurately describe what happened? A valid signature does not answer that question on its own. It protects a statement and connects it to a key.

What can be checked separately

Recipients can check receipt structure, consistency and signature using a trust store they manage. They can also compare hashes when the files and configuration required for the chosen check are available.

This provides practical independence: producers do not need to keep a session open or provide a dashboard for every check. Offline verification presents the corresponding commands.

What still needs examination

Verifiers need to know the declared scope, understand how the key was approved and consider available revocation information. An offline trust store does not update itself.

A malicious build can produce a misleading signed statement if the recording process itself is compromised. Build protection and provenance examination therefore remain complementary. Successful verification is not a general verdict on software security.

Run a repeatable trial

Produce a signed receipt, prepare trust material and required files, then run the checks on another machine. Document expected results for an unchanged file, a modified file and an unapproved key.

The CLI documentation gets you started; the receipt format explains what is checked. This is a practical application of Trust is not evidence: keep trust assumptions explicit and give recipients evidence they can examine themselves.