Cilium publishes its CI hardening playbook, gaps and all

Every open source project's CI pipeline is a quiet confession of how much trust it extends to its own contributors. (Most maintainers would rather you not read theirs.) This week the Cilium team did the opposite. The third and final post in their CI/CD hardening series, published on the CNCF blog, walks through how they manage credentials and verify the artifacts they ship, and lists the parts they have not yet fixed.

What's actually in part three

Credentials are the section most security posts skim past. Cilium walks through theirs in detail. The default GITHUB_TOKEN is held to read-only on contents and packages, and any workflow that needs more has to ask for it by name. Every actions/checkout call sets persist-credentials: false, so a downstream step cannot quietly reuse the checkout token to do something else.

CI and production pushes go to different registries. Everything CI builds lands in a development registry. Anything that becomes a public release tag is pushed by workflows running in distinct GitHub protected environments (release, release-tool, release-helm), each gated behind explicit maintainer approval.

Then the verification half. Container images for cilium, the operator, hubble-relay, and clustermesh-apiserver are signed with Sigstore Cosign in keyless OIDC mode, through a reusable composite action committed inside the repo. SBOMs are generated and attested with the spdxjson predicate. Helm chart OCI artifacts get the same signing treatment. Tag immutability is enabled at the repository level, so a release tag cannot be silently rewritten later. A bot enforces DCO sign-off on every commit and blocks merges when a label says the change is not ready.

permissions:
  contents: read
  packages: read

steps:
  - uses: actions/checkout@<full-40-char-sha>
    with:
      persist-credentials: false

Why the keyless part is doing the heavy lifting

If you remember one thing from the post, make it the keyless OIDC piece. Long-lived signing keys are a liability the moment a maintainer's laptop walks out of a coffee shop. Keyless signing anchors the trust root in the workflow identity, so the certificate, the transparency-log entry, and the workflow that produced the artifact are linked together. Verify the cert, and you know which repository and which workflow built the image. Lose a maintainer's GPG key, and you do not have to rotate the world.

Is keyless a silver bullet? Of course not. A compromised workflow can still sign garbage that looks perfectly legitimate (it was, after all, produced by the legitimate workflow), and the verifier on the other end still has to actually check the signature. Most consumers do not.

The unusual part: what they admit they have not fixed

This is where the post earns its keep. Most security writeups stop at the highlight reel. Cilium lists, in public, what their pipeline is still missing. No SLSA provenance yet, because docker/build-push-action is currently invoked with provenance: false. No actions/dependency-review-action wired into PRs. No govulncheck in CI. An expired SECURITY-INSIGHTS.yml. No OpenSSF Scorecard workflow. No go mod verify step for the vendor directory. And the one that should make every reader wince: internal composite actions still pinned to @main across dozens of references, instead of by SHA.

That last item is the kind of debt that sits quietly for years until somebody pushes to the wrong branch.

How GitHub's roadmap maps on top

The post closes by mapping the remaining gaps against GitHub's published 2026 Actions security roadmap: a dependencies section in workflow YAML for transitive locking, workflow execution protections via org-level rulesets, scoped secrets bound to paths or branches, a native L7 egress firewall, and an Actions data stream for telemetry. Some of those will close gaps Cilium already documents. Some will not.

Here is the verdict. Most "we hardened our pipeline" writeups are marketing pieces dressed in YAML. This one is a runbook, including the parts where the runbook is incomplete. If you maintain a project that other people depend on, the useful exercise is not to copy Cilium's setup line for line. It is to write your own version of part three, in public, with the same honesty about what you have not done yet.

Your pipeline already has gaps. The question is whether you can name them.