DEV Community

Calvine Otieno for AWS Community Builders

Posted on

Improving your CI/CD Pipeline: Helm Charts Security Scanning with Trivy and GitHub Actions

Image description

Originally published by me on Medium

DevOps has gained momentum over the past few years and it’s continuing to grow each day. Many organizations small, medium or big embrace DevOps processes. The automation of manual processes in the software development life cycle and faster release of features to customers are some of the key roles that DevOps culture brings to any organisation.

With growing automation and CI/CD tools in the market, security has become a major concern. The rise of Containers and IaC has led to major security issues and hence the rise of DevSecOps. DevSecOps is a concept where DevOps is augmented with security best practices early in the life of the Software Development Life Cycle (SLDC). Scanning the resultant artefacts be it docker images or Helm Charts for vulnerabilities is an essential part of that life cycle, especially for cloud-native environments.

In this article, I will demo how we can perform automated vulnerability scans for Helm Charts using GitHub Actions and Trivy.

Image description

Trivy and Github Actions Workflow

What is Trivy?

Trivy is an open-source project by Aqua Security. It’s a vulnerability/misconfiguration scanner for artefacts like container images, filesystems/rootfs, Helm Charts, and git repositories. It has a comprehensive detection for OS and language-specific packages, as well as Infrastructure as code files like Terraform. With Trivy, you can integrate this scanning with your CI/CD platform before you publish/deploy the artefacts to production.

Trivy supports table, json, and sarif outputs formats. Sarif scan output can be written to the GitHub repo Security tab(for private repositories, you need Github advanced license).

Prerequisites

You need to have some basic knowledge of working with Helm Charts and GitHub Actions.

  • Helm Charts installed in your local machine
  • Trivy installed in your local machine
  • A public GitHub Repository

And of course a code editor of your choice 😀.

Let’s start

Create a sample helm chart by running this command in your terminal:

helm create sample-helm-devsecops
Enter fullscreen mode Exit fullscreen mode

This command will create a helm chart name sample-helm-devsecops.

For the sake of this quick demo, we will be concentrating much on deployment.yaml file.

Create a new folder name chart and move the sample-helm-devsecops folder and its content there.

Let us do a trivy scan of our just created chart by running this command:

trivy config charts/sample-helm-devsecops
Enter fullscreen mode Exit fullscreen mode

You should see something like this:

Image description

**Here we have Tests: 79 (SUCCESSES: 67, FAILURES: 12, EXCEPTIONS: 0)

Failures: 12 (UNKNOWN: 0, LOW: 10, MEDIUM: 2, HIGH: 0, CRITICAL: 0)**

Nice. We are done with our first step.

Create A GitHub Repo and Github Action

Now that we have the chart set up, we can go ahead and push it to our GitHub repository.

Go ahead to your GitHub and create a repository, here I called mine sample-helm-devsecops. I will assume you know how to add a remote origin and push your code. This article will not cover Git and GitHub fundamentals.

After pushing your chart, let us create a workflow that will:

  • Run Trivy vulnerability scanner in IaC mode
  • Upload Trivy scan results to the GitHub Security tab

Create a folder named .github and inside it add another folder workflows. In the workflows folder, create a file trivy-secops.yaml with the following content:

name: trivy-security-scanning
on: push

permissions:
  security-events: write # To upload sarif files

jobs:
  chart-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@93ea575cb5d8a053eaa0ac8fa3b40d7e05a33cc8 # tag=v3.1.0
        with:
          fetch-depth: 0

      - name: Set up Helm
        uses: azure/setup-helm@f382f75448129b3be48f8121b9857be18d815a82 # tag=v3.4
        with:
          version: v3.6.3

      - name: Set up python
        uses: actions/setup-python@13ae5bb136fac2878aff31522b9efb785519f984 # tag=v4.3.0
        with:
          python-version: 3.7

      - name: Run Trivy vulnerability scanner in IaC mode
        uses: aquasecurity/trivy-action@9ab158e8597f3b310480b9a69402b419bc03dbd5 # tag=0.8.0
        with:
          scan-type: 'config'
          hide-progress: false
          format: 'sarif'
          scan-ref: 'charts/sample-helm-devsecops'
          output: 'trivy-results.sarif'
          exit-code: '1'
          ignore-unfixed: true

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@312e093a1892bd801f026f1090904ee8e460b9b6 # v2.1.34
        with:
          sarif_file: 'trivy-results.sarif'

Enter fullscreen mode Exit fullscreen mode

Here we are doing all the severity-level scans (LOW, MEDIUM, HIGH, and CRITICAL).

git add and push the changes to GitHub. Check the Actions tab and you should see a workflow running. It will fail because of the vulnerabilities we saw earlier.

Now go to the Security Tab and then click the Code scanning tab, you should see something like this:

Image description

You can see Trivy scanned our helm chart and uploaded the scan to Github Security Tab. From here we can create issues for these vulnerability scans and assign them to developers. Once the issue is fixed and the changes pushed, Trivy will run the scan again and the issue will be closed.

Demo: Create an issue for vulnerability number #1 — Process can elevate its own privileges

Click the issue and it should take you to a new window giving a description of the severity. There you can create a GitHub issue and it will automatically link the vulnerability with the issue. This helps you to track the vulnerability and automatically close them with a PR fixing the issue.

Create a GitHub Issue for the vulnerability

Image description

Image description

Once we merge the PR, the issue should be closed and vulnerability #1 should be solved.

Image description

You can see the issue has been resolved and in our recent scan it’s not there.

You can now repeat these steps to fix the remaining issues and once done, your scan results should be clean.

Image description

This is all for now. I hope you have learnt something and enjoyed reading the article. Next article we will focus on doing the same with Gitlab CI.

Here is the repo for this article. Follow me on GitHub for more about DevOps and DevSecOps.

Thanks for reading. Let’s connect on Twitter and LinkedIn 😁.

Top comments (0)