DEV Community

Hritik Raj
Hritik Raj

Posted on

My Journey into GitHub Security: A Hands-On DevOps Challenge

#github #getfitwithsagar #srelife #devopsforall

Hello, fellow learners!

I'm currently on a journey to sharpen my DevOps and SRE skills, and I've been following the DevOps SRE Daily Challenge series. Today’s task was a deep dive into something absolutely critical: GitHub Security.

We all use GitHub, but how many of us have actually configured a repository to be truly secure and collaborative? I decided to take the challenge head-on, and I wanted to share what I learned along the way.

The Mission: Build a Fortress for Our Code

The objective was clear: create a secure and collaborative GitHub environment for a sample project. This wasn't just about writing code; it was about building the infrastructure around it to ensure quality, prevent mistakes, and automate security.

Here's a breakdown of my adventure.

Step 1: Laying the Foundation with a GitHub Organization

Before this challenge, I mostly worked in personal repositories. The first step was to create a proper GitHub Organization. This was a game-changer.

  • Creating an Org (DevOps-Challenge-Org): This immediately felt more professional. It created a central hub for all our project's assets.
  • Building Teams (Developers, DevOps, QA): Instead of giving permissions to individuals, I created teams. This made managing access so much cleaner. When a new developer joins, I just add them to the Developers team, and they instantly get the right access to all the repos they need.
  • Enforcing 2FA: The first security action I took was requiring Two-Factor Authentication for everyone in the org. It's a simple click in the settings, but it instantly raises the security baseline for every single member.

My takeaway: Organizations and teams aren't just for big companies. They provide a clear structure and control that's valuable for any project with more than one person.

Step 2: Locking the main Branch

This was my favorite part. The main branch is sacred, and it should be treated that way. I went to Settings → Branches and set up protection rules for main.

  1. Require a pull request before merging: I disabled direct pushes. This single setting forces every change, no matter how small, to go through a review process. No more "quick fixes" pushed directly to production!
  2. Require 2 approvals: A single approval is good, but two is better. This enforces a "four-eyes principle," ensuring that multiple people have vetted the code.
  3. Require status checks to pass: This is where the automation kicks in. I configured it so that a PR can't be merged unless all our automated checks (like tests, builds, and security scans) are green.
  4. Include administrators: I checked this box to make sure that even repository admins have to follow the rules. No one is above the process!

My takeaway: Branch protection rules are the "constitution" for your repository. They set the rules of engagement and ensure that every change is deliberate, reviewed, and tested.

Step 3: Automating the Gatekeepers with Bots

Manually reviewing every line of code for security flaws or dependency issues is impossible. This is where automation becomes your best friend.

  • Dependabot: I enabled this in the repository settings under Security & analysis. It's like having a dedicated team member who constantly checks my project's dependencies for known vulnerabilities and automatically opens PRs to fix them.
  • Coderabbit: I'd heard about AI code reviewers, and this was my first time using one. I installed the Coderabbit app from the Marketplace. On my next PR, it popped up with comments and suggestions pointing out potential bugs and style issues. It felt like getting an instant, preliminary review before a human even had to look at it.
  • Snyk: For an even deeper vulnerability scan, I integrated Snyk. I connected my repo, and Snyk performed a deep scan of my dependencies. I then added the Snyk scan as a required status check in my branch protection rules. Now, a PR will be blocked if it introduces a new high-severity vulnerability.

My takeaway: Security isn't a one-time check. By integrating these bots, I've created a continuous security monitoring system that works 24/7.

Step 4: The Final Polish - Secrets and CODEOWNERS

Two final pieces really tied everything together:

  1. GitHub Secrets: I practiced adding dummy secrets like API_KEY to the repository's Settings → Secrets and variables → Actions. Knowing how to use these means I'll never be tempted to hardcode a password or API key in my code again.
  2. CODEOWNERS file: I created a file at .github/CODEOWNERS to automatically assign reviewers based on which files were changed. For example, any changes to .js files would automatically loop in the @DevOps-Challenge-Org/Developers team. This removes the guesswork of figuring out who should review a PR.

Final Thoughts

This challenge was incredibly insightful. It took me from thinking of GitHub as just a place to store code to seeing it as a powerful platform for building secure, automated, and collaborative workflows. If you're a developer or aspiring SRE, I can't recommend a hands-on exercise like this enough.

What are your go-to GitHub security practices? I'd love to hear them in the comments!

#getfitwithsagar #SRELife #DevOpsForAll

Top comments (0)