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 holder of a private key signs a specific statement or artifact digest. A verifier can check that signature with the matching public key, but connecting the key to a real publisher requires a separately trusted key reference. A hash chain makes edits to checkpointed entries detectable; it does not show that no entries were omitted or that today's deployment was recorded. Together these controls help verify a particular record, within the trust and coverage of its release path.
Common supply-chain tools include Sigstore and cosign for signing, in-toto for signed statements, and CycloneDX or SPDX for software bills of materials. They are examples of industry tooling, not services or certifications this site claims to run.
What does the published Kinetic Gain record verify?
The apex publishes a dated ed25519-signed record at /.well-known/kg-verify.json and a matching same-site public key at /.well-known/kg-pubkey.json. The browser check validates that signature and recomputes the published declaration hash. It does not walk the audit chain, authenticate the key independently, or compare the record with the current hosted bytes. The separate audit stream contains six historical entries as of this article's 2026-10-11 update. Some lack an artifact hash, and its latest signer-declared timestamp is 2026-08-20; recent deployments are absent.
A separate repository gate can recheck signatures on the 11 published Suite documents when that gate is run. Its existence does not prove that every hosting path executed it. These records illustrate signature and hash-chain mechanics; they are not a complete deploy history, independently anchored provenance, or a certified supply-chain posture.
Why is a signed, provenanced deploy the supply-chain piece of AI-governance evidence?
A governed control plane needs evidence that reaches the artifact people actually use. A complete release proof would connect a reviewed commit to a build digest, a trusted signer, a durable checkpoint, and a comparison with the hosted bytes. A signature on a historical record is one part of that chain, not a substitute for the rest.
The site's dated record is useful for checking its published signature and declaration hash. It does not prove that current code is serving, that the audit stream is complete, or that a live runtime action was captured. Those claims require separate release and runtime evidence.