In this blog post, you will learn how to set up image scanning with GitHub Actions using the Sysdig Secure DevOps Platform. We will create a basic workflow to perform a local scan to detect vulnerabilities and bad practices before the image is pushed to any registry. We will also customize scanning policies to stop the build according to a set of defined rules.
In the Kubernetes / container world, image scanning refers to the process of analyzing the contents and the build process of a container image in order to detect security issues, vulnerabilities or bad practices. Inline scanning has some benefits opposed to a traditional approach, where the image is first pushed to a registry, and then pulled and scanned from an external tool:
- First, the image is analyzed locally, and not sent anywhere outside the build environment. It provides confidentiality and prevents the image from being published in case it is not compliant with defined policies.
- The scanner generates metadata that is evaluated against the compliance policies. In case a policy is modified, compliance can be reevaluated instantly without re-scanning the image.
Vulnerability scanning on GitHub repositories
As nearly every deployed container is built on top of other community-contributed images, bottom layer vulnerabilities and bad practices, like privileged containers or unsafe ports, can compromise your whole infrastructure. Image scanning has become a critical step in CI/CD workflows by introducing security earlier in the development process (security shift-left).
GitHub actions allow you to automate software development tasks directly in your git repositories, creating powerful CI/CD workflows triggered by different events. A growing number of preexisting actions for the most common tasks can be found in the GitHub Marketplace, or you can create a totally customized workflow and write your own actions. Using actions is simple, as we will demonstrate by including the Sysdig Secure Inline Scan action.
Our workflow will build our code into a Docker image, then it will locally scan the image using the Sysdig Secure Inline Scan action. The scan results will then be sent to Sysdig. If the scan fails, the workflow breaks, preventing the image from being uploaded into a registry.
Creating GitHub Action that triggers Image Scanning
Prerequisites
The requirements for getting Sysdig Image Scanning up and running are straight forward:
- A GitHub repository and administrative permissions, as they are required to enable Actions and to manage Secrets.
- A Sysdig Secure account to configure Image Scanning Policies; also, where the results of the scans will be collected. You can request a demo if you already don’t have one.
- Some container Dockerfile ready to be built. You can fork and use our example, but using your own container is funnier!
Once you are ready, let’s move on!
Enable GitHub Actions in your repository
If you did not activate Actions for your repository, the first step is making sure third-party Actions are enabled. Navigate to your repository Settings and look for the Actions section ( https://github.com/<user>/<repo>/settings/actions).
There, make sure the Enable local and third-party Actions for this repository option is selected:
Once actions are enabled, you should get an Actions tab at the top navigation bar on your repository main page, like this:
Set up an image scanning workflow on GitHub
GitHub Actions is the feature that allows the automation of CI/CD software workflows directly in your GitHub Repositories. It borrows the name from the actions, automated tasks that are combined to create workflows. So our journey will start by creating and configuring a new Workflow.
From the Actions tab, click the New workflow button on the top left:
You’ll be presented with some predefined workflows based on the project type and some popular workflows. You can see the code from these workflows in the Starter Workflows repository, and there are very good examples to learn from. You can choose one of these, and then include the Image Scanning action. But we will start a Workflow from scratch by clicking Set up a workflow yourself in the top right corner of the window:
Let’s change the default main.yml name to something more appropriate, like image-scan.yml, and edit the workflow YAML in the embedded editor to use the following steps:
name: Build and scan Docker Image
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Build the Docker image
run: docker build . --file Dockerfile --tag sysdiglabs/dummy-vuln-app:latest
For more details about using GitHub actions, check the official documentation. But let’s do a quick overview. We are defining a Workflow with name “Build and scan Docker Image” (that is the name that will be displayed in the actions UI in your repository). The workflow is triggered every time a push happens in the repo, and we are defining a job with job_id build that runs-on an ubuntu-latest runner hosted by GitHub, and executes a list of steps, sequentially. Of course, there are many types of triggers available. You can execute multiple jobs in parallel and define dependencies and data flow between jobs. Additionally, you can execute on different types of workers, including your own self-hosted runners, and much more.
For this job, we have declared two steps, that are being executed in the runner.
- The first step has no name (it is an optional attribute, just used for display purposes), and we tell that step to use the action actions/checkout@v1, which you can find on https://github.com/actions/checkout.
- The second one, with name “Build the Docker image”, is not using an action, but we instead simply run the command docker to build an image.
The GitHub runners come with a pretty extensive set of tools pre-installed, which should fit most typical use cases, like building a Docker image in our example.
Let’s now include a new step that will trigger the image scanning, by adding:
- name: Scan image
uses: sysdiglabs/scan-action@v1
with:
image-tag: "sysdiglabs/dummy-vuln-app:latest"
sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }}
We are declaring a new named step that uses sysdiglabs/scan-action@v1 (check the action code in this repository), and receives a couple of parameters:
- image-tag: The tag of the local image to scan, which should match the tag we used in the docker build step.
- sysdig-secure-token: The API token for authenticating in Sysdig Secure, which is used for retrieving the policies and publishing the results. For the sake of security, never put the API token in the yaml file. Instead, create a GitHub secret named
SYSDIG_SECURE_TOKENand reference that secret using the syntax${{ secrets.SYSDIG_SECURE_TOKEN }}.
As you can see, adding a new action step to the job is really simple. But it can be even simpler: there’s no need to remember the action name and the syntax, or read the documentation. The Marketplace tab next to the editor allows you to quickly search for available actions in the marketplace:
And copy the YAML snippet directly into your workflow.
There are some more parameters available in the Sysdig Secure Inline Scan action, but defaults are just right for most use-cases.
Once you have finished with the YAML, click the Start commit button on the top right. Add a message and an optional description, and commit the change.
GitHub actions workflows are simply a .yml file in .github/workflows/ inside your repository. That means that there is no need to go through the Actions UI. You can create a new workflow without taking your hands off the keyboard by simply adding .github/workflows/my-shiny-workflow.yml into your repository, then committing and pushing the changes.
Image scanning on GitHub: Lights, camera, action!
Provided you have a Dockerfile in your repository and a valid Secure API token, the commit of the workflow you just created should trigger the execution of the Workflow, build the image and scan it.
You can navigate to the Actions section of the repo to see the result of the Workflow execution:
And click into the Workflow execution to get a detailed view of every step, get the logs, etc.:
The analysis results are posted to your Sysdig Secure account under Image Scanning -> Scan Results:
Notice that multiple vulnerabilities were detected in the scan step, but job and workflow are success as the Scan Result is passed. On a typical workflow, after the scan you would publish the image by pushing it to the registry. But publishing an image with critical security issues is not a good idea. We should interrupt the job and break the build depending on the scanning results.
Breaking the build when vulnerabilities are found
Inside Sysdig Secure, you can define Image Scanning Policies and then assign those policies to a subset of registries, repositories, and tags.
By default, the Default Policy gets assigned to all registries, repositories and tags, and the vulnerabilities we found in the image are not enough to stop the build. In the analysis results, you can appreciate that there are 67 Warns, but no Stops.
To make the build fail, let’s go to Image Scanning -> Policies and edit the Default Policy, changing the latest rule in the screenshot (port 22 exposed in the Dockerfile) from Warn to Stop:
Back to the scan results, you can see that as soon as a policy is changed, the rules are reevaluated, and our previous scan now does not pass:
These changes will apply immediately. When using a Kubernetes Admission controller to block vulnerable images, new pods won’t be created. But in our CI/CD pipeline with GitHub Actions, as the scan is performed right after the Docker image is built, we need to trigger a change in the repository to execute the action again. The scan runs again, this time it fails due to the policy configuration, and the build breaks:
Conclusions
As you can see, GitHub Actions provides a powerful tool to automate your CI/CD pipelines directly on your GitHub repository. Now it is easy and straightforward to include Sysdig Secure Inline Scan in your workflow, scanning images for vulnerabilities and enforcing best practices at build time. This provides several benefits over traditional image scanning within the registry:
- Implements image scanning in the CI/CD pipeline to find vulnerabilities and prevent the image from being published at all.
- Performs analysis inline (locally) in the runner – the image is not sent anywhere else, including outside of the environment in which it’s built. During the analysis, only metadata information, and not the actual contents, is extracted from the image.
- Metadata obtained from the analysis can be reevaluated later if new vulnerabilities are discovered or policies are modified without requiring a new scanning of the image for alerting. If you want to break the build, you still need to trigger a new scan within the build.
- Sysdig Secure provides out-of-the-box policies to enforce and adhere to various container compliance standards (like NIST 800-190 and PCI)..
Sysdig Secure image scanning also integrates seamlessly with most CI/CD pipeline tools including Jenkins, Bamboo, Azure Pipelines or AWS CodePipelines.
If you are not using Sysdig Secure for scanning your images yet, wait no longer and request a demo now!