kubernetessecurityPractitioner

Locking Down Dependencies in CI/CD: A Must for Open Source Projects

5 min read CNCF BlogJun 12, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Securing your CI/CD pipeline is essential, especially for open source projects where dependencies can introduce vulnerabilities. The single most impactful measure you can take is to stop trusting mutable tags. By pinning GitHub Actions by SHA digest, you ensure that your workflows only pull in trusted code, significantly reducing the risk of introducing compromised dependencies.

When you pin an action like actions/checkout@de0fac2e, you know exactly which code runs for that action. However, be aware of transitive dependencies—if actions/checkout references another action by tag, that resolution happens at runtime and is invisible to you. To maintain control, use Renovate to manage your SHA pins. Configure Renovate with parameters like pinDigests set to true globally, which automatically pins GitHub Action digests. Additionally, you can set a minimumReleaseAge of 5 days to avoid pulling in freshly published versions that may not be stable. This way, you can ensure that your dependencies are both secure and reliable.

In production, remember that simply pinning dependencies is not enough. You must also vendor all Go dependencies and verify there’s no drift between go.mod, go.sum, and vendor/. This practice helps maintain consistency across your builds. Be cautious, as a pinned workflow that fetches a compromised dependency is still a compromised workflow. Regularly review your dependencies and keep your Renovate configuration updated to adapt to new security challenges.

Key takeaways

→Pin GitHub Actions by SHA digest to prevent compromised code.
→Use Renovate to automate SHA pinning and manage dependency updates.
→Vendor all Go dependencies to ensure consistency across builds.
→Set minimumReleaseAge to avoid unstable versions.
→Regularly review dependencies to adapt to security challenges.

Why it matters

In production, a single compromised dependency can lead to significant security breaches. By locking down your dependencies, you protect not just your project but also your users and the broader ecosystem.

Code examples

json5

1{
2  "matchUpdateTypes": ["major", "minor", "patch"],
3  "minimumReleaseAge": "5 days"
4},
5{
6  "matchPackageNames": [
7    "actions/{/,}**",
8    "docker/{/,}**",
9    "cilium/{/,}**",
10    "k8s.io/{/,}**",
11    "sigs.k8s.io/{/,}**",
12    "golang.org/x/{/,}**",
13    "github.com/golang/{/,}**",
14    "github.com/prometheus/{/,}**",
15    "github.com/hashicorp/{/,}**",
16    "go.etcd.io/etcd/{/,}**"
17  ],
18  "automerge": true,
19  "automergeType": "pr",
20  "groupName": "auto-merge-trusted-deps",
21  "reviewers": ["ciliumbot"]
22}

YAML

if: ${{
  github.event.pull_request.user.login == 'cilium-renovate[bot]' &&
  (github.triggering_actor == 'cilium-renovate[bot]' ||
  github.triggering_actor == 'auto-committer[bot]')
}}

Bash

go run ./tools/licensecheck

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Better StackSponsor

Unified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.

Try Better Stack free →

Locking Down Dependencies in CI/CD: A Must for Open Source Projects

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Mastering IAM in Kubernetes: Beyond the Basics

Securing CI/CD in Open Source: Mastering Workflow Control

Inspektor Gadget Security Audit: What You Need to Know