GitHub Security Scanning Solutions For GitLab CI CD Pipeline Migration

Migrating your CI/CD pipeline from GitLab to GitHub? That's a big move, guys! And when you're making that switch, security is super important. You need to make sure you're still catching vulnerabilities and secrets just like you were in GitLab. In this article, we'll break down how to find alternative security scanning solutions for GitHub migrations, focusing on replacing your existing GitLab security scans with GitHub Actions. We'll dive deep into creating GitHub Actions workflows that mimic your current GitLab setup, ensuring a smooth and secure transition. So, let's get started and make this migration a secure one!

Understanding the GitLab Security Setup

Before we jump into GitHub Actions, let's understand your existing GitLab setup. You've got two key parts:

1. Vulnerability Scanning: This uses Semgrep for Static Application Security Testing (SAST). SAST tools analyze your code for potential vulnerabilities before you even run it. This is crucial for catching issues early in the development process. Semgrep is a fantastic tool, known for its speed and accuracy in identifying a wide range of security flaws. It's like having a security expert review your code automatically.
2. Secret Detection: This scans your codebase for accidentally committed secrets, like passwords, API keys, and other sensitive information. We've all been there – accidentally committing something we shouldn't have! Secret detection helps you catch these mistakes before they become a bigger problem. This is a critical part of your security posture, preventing potential data breaches and unauthorized access.

You're using specific GitLab CI/CD templates (Jobs/Secret-Detection.gitlab-ci.yml and Jobs/SAST.gitlab-ci.yml) to handle these scans. The semgrep-sast job runs Semgrep, and the secret_detection job looks for secrets. These jobs generate reports (gl-sast-report.json and gl-secret-detection-report.json) that are then used to determine if the pipeline should pass or fail.

The next step in your GitLab workflow is checking these reports. The check-sast-report job parses the gl-sast-report.json file to identify vulnerabilities. It specifically looks for critical vulnerabilities and fails the pipeline if any are found. This is a great way to prevent vulnerable code from being merged into your main branch. The check-secrets job scans the gl-secret-detection-report.json file for any detected secrets and also fails the pipeline if any are found. This is vital for preventing sensitive information from leaking into your codebase.

This setup is solid! You're using SAST and secret detection to proactively identify security issues. Now, let's see how we can replicate this in GitHub Actions.

GitHub Actions: Your Security Scanning Powerhouse

GitHub Actions is GitHub's built-in CI/CD platform, and it's perfect for automating security scans. It's flexible, powerful, and integrates seamlessly with your GitHub repositories. Think of it as your new security command center! We're going to create workflows – automated processes – that run the same security checks you had in GitLab.

Key Concepts of GitHub Actions

Before we dive into the code, let's quickly review some key concepts:

• Workflows: These are the automated processes we create. They're defined in YAML files and live in your .github/workflows directory.
• Jobs: A workflow is made up of one or more jobs. Each job runs on a virtual machine and performs a specific task.
• Steps: A job is made up of one or more steps. Each step executes a command or runs an action.
• Actions: These are reusable units of code that perform specific tasks. There are tons of pre-built actions available, and you can also create your own.
• Secrets: Securely store sensitive information like API keys and passwords. You can access these secrets within your workflows without exposing them in your code.

Replicating Semgrep SAST with GitHub Actions

Let's start by replicating the Semgrep SAST scan. There are a couple of ways to do this. One option is to use the official Semgrep GitHub Action. This action makes it super easy to run Semgrep scans on your code.

Here’s how you can implement Semgrep SAST with GitHub Actions: We can leverage the power of GitHub Actions to seamlessly integrate Semgrep into our CI/CD pipeline. To begin, we need to craft a YAML file within the .github/workflows directory of our repository. This file will define our workflow, outlining the steps required to perform the Semgrep scan. At the heart of this workflow is the use of a pre-built Semgrep GitHub Action, which streamlines the process of running Semgrep scans. We configure this action to analyze our codebase for potential vulnerabilities, leveraging Semgrep's robust detection capabilities. The action will generate a report detailing any identified issues, which we can then use to take corrective action. This proactive approach to security ensures that vulnerabilities are caught early in the development lifecycle, minimizing the risk of introducing security flaws into our production environment. By automating the Semgrep scan with GitHub Actions, we can enforce consistent security checks across all our code changes, enhancing the overall security posture of our project. The ability to customize the Semgrep ruleset used in the scan allows us to tailor the analysis to the specific needs and risks associated with our application. This flexibility ensures that we are focusing our efforts on the most critical vulnerabilities, making our security efforts more efficient and effective. In addition to identifying vulnerabilities, Semgrep can also help us enforce coding standards and best practices, further improving the quality and security of our code. By integrating Semgrep into our CI/CD pipeline, we are not only detecting potential security flaws but also promoting a culture of security-conscious development within our team.

name: Semgrep SAST

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Semgrep Scan
        uses: returntocorp/semgrep-action@v1
        with:
          # Adjust this to your needs, e.g., to include specific rules
          sarif_file: semgrep-report.sarif

      - name: Upload SARIF Results to GitHub Code Scanning
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: semgrep-report.sarif

This workflow does the following:

1. Triggers: Runs on pushes to the main branch and pull requests targeting the main branch.
2. Job: Defines a job called semgrep that runs on an Ubuntu virtual machine.
3. Steps:
   • Checkout: Checks out your code using the actions/checkout@v3 action.
   • Semgrep Scan: Runs the Semgrep scan using the returntocorp/semgrep-action@v1 action. We specify the sarif_file output, which will store the scan results in SARIF format.
   • Upload SARIF Results: Uploads the SARIF report to GitHub Code Scanning using the github/codeql-action/upload-sarif@v2 action. This allows you to view the Semgrep findings directly in GitHub's security tab.

