Securing CI/CD in Open Source Projects: Cilium’s Final Guide to Credentials, Verification, and Remaining Gaps

VK Cloud has released the concluding installment of its translated Cilium series on securing the software supply chain for open source projects. While Part 1 focused on access controls and Part 2 addressed dependency hardening, this final article examines how to isolate secrets between CI and production environments, sign every release without long-lived keys using Sigstore Cosign, and identify remaining security gaps. It also analyzes GitHub’s Actions security roadmap for 2026 and evaluates how upcoming platform changes complement the controls already implemented by the Cilium project.

Protecting Credentials

Cilium assumes that any single layer may eventually fail. Therefore, if a CI workflow is ever compromised, it must not grant attackers access to high-value assets. By default, GITHUB_TOKEN permissions are restricted to minimal read access for contents and packages. Workflows requiring elevated rights must explicitly declare them, preventing forgotten permission blocks from granting broad write access across the organization.

The project maintains two distinct sets of registry credentials behind separate protected GitHub environments. CI credentials can only push development images to quay.io/cilium/*-ci and are available to CI builds. Even if a workflow is compromised, these credentials cannot be used to push production-tagged images. Production credentials reside behind the “release” environment and require explicit maintainer approval before a workflow can access them. Neither forks, feature branches, nor regular CI builds can reach these secrets.

Every actions/checkout call also sets persist-credentials: false, ensuring the GITHUB_TOKEN never appears in the runner’s git configuration where later steps could intercept it.

Signing and Attestation

Every released container image (cilium, operator-*, hubble-relay, clustermesh-apiserver) is signed using Sigstore Cosign with keyless OIDC signatures. No long-lived signing keys exist that could be stolen. The signing pipeline is implemented as a reusable composite action that installs Cosign, generates SPDX SBOMs via anchore/sbom-action, signs the image, and attaches the SBOM attestation. The same process applies to Helm chart OCI artifacts. Release builds execute inside protected environments, ensuring production registry credentials remain gated by environment protection rules.

Additional Hardening Measures

Cilium enforces several supplementary controls: release tags and assets become immutable after publication, every commit must carry a Signed-off-by line enforced by the maintainers-little-helper bot, and the project has undergone third-party security audits by ADA Logics that include a published threat model.

Identified Gaps and Future Work

An internal audit against OpenSSF Scorecard, SLSA, and StepSecurity recommendations revealed several shortcomings. The project currently disables provenance in docker/build-push-action, lacks dependency review during pull requests, does not run govulncheck in CI, and still references 68 internal actions at @main instead of pinned SHAs. Additional missing items include continuous Scorecard monitoring, an updated SECURITY-INSIGHTS.yml file, and a go mod verify step. The team plans to address these issues and welcomes community contributions.

GitHub’s 2026 Actions Security Roadmap

The article also reviews GitHub’s April 2026 roadmap, which introduces platform-level changes across the ecosystem, attack surface, and infrastructure layers. Planned features such as native dependency blocking at the YAML level, centralized workflow execution policies via rulesets, scoped secrets, and a native L7 egress firewall would directly address several gaps Cilium currently mitigates manually. The project views these upcoming capabilities as validation of the defense-in-depth approach it has already adopted.

The authors conclude that supply-chain security requires repeatedly asking what happens if a trusted component is compromised and then adding layers that limit blast radius. Cilium’s strategy combines access controls, pinned digests, least privilege, credential isolation, and signatures. While no combination guarantees invulnerability, openly sharing both successes and remaining weaknesses raises the baseline for the entire open source ecosystem.