Automating Security Updates for Prometheus LTS: My First CNCF Contribution

I’ve always loved DevOps, but contributing to an actual CNCF project? That felt like standi

.

In Prometheus, LTS branches are like the “golden retrievers” of releases: reliable, stable, and supported for a long time (over a year!). They only get:

• Bug fixes


• Security patches


• Documentation updates

…everything else? Nope. Experimental features or new fancy stuff are off-limits. The reasoning is simple: companies rely on these branches for monitoring critical systems. They don’t want surprises that could cause sudden breakdown to their large systems.

I focused on two active LTS branches: release-2.53 and release-3.5. Think of them as my training wheels.

Step 2: Why Security Updates Matter

Security updates aren’t glamorous, but they’re life-saving. Imagine a dependency getting hacked while you’re havaing breakfast with the ex you've been trying to get back with, it’s the worst kind of surprise.

GitHub has a neat helper called Dependabot that automatically opens PRs for vulnerable dependencies. My job? Configure it safely for LTS.

Key rules I followed:

1. Update only Go modules (go.mod) and GitHub Actions


2. Apply updates only to LTS branches


3. Make it security-only, no random feature upgrades


4. Limit PRs to avoid spam: max 2 for Go, 1 for Actions per branch


5. Schedule weekly checks, because daily emails are a nightmare

Step 3: The Contribution Workflow

Here’s how my first PR went down, step by step:

1. Forked the Prometheus repo (because direct access is scary)


2. Cloned my fork locally


3. Created a branch named ci/dependabot-lts-security (naming matters!)


4. Added .github/dependabot.yml with the config I just described


5. Committed my changes with a DCO sign-off (promised I wrote this myself, pinky swear)


6. Pushed the branch and opened a PR

Step 4: What I Learned

• Read the rules first. LTS policies exist for a reason, don’t ignore them.


• DCO matters. Sign-off your commits; it’s a CNCF thing, not a bureaucratic nightmare.


• Automation is powerful. A single Dependabot config can save maintainers hours of toil.


• Initiative is welcome. Maintainers expect new contributors to take the first step.

Honestly, nothing felt cooler than seeing that PR button: “Create Pull Request.” A mix of pride, terror, and adrenaline.

Step 5: The Dependabot Config (Our Tiny Hero)

Here’s what I added(remember, no don't leave a blankspace or a line empty):

version: 2



updates:

  - package-ecosystem: "gomod"

    directory: "/"

    target-branch: "release-2.53"

    schedule:

      interval: "weekly"

    security-updates-only: true

    open-pull-requests-limit: 2



  - package-ecosystem: "gomod"

    directory: "/"

    target-branch: "release-3.5"

    schedule:

      interval: "weekly"

    security-updates-only: true

    open-pull-requests-limit: 2



  - package-ecosystem: "github-actions"

    directory: "/"

    target-branch: "release-2.53"

    schedule:

      interval: "weekly"

    security-updates-only: true

    open-pull-requests-limit: 1



  - package-ecosystem: "github-actions"

    directory: "/"

    target-branch: "release-3.5"

    schedule:

      interval: "weekly"

    security-updates-only: true

    open-pull-requests-limit: 1