This is a basic setup, but you can customize it further. For example, you can specify which Semgrep rules to use, exclude certain files or directories from the scan, and more. Semgrep is highly configurable, allowing you to tailor the scans to your specific needs.

Implementing Secret Detection with GitHub Actions

Now, let's tackle secret detection. Just like with SAST, there are several GitHub Actions available for this. One popular option is the gitleaks action, which uses the Gitleaks tool to scan your repository for secrets. Gitleaks is a powerful tool for identifying secrets like passwords, API keys, and tokens that may have been accidentally committed to your repository.

Here’s how you can integrate secret detection with GitHub Actions: In order to detect secrets, we will integrate gitleaks into GitHub Actions. By integrating gitleaks, we can proactively identify and prevent the leakage of sensitive information, such as passwords, API keys, and tokens. The first step involves defining a new workflow within the .github/workflows directory of our repository. This workflow will be triggered on every push and pull request, ensuring that all code changes are scanned for secrets. Within the workflow, we will utilize the gitleaks action, which simplifies the process of running gitleaks scans. The action will analyze the commit history and current state of our repository, searching for patterns that match known secret formats. When a secret is detected, the action will generate a report detailing the findings, including the location of the secret and the type of secret detected. This report can then be used to take corrective action, such as revoking the compromised secret and updating the codebase to remove the secret. By automating the secret detection process with GitHub Actions and gitleaks, we can significantly reduce the risk of exposing sensitive information and maintain the integrity of our application. The ability to customize the gitleaks configuration allows us to tailor the scans to our specific needs, such as adding custom secret patterns or excluding certain files or directories from the scan. This flexibility ensures that our secret detection efforts are focused on the most critical areas of our codebase.

name: Secret Detection

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0 # Required for Gitleaks to scan the entire history

      - name: Gitleaks Scan
        uses: zricethezav/gitleaks-action@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

This workflow is similar to the Semgrep workflow. It:

1. Triggers: Runs on pushes to the main branch and pull requests targeting the main branch.
2. Job: Defines a job called secrets that runs on an Ubuntu virtual machine.
3. Steps:
   • Checkout: Checks out your code using the actions/checkout@v3 action. Important: We set fetch-depth: 0 to ensure Gitleaks scans the entire commit history. This is crucial for finding secrets that may have been committed in the past.
   • Gitleaks Scan: Runs the Gitleaks scan using the zricethezav/gitleaks-action@v1 action. We pass the GITHUB_TOKEN as an environment variable, which is required for the action to access the repository.

Gitleaks is also highly configurable. You can define custom rules, ignore specific files or directories, and more. You can even configure it to automatically redact secrets from your commit history!

Checking Vulnerability Reports in GitHub Actions

Okay, we've got our SAST and secret detection scans running. Now, we need to replicate the report checking logic from your GitLab setup. Remember those check-sast-report and check-secrets jobs? We need to do something similar in GitHub Actions.

This is where things get a little more manual. There isn't a single pre-built action that exactly replicates your GitLab report checking logic. But don't worry, we can easily create our own steps using shell scripts and some of the tools you're already familiar with (like jq).

Let's start with the SAST report checking. We'll need to:

1. Parse the Semgrep SARIF report: We'll use jq to extract the number of vulnerabilities and the number of critical vulnerabilities.
2. Check for critical vulnerabilities: If any critical vulnerabilities are found, we'll fail the workflow.
3. Check for other vulnerabilities: If no critical vulnerabilities are found but other vulnerabilities exist, we'll still fail the workflow (you mentioned you want to take a look at these).

Here's how we could write a GitHub Actions step to check the SAST report: Crafting a robust security pipeline involves more than just running scans; it also entails meticulously analyzing the generated reports to identify and address vulnerabilities. In our SAST report checking step, we will leverage the power of jq, a lightweight and flexible command-line JSON processor, to parse the Semgrep SARIF report. This allows us to extract key metrics, such as the total number of vulnerabilities and the count of critical vulnerabilities. By programmatically analyzing the report, we can automate the decision-making process, ensuring that critical issues are promptly flagged and addressed. If our analysis reveals the presence of critical vulnerabilities, we will configure the workflow to fail, preventing the deployment of potentially vulnerable code. This proactive approach helps to minimize the risk of introducing security flaws into our production environment. Even in the absence of critical vulnerabilities, we will still flag the presence of other vulnerabilities, prompting a thorough review and remediation effort. This comprehensive approach to vulnerability management ensures that we are not only addressing the most pressing issues but also continuously improving the overall security posture of our application. By integrating this report checking step into our GitHub Actions workflow, we can automate the analysis process, saving valuable time and resources while maintaining a high level of security assurance. The ability to customize the report checking logic allows us to tailor the analysis to the specific needs and risks associated with our application, ensuring that we are focusing our efforts on the most critical vulnerabilities.

- name: Check Semgrep Report
  if: always() # Run this step even if the Semgrep scan fails
  run:
    |      
      # Check if sarif file exists
      if [ ! -f semgrep-report.sarif ]; then
        echo "Semgrep report not found. Skipping check."
        exit 0
      fi

      array_length=$(jq '.runs[0].results | length' semgrep-report.sarif)
      if [ "$array_length" -gt 0 ]; then
        echo "$array_length Vulnerabilities found!"
        critical_count=$(jq '[.runs[0].results[] | select(.properties.security-severity ==