What does it mean to secure the software supply chain?
Securing the software supply chain means securing the path that produces and ships an artifact — the build system, the dependencies, and the release channel — not just reviewing the source. The hard truth is that clean source code is not enough: an attacker who compromises a build server or a package registry can inject malicious bytes after review and ship them under your name. The SolarWinds compromise was exactly this — the source was fine; the build pipeline was not.
So the discipline shifts from trust the code to verify the artifact and how it was produced. You stop asking people to trust that the bytes on the server match the bytes you reviewed, and you give them a way to check it themselves. That single move — verify, don't trust — is the through-line of everything below, and it is the same property an AI control plane demands of its evidence.
What is build provenance, and what is an attestation?
Build provenance is verifiable metadata that answers three questions: what artifact was built (named by a cryptographic digest, e.g. a sha256 hash), from what source (the repository and commit), and by what builder (the platform, identity, and parameters). An attestation is a signed statement that binds that provenance to the artifact's digest — so a consumer can verify the claim instead of taking it on faith.
The industry yardstick for this is SLSA (Supply-chain Levels for Software Artifacts), an OpenSSF framework whose v1.0 centers on a build track graded L0 to L3: roughly, no provenance, provenance exists, a hosted platform generates and signs it, and a hardened platform produces non-falsifiable provenance. SLSA grades a process; it is a maturity model, not a product, and not a badge you wear. We cite it as a ruler for what good provenance looks like — we do not claim a level number, because we have not been assessed against one.
How do teams sign artifacts so anyone can verify origin and integrity?
The mechanism is a public-key signature: the holder of a private key signs the exact bytes, and anyone with the matching public key can verify those bytes were signed by that key — no shared secret, no trusted third party. An ed25519 signature proves origin; a hash chain proves integrity (nothing was altered). Origin plus integrity is the complete property, and it is the same pairing we use for a tamper-evident audit log.
The mainstream tooling encodes this principle. Sigstore and its cosign tool sign keylessly — an OIDC workload identity is exchanged at the Fulcio CA for a short-lived certificate, and the event is recorded in the Rekor transparency log. in-toto defines the standard signed-statement envelope (SLSA provenance is expressed as an in-toto attestation), and an SBOM (CycloneDX or SPDX) inventories what went into a build. GitHub's artifact attestations made this pattern a near-default for public repos in 2024. These are external standards we describe accurately — not ones this estate runs.
How does Kinetic Gain prove this on its own deploys?
It runs the principle on itself, and lets you check the math in a browser. The apex signs its own deploy attestation with an ed25519 keypair (key_id kg-2026-06) and publishes the matching public key at /.well-known/kg-pubkey.json. The attestation lives at /.well-known/kg-verify.json: fetch it, fetch the public key, ed25519-verify — a local computation, no third party. Each deploy is appended to an append-only sha256 hash chain whose every entry binds the git commit, the artifact and its canonical hash, the deployer, and a timestamp, so altering any entry breaks the chain.
Separately, the same estate signs its 11 published /.well-known/ Suite documents with a distinct ed25519 keypair (the pulse-signing key at /.well-known/pulse-signing.json), and a blocking deploy-time gate re-verifies those 11 signatures before shipping; an unsigned or invalid document fails the deploy. That gate exists because of the 2026-06-01 drift incident — a dry-run found 0/11 still verifying after edits had silently invalidated them — and we added the check so the drift cannot recur. No SLSA level, no sigstore, no SBOM: a self-asserted posture you can verify, not a certified one.
Why is a signed, provenanced deploy the supply-chain piece of AI-governance evidence?
Because a governed control plane rests on three properties — capability, classification, and verifiable evidence — and a signed, provenanced deploy is where the evidence property reaches all the way down to the bytes you ship. It is the supply-chain twin of the runtime tamper-evident audit log: the same two primitives (hash chain for integrity, ed25519 signature for origin), pointed at the deploy artifact and its source commit instead of the runtime record.
That completes the thesis the control-plane cornerstone sets out. A system can declare what it does and how regulators classify it, but if you cannot verify the artifact actually serving those claims, the governance is assertion. Tamper-evident is not tamper-proof — the chain and signature make alteration detectable, not impossible — but detectable, by anyone, with math alone, is the durable standard. That is the lever our AI governance practice builds on, and the full Suite of specs follows the same rule: verify, don't trust.