The Governed CI/CD Loop: GitHub to Production and Back, with Zero Stored Secrets

CI/CD and change governance have spent a decade operating as if they did not need each other. The pipeline deploys. The change process records. In most enterprises the two are joined by convention, such as a ticket number pasted into a commit message or a pipeline that pauses on an approval step it enforces for itself, and by a set of stored credentials: the CI secret that calls the deployment target, the bot token that writes statuses back, and the webhook endpoint that trusts whatever calls it.

The result is a loop that works and cannot be defended. Execution can drift from approval. The evidence lives in three systems. The credentials that join them are standing authority waiting to leak.

OpsChain's GitHub integration closes this loop. Both directions are governed, and there is no standing secret on either side.

Inbound: identity in place of API keys

The first thing to remove is the API key in your repository secrets.

When a GitHub Actions workflow needs to raise a change in OpsChain, it does not present a stored credential. It presents its OIDC identity: GitHub's own cryptographic attestation that this workflow run, from this repository, on this branch, is the caller. OpsChain federates that identity in and maps it to a named service account with path-based permissions. The pipeline acts as a known actor inside the governance fabric, under its own name, and not as whoever holds the key.

That gives you what named identity gives everywhere else: attribution, scoping and revocability. There is no OPSCHAIN_API_KEY to rotate after an engineer leaves, to scrub from a leaked CI log, or to explain to an assessor. There is nothing to steal, because nothing is stored.

Repository events flow in the same way signed webhooks do everywhere on the platform. They are signed, replay-protected, and execute as named service accounts. A push, a release or a workflow completion can each start a governed run, and the path's approval policy decides what may proceed.

The middle: approval where execution happens

Once the deploy is a governed change, everything we have written about approval-as-policy applies. The production path holds its quorum. The submitter, whether a person or a pipeline, cannot approve its own change. The change window admits or refuses the run. The pipeline does not enforce governance for itself, and that is the property your change function could never verify in a pipeline that did.

This is the part most "GitOps plus tickets" arrangements cannot offer. The approval is not adjacent to execution. It sits in front of execution, held by the platform that executes.

Outbound: just-in-time tokens and attestations

The loop closes in the other direction without a standing credential either. When OpsChain writes back to GitHub, whether a status, a deployment record or an attestation, it mints a just-in-time token scoped to the repository and the operation at hand, uses it and discards it. The token is scoped, masked in logs and never persisted.

What it writes back matters as much as how. The deployment's attestation lands in GitHub and links the artefact to the governed change that shipped it: the approvals it passed, the window it ran in and the evidence trail behind it. Your engineers see the deployment's governance record where they already work. Your auditors see that the thing in production traces to an approved, recorded change.

One release, end to end

Here is a concrete pass through the loop, at a telco shipping a billing-service release:

1. An engineer merges to the release branch. The merge event arrives, signed and replay-protected, and opens a governed change on the production path.
2. The deploy workflow authenticates with its OIDC identity. No repository secret is involved.
3. The production path's policy holds the change: a quorum of two, with the submitter excluded. The pipeline is the submitter, so the pipeline cannot approve. The same rule binds every person. Two named engineers review and approve, and the decision is recorded.
4. The change window opens. The deployment executes through OpsChain's execution fabric, with every step logged live.
5. OpsChain attests back into GitHub with a just-in-time scoped token: this artefact, this governed change, these approvals, this outcome.
6. The whole episode (event, identity, approvals, execution and attestation) sits in one hash-chained audit lane, exportable with its chain intact.

Count the stored secrets in that story: zero. Count the places approval and execution could drift apart: zero. Count the systems an auditor must reconcile to see the release's history: one.

The limits of the integration

The loop above is the GitHub integration as it ships today: identity federation in, events in, just-in-time tokens and attestations out. It does not make your pipelines faster, and it does not replace your CI. GitHub still builds and tests as before. What changes is narrower and more valuable. The deploy itself becomes a governed change, and the governance becomes provable.

---

Key takeaway

A pipeline that enforces its own approvals is a witness vouching for itself. OIDC identity in, enforced approvals in the middle, just-in-time tokens and attestations out. Every deployment is approved, executed and attested, with zero stored secrets.

See the integration surface on the platform page, or book a demo and watch a release make the full loop.