Verifiable releases: SBOM, provenance, and signatures

A tool that administers production Kubernetes holds credentials, can read secrets, and can change the workloads you run. That makes it a valuable supply-chain target, and it is why conndeck's release process is designed around a simple premise: you should be able to verify the artifact before it ever runs.

Why an admin tool is worth attacking

A cluster admin tool is a concentrator of privilege. It may handle kubeconfig credentials, stream logs, and perform authorized operations in the clusters and contexts available to it. Compromise the tool and you inherit that access on every operator's machine that runs it.

Desktop distribution makes this concrete. A tampered binary, a hijacked download mirror, or a compromised update channel is a quiet pivot into production, and because the tool is trusted by design, downstream controls may not reliably identify the compromised desktop tool as the source. This is the same reasoning behind conndeck's local-first posture: no telemetry, no login, no data leaves your device. That posture reduces how much of the vendor's infrastructure you have to trust day to day. Release verification is the install-time counterpart — it can reduce reliance on the distribution channel by checking downloaded artifacts against separately trusted verification material.

The artifacts, in plain terms

Verification is a chain of artifacts, each answering a different question. No single one is sufficient on its own.

SHA256 hashes: which file is this

A SHA256 hash is a fingerprint of a file's exact bytes. The publisher hashes the release artifact and publishes the result; you hash what you downloaded and compare. A match means your file is bit-for-bit identical to what was hashed at release time, and any tampering or corruption in transit changes the digest.

The limit: a hash published next to the download proves only that the file matches what the site published. If an attacker can replace the binary and the hash on the same page, the comparison still passes. A hash needs something that anchors it to the publisher.

Detached signatures: who stands behind it

A detached signature is a small separate file that lets a verifier check that release material was endorsed by the holder of the corresponding signing key. An attacker who swaps the binary must now also produce a signature that verifies against the published key — a much harder problem than editing a download page.

A signature alone is still not enough. It proves that a key signed something. It does not tell you whether the signed binary was built from the source you think it was, and it says nothing about what is inside it. Keys can also be mishandled, so a signature is a strong link in the chain rather than the whole chain.

SBOM: what is inside

A software bill of materials is a machine-readable inventory of the components and dependencies recorded for a build. It can make included components easier to inspect, subject to the SBOM's completeness and accuracy — it documents what its generator found and does not by itself prove the inventory is exhaustive. When a dependency vulnerability is disclosed, an SBOM gives investigators a structured starting point for assessing whether the affected component is present in a given build.

Provenance: where it came from

Provenance — attestation metadata about the build — is intended to connect a release artifact with information about its build origin. It is meant to narrow the gap between "this binary is signed" and "this binary was built from the source tree you think it was." The strength of that evidence depends on how the provenance is generated and authenticated: provenance can support the claimed correspondence, but on its own it does not prove it.

The four artifacts answer four distinct questions: identity (hash), endorsement (signature), contents (SBOM), and origin (provenance).

A single verification command

High-friction verification is less likely to become a routine operator practice, so conndeck's design target is a single copy-paste step. The planned public-release flow centers on the scripts/verify-release.sh command: once public artifacts ship, the verification documentation should describe what the command checks, and any mismatch should be treated as a stop condition, not a warning to click through. The discipline only works if the failure mode is loud and the success path is boring.

A note on release status

conndeck is pre-release. Public download artifacts have not shipped, and the hashes currently published on the downloads page are placeholders, explicitly marked as pending release artifacts, until real builds exist. The changelog is intentionally lightweight for the same reason.

Describing the verification chain now is deliberate. The discipline is designed into the release process rather than bolted on after a first incident: signed builds, SHA256 hashes, detached signatures, an SBOM, and provenance metadata define the intended verification model for public releases.

What to demand from any Kubernetes tool vendor

Whatever tool you standardize on, the bar should be the same:

• Published SHA256 hashes for every release artifact, on a page you can cache and diff between releases.
• Detached signatures verifiable against a stable, published public key.
• A machine-readable SBOM attached to every release.
• Provenance metadata tying each artifact back to a source revision and build process.
• One documented command that runs the whole check, with a hard failure on any mismatch.

A vendor that asks for cluster-admin-level access and cannot produce these is asking operators to accept trust that cannot be independently verified from the release artifacts. The healthy default is verify, then run — evaluate any vendor's claims, conndeck's included, against the artifacts, not the marketing.

Verifiability completes the local-first story

The local-first posture means conndeck's infrastructure does not need to be trusted with cluster data, because that data stays on the user's device by default, unless the user explicitly enables a sync or sharing workflow. Verifiable releases are intended to make tampering in the distribution path detectable and to reduce the amount of implicit trust required there as well. The combination is the trust model: less taken on faith, and a concrete check you can run yourself once artifacts ship.

The verify release page describes the intended verification approach while public artifacts remain pending.