Integrating Security Gates in CI/CD

What is a Security Gate?

In a CI/CD pipeline, a security gate is an automated step that enforces a security policy. If the policy is violated, the pipeline is stopped. For our purposes, the policy will be:

"The pipeline must fail if the Docker image contains vulnerabilities of CRITICAL or HIGH severity."

Vulnerability scanners can enforce this by returning a non-zero exit code when they find vulnerabilities that meet or exceed a specified threshold. Since CI/CD systems like GitHub Actions treat a non-zero exit code from any step as a failure, this simple mechanism effectively "closes the gate" and stops the build.

Let's see how to implement this using a couple of popular tools.

Implementing a Security Gate with Docker Scout

Docker Scout is a set of software supply chain features integrated directly into Docker. It replaces the older docker scan command and provides powerful tools for analyzing image contents and vulnerabilities right from your command line.

To get started, let's explore what Docker Scout is and how it works.

The real power comes from integrating this scan into our automated workflow. We will now watch a detailed walkthrough that shows how to add docker scout to a CI script to create a security gate.

Integrating Docker Scout into GitHub Actions

Based on the video, let's see how to add the security gate to our build-and-push job in the GitHub Actions workflow. The scan should happen right after the image is built but before it's pushed.

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # You would still have your login steps if pushing
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build the Docker image
        id: build
        run: |
          IMAGE_TAG="myapp:insecure"
          docker build -t $IMAGE_TAG .
          echo "IMAGE_TAG=${IMAGE_TAG}" >> $GITHUB_OUTPUT

      # The Security Gate
      - name: Scan image for vulnerabilities
        run: |
          docker scout cves ${{ steps.build.outputs.IMAGE_TAG }} \
            --exit-code \
            --only-severity critical,high
      
      # This step will only run if the scan above passes (exit code 0)
      - name: Push the Docker image
        run: |
          echo "Vulnerability scan passed. Pushing image..."
          # In a real workflow, this would be your docker/build-push-action step
          # docker push ${{ steps.build.outputs.IMAGE_TAG }}

The key part is the Scan image for vulnerabilities step.

• --exit-code: This flag tells Docker Scout to exit with a non-zero status code if vulnerabilities are found that match the filter criteria.
• --only-severity critical,high: This is our policy. We are instructing the gate to only consider critical and high severity vulnerabilities.

If the scan finds a CRITICAL or HIGH vulnerability, this step will fail, and the Push the Docker image step will never be reached.

Implementing a Security Gate with Trivy

While Docker Scout is convenient, Trivy by Aqua Security is an extremely popular, open-source, and versatile scanner that is widely used in many CI/CD systems. It's an excellent tool to have in your DevOps toolkit.

The article below provides several examples of integrating different scanners into a CI/CD pipeline. We'll focus on its Trivy examples.

Using the official trivy-action for GitHub Actions, our security gate step becomes very clear and declarative.

      # Build step remains the same...
      - name: Build the Docker image
        id: build
        run: |
          IMAGE_TAG="myapp:insecure"
          docker build -t $IMAGE_TAG .
          echo "IMAGE_TAG=${IMAGE_TAG}" >> $GITHUB_OUTPUT

      # The Security Gate using Trivy
      - name: Run Trivy Vulnerability Scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ steps.build.outputs.IMAGE_TAG }}
          format: 'table'
          # Set the policy: fail on CRITICAL or HIGH severities
          exit-code: '1'
          severity: 'CRITICAL,HIGH'
          # Optional: Don't fail for vulnerabilities that don't have a fix yet
          ignore-unfixed: true 

This configuration achieves the exact same outcome as the Docker Scout example. The trivy-action will scan the image specified in image-ref. If it finds vulnerabilities matching the severity list, it will exit with code 1, failing the workflow. The ignore-unfixed: true parameter is a common and practical setting to avoid failing builds for vulnerabilities that you cannot yet patch.

      # First, scan for CRITICAL vulnerabilities and fail the build if found.
      - name: Scan for Critical Vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ steps.build.outputs.IMAGE_TAG }}
          format: 'table'
          exit-code: '1' # Fail the build
          severity: 'CRITICAL'
          ignore-unfixed: true

      # Second, scan for HIGH vulnerabilities but do NOT fail the build.
      # The output will still appear in the logs as a warning.
      - name: Scan for High Vulnerabilities (Warning only)
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ steps.build.outputs.IMAGE_TAG }}
          format: 'table'
          exit-code: '0' # Do not fail the build
          severity: 'HIGH'
          ignore-unfixed: true

Beyond the Gate: SBOMs and Reporting

Failing a build is the primary function of a security gate, but modern scanners do more. A crucial artifact they can produce is a Software Bill of Materials (SBOM).

An SBOM is a detailed inventory of all components, libraries, and dependencies included in your software. After security incidents like the Log4j vulnerability, having an SBOM became critical for organizations to quickly identify if they were affected. Generating an SBOM should be a standard part of your build process.

Both Docker Scout and Trivy can generate SBOMs easily.

With Docker Scout:

docker scout sbom myapp:latest > sbom.json

With Trivy:

trivy image --format cyclonedx --output sbom.json myapp:latest

You can add this command as another step in your pipeline to generate the SBOM and then upload it as a build artifact for compliance and future analysis.

Conclusion

You have now learned how to fortify your CI/CD pipeline by embedding an automated security gate. This is a fundamental practice in DevSecOps that ensures a baseline of security for every image you produce.

Key Takeaways:

• Shift Left: By scanning for vulnerabilities before pushing an image, you catch security issues early, reducing risk and remediation costs.
• Security as Code: A security gate is defined directly in your CI/CD configuration (e.g., workflow.yaml), making your security policy version-controlled, transparent, and automated.
• Policy Enforcement via Exit Codes: The simple mechanism of using non-zero exit codes is the standard way for tools like Docker Scout and Trivy to signal failure and stop a pipeline.
• Remediation is Key: The most common way to fix vulnerabilities found in a Docker image is to update the base image or specific OS packages to patched versions. Using minimal, hardened base images (like Alpine, distroless, or those from Chainguard) is a proactive strategy to reduce the attack surface from the start.
• Generate SBOMs: Always generate a Software Bill of Materials (SBOM) as a build artifact for inventory, compliance, and future security analysis.

In this and previous lessons, we've been running Docker commands inside our CI/CD jobs. But how does the CI runner itself get access to a Docker environment to execute these commands? In our next lesson, we will explore this crucial implementation detail by addressing the learning outcome: Compare the trade-offs of Docker-in-Docker (DinD) vs. socket mounting for CI/CD builds. This topic has significant security and performance implications that every DevOps professional should understand.