Compliance checks don’t need to be a speed bump in your DevOps pipeline; they can actually be the accelerator.
Let’s see it in action. Imagine a simple Dockerfile that needs to adhere to a specific base image version and disallow root access. We can bake these checks right into our build process.
# This is a valid Dockerfile for our example
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y --no-install-recommends some-package \
&& rm -rf /var/lib/apt/lists/*
# Ensure no sensitive data is copied directly
COPY secrets.txt /app/secrets.txt
USER nobody
WORKDIR /app
CMD ["./run.sh"]
Now, how do we automate the checks? We’ll use a tool like Hadolint for Dockerfile linting and Trivy for vulnerability scanning and configuration checks.
Here’s a snippet of a GitLab CI/CD pipeline (.gitlab-ci.yml) that incorporates these checks:
stages:
- build
- test
- deploy
variables:
IMAGE_NAME: my-app
IMAGE_TAG: latest
build_image:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker build -t $IMAGE_NAME:$IMAGE_TAG .
- docker save $IMAGE_NAME:$IMAGE_TAG > image.tar
artifacts:
paths:
- image.tar
check_dockerfile:
stage: test
image: hadolint/hadolint:latest-debian
script:
- hadolint Dockerfile
scan_image:
stage: test
image: aquasec/trivy:latest
script:
- trivy image --severity HIGH,CRITICAL --exit-code 1 $IMAGE_NAME:$IMAGE_TAG
needs: ["build_image"]
deploy_app:
stage: deploy
script:
- echo "Deploying $IMAGE_NAME:$IMAGE_TAG..."
only:
- main
needs: ["scan_image"]
This pipeline defines three stages: build, test, and deploy. The build_image job uses Docker-in-Docker to build our image and saves it as an artifact. The check_dockerfile job runs Hadolint directly against the Dockerfile. If Hadolint finds any rule violations, the pipeline will fail. For instance, if we had USER root instead of USER nobody, Hadolint would flag it.
The scan_image job then takes over, using Trivy to scan the built Docker image. We’re specifically telling Trivy to fail the build (--exit-code 1) if it finds any vulnerabilities with HIGH or CRITICAL severity. Trivy also checks for misconfigurations, like exposed secrets or running as root.
The deploy_app stage is conditional, only running on the main branch and only if the preceding scan_image job succeeds. This ensures that only compliant and secure images proceed to deployment.
The core problem this solves is the "security is slow" fallacy. By integrating automated checks directly into the CI/CD pipeline, we shift compliance from a manual, post-development gate to a continuous, developer-driven process. This isn’t about adding overhead; it’s about building quality and security in. The system works by leveraging specialized static analysis tools that understand the nuances of container images and configuration files. They act as automated auditors, providing immediate feedback.
The mental model you want to build is one of "shift-left" for security and compliance. Instead of a separate team reviewing everything at the end, developers get instant feedback on their code and configurations. This drastically reduces the cost of fixing issues because they are caught early. Think of Hadolint as enforcing best practices for how you build your container image (e.g., avoiding unnecessary layers, cleaning up apt caches), while Trivy is looking for what’s inside the image (vulnerabilities in packages, misconfigurations).
A detail most people miss is how these tools can be configured to match organizational policies precisely. For example, Trivy can be pointed to specific vulnerability databases or custom policies defined in OPA (Open Policy Agent) format. You aren’t just accepting generic "critical" findings; you can define what "critical" means for your organization. You can tailor rulesets for Hadolint to enforce specific image layering strategies or command usage. This makes the compliance truly yours, not just a generic checkbox.
The next step is understanding how to integrate infrastructure-as-code compliance checks using tools like Terrascan or Checkov.