The change was a single line. Log4Shell (CVE-2021-44228), a remote code execution hole in a logging library that ran in half the world's Java software, had just dropped; the fix was a one release bump. CI compiled it. All 10,000 automated tests passed. Staging ran green overnight. By any signal a machine can produce, the change was safe.
Then I spent 45 minutes on a Thursday afternoon Zoom explaining it to an emergency change advisory board: a room of managers, most of whom had not written code in a decade, while I filled out a Jira ticket with 20 fields to "prove" the change was safe. The proof already existed. It was cryptographic, reproducible, sitting in our CI logs. We were deriving it again by hand, slowly, in a meeting.
That meeting is the reason I built autogov, the toolkit Liatrio is now open sourcing. This is what I learned about how automated supply chain governance actually works once you stop treating it as paperwork.
The problem isn't security. It's theater.
Most software supply chain governance is the security equivalent of taking your shoes off at the airport. It looks decisive on an auditor's spreadsheet and generates approvals, tickets, and meeting invites. What it doesn't do is stop a determined attacker from compromising an upstream dependency. The attacker isn't filling out the Jira ticket; the developer rushing a CVE patch is. The friction mostly inconveniences the people who were never the threat.
A human in the loop is not the same thing as a control. A manager approving a ticket cannot read a binary, or tell whether what's in staging came from the build they're signing off on. They're trusting a story about the software, and a compromised pipeline will happily supply a convincing one. Ask SolarWinds. In 2020, attackers compromised its build system and shipped a backdoor, Sunburst, inside legitimately signed Orion updates; roughly 18,000 organizations, including federal agencies, installed it. Every signature checked out. The build did not.
The gate someone adds after one bad change never stops the next one; it just slows every fix after. The evidence a reviewer actually needs already sits in the pipeline. The hard problem isn't gathering more of it; it's making that evidence trustworthy enough that a machine can act on it without a meeting.
Make the secure path the path of least resistance
Real governance is a guardrail built into the tools a developer already uses, not a gatekeeper bolted onto the end of the process. It's invisible on the days nothing is wrong.
If a developer has to consciously think about supply chain governance during a routine deploy, the platform team has failed them. People route around friction: the moment the secure way is the slow way, you've built an incentive to cut the corner. So you invert it: make the secure path the default, and let the compliance artifacts fall out of the build.
Every build emits signed evidence
autogov turns a build into a stack of signed in-toto statements about itself. As CI produces an artifact, build provenance and an SBOM come from GitHub and syft tooling in the workflows, and the autogov CLI emits the rest directly: a vulnerability scan, test results from JUnit XML, and a code scanning summary from SARIF 2.1.0. Each is a predicate, a typed payload that says one true thing about the build.
Every statement is signed through Sigstore, keyless: no standing signing keys to leak or rotate.
Fulcio issues an ephemeral certificate bound to the build's workflow identity.
Each build attestation is logged in Rekor.
The result is a bundle anyone can verify with cosign.
The signature does not say "Ian approved this." For a build attestation it says "this artifact was built by this workflow, and here's the transparency log entry that proves it." A valid signature on a poisoned build is still valid. Provenance binds the artifact to how it was built, not to who waved it through.
The model is deliberately extensible: a new kind of evidence is a producer plus a policy, both aligned to open standards. SARIF code scanning is one example: I wrote a producer that turns code scanning output into an in-toto predicate and a Rego rule that gates on it, the same shape as the earlier test result predicate. The newest is source review: who approved a change before it merged, captured the same way, with the gate off by default. New evidence type, no new architecture.
Policy is code, and the verdict is a portable receipt
Evidence is only half of it. The other half is recording, mechanically, a verdict on whether it should ship. autogov does that with OPA and Rego: at verify time, policy as code evaluates the attestations and produces a signed pass/fail verdict your release can gate on.
Is the provenance valid? Is an SBOM present? Are vulnerabilities within their configured threshold? Did the tests pass? Any critical code scan findings? Was it signed by an approved identity? The answers are deterministic: run it twice, get the same verdict.
The policy library is composable and, more importantly, driven by data. Internal tools fail when org assumptions get hardcoded: adopting one means forking it and maintaining the diff forever, which is how policy libraries die. So I pushed those assumptions out into data: approved owner IDs, the signer org, the image subject prefix, vulnerability and code scan thresholds, all configuration with sensible defaults. You adopt the canonical bundle and override what differs.
The output is where this stops being plumbing. The verdict is itself a signed artifact: a SLSA Verification Summary Attestation (VSA), a portable receipt that says "this artifact passed policy X, here's what was checked." A downstream system trusts the VSA without running the evaluation again. That is the CAB meeting, replaced: an audit trail stronger than any Jira ticket, and nobody stuck in a meeting to produce it.
What it looks like wired together
Three pieces compose into the toolkit:
autogov CLI (Go): Produces and verifies evidence (verify, predicate, download, offline) and handles releases (release, changelog): commits signed through the GitHub API, a file mutation engine, changelogs, and policy bundles over oci:// and ghrel://. The CLI itself ships as a signed OCI image at ghcr.io/liatrio/autogov, verifiable by digest with the same primitives it applies to your builds.
autogov-workflows: Reusable GitHub Actions workflows that wire generate to verify to gate. Pinned by commit SHA and aimed at SLSA Build Level 3, so you write your build logic and inherit sensible defaults.
autogov-policy-library: The OPA/Rego policy library holding the versioned policies you configure rather than fork, aggregating into one gate.
Note: A small caller-workflows repo shows the whole loop end to end.
The objections worth taking seriously
Two are fair.
First: Auditors still want a human signature. True in plenty of regulated shops. autogov doesn't abolish the human; it changes what they sign. Instead of attesting "I reviewed this change," they attest "I approved this policy," once, and every build is measured against it. The judgment moves to where it scales.
Second: Aren't attestations just checkboxes in a different shape? They would be, if they were unsigned. The difference is provenance: a forged checkbox costs an attacker nothing, while an attestation backed by Fulcio can only be produced by something that controls the build's workflow identity. The verdict is computed from evidence you can't forge, not from a self-asserted claim.
Where to start
If your pipeline does none of this yet, start small.
Emit provenance first. A single signed attestation of how the artifact was built is the most valuable evidence you can produce.
Adopt the policy bundle with your own data. Point it at your approved identities and thresholds, and don't fork it; if you want to, that's a bug worth filing.
Gate on the VSA. Wire your release to fail on a failed verdict, so the signed receipt is the thing it checks and downstream systems trust.
Add one evidence type: a producer and a policy. Pick the gap that bites you most; model it as a new predicate and gate.
Harden your producers. They ingest untrusted scanner output and SARIF from third parties, so assume hostile input. My gzip bomb defenses and size caps came from exactly that.
Giving it back
The community gave us the primitives: Sigstore, in-toto, SLSA, OPA, SARIF. Liatrio contributed back to Sigstore and wrote about it; this is the sequel. We built the integration layer on top, and that glue is not a competitive secret; it's shared infrastructure every enterprise rebuilds. A tool you can't inspect is a weaker one, so we're opening it.
The toolkit is tied to GitHub today, and I won't pretend otherwise. But the standards it rests on are portable, so the direction I want to take it is independent of any single CI host or cloud. That's an honest next step, not a shipped feature, and the part I'd most like help with.
Try it, break it, tell me where it's rough. The code is available at:
If you're wrestling with supply chain governance and want to compare notes, Liatrio's at liatrio.ai. I'd rather read your pull request than sit in another CAB meeting.
