Hands-On Lab: Automated Docker Security Checks on Every PR

Sign up for Continue, connect this sample repo, and watch two checks catch real container security issues on your PRs.

What You'll Build

Two Continue checks that run as GitHub status checks on every PR:

1. Dockerfile Review (.continue/checks/dockerfile-review.md): Catches :latest tags, missing USER directives, hardcoded secrets in ARG/ENV, ADD instead of COPY, and missing HEALTHCHECK. Each rule maps to a Docker Scout policy.

2. Compose Review (.continue/checks/compose-review.md): Catches :latest tags in images, missing health checks, missing resource limits, privileged: true, and secrets in environment: instead of secrets:.

Both checks are already in this repo. You don't need to write them from scratch. The lab walks you through connecting the repo, opening test PRs, and watching the checks work.

What's in This Repo

A Python/Flask REST API with a production-ready Dockerfile and docker-compose.yml. The test branches contain intentionally problematic container configurations that the checks will catch.

├── src/
│   └── app.py                  # Flask app with /health endpoint
├── .continue/
│   └── checks/
│       ├── dockerfile-review.md    # Check 1: Dockerfile best practices
│       └── compose-review.md       # Check 2: Compose production readiness
├── Dockerfile                  # Production-ready multi-stage build
├── docker-compose.yml          # Production-ready compose config
├── requirements.txt            # Python dependencies
├── .dockerignore               # Build context exclusions
└── .env.example                # Environment variable template

Prerequisites

• GitHub account

Step 1: Sign Up for Continue

1. Go to continue.dev and sign up for Mission Control
2. Connect your GitHub account

Step 2: Fork and Connect the Repo

1. Fork this repo to your GitHub account
2. In Mission Control, connect the forked repo

Checkpoint: You should see the repo connected in Mission Control with two checks detected.

Step 3: Review the Checks

Open .continue/checks/ in your fork. Two checks are already defined:

• dockerfile-review.md enforces Docker Scout policies at PR time: Up-to-Date Base Images, Default Non-Root User, Approved Base Images, High-Profile Vulnerabilities, and Production Readiness.
• compose-review.md enforces production readiness: pinned image tags, health checks, resource limits, no privileged mode, and proper secrets management.

These are plain markdown files in your repo. Version-controlled, reviewable, editable. This is what standards-as-code looks like.

Step 4: Open Test PR #1, The Problematic Dockerfile

1. In your fork, open a PR from test/bad-dockerfile to main
2. Wait for checks to run
3. Expected: The Dockerfile Review check flags five issues:
   • FROM python:latest (Up-to-Date Base Images policy)
   • ARG DATABASE_PASSWORD=changeme (High-Profile Vulnerabilities policy)
   • ENV SECRET_KEY=hardcoded123 (High-Profile Vulnerabilities policy)
   • ADD . /app/ instead of COPY (Advisory patterns)
   • No USER directive (Default Non-Root User policy)
   • No HEALTHCHECK (Production readiness)
4. Review the suggested fixes and accept them
5. Checks go green

What you're seeing: The check caught six issues a human reviewer might or might not have noticed. You reviewed the suggestions and accepted them. This is the "building trust" phase.

Step 5: Open Test PR #2, The Problematic Compose File

1. Open a PR from test/bad-compose to main
2. Wait for checks
3. Expected:
   • Compose Review check fails: nginx:latest tag, privileged: true, secrets in environment: block, no health checks on any service, no resource limits
   • Dockerfile Review check also fails: The branch includes a problematic Dockerfile alongside the compose file
4. Accept the suggestions
5. Checks go green

What you're seeing: Two checks, two different kinds of catches, both running automatically. The Dockerfile check catches build-time issues. The Compose check catches runtime configuration issues.

Step 6: Open Test PR #3, The Green Check

1. Open a PR from test/clean-upgrade to main
2. Wait for checks
3. Expected: Both checks pass. Green checks. No action needed.

What you're seeing: This is what most of your PRs will look like once the checks are running. Green. Handled. You move on.

Step 7: Customize (Optional)

Open .continue/checks/dockerfile-review.md in your fork and add a rule. Ideas:

• Require multi-stage builds for production Dockerfiles
• Warn on non-slim/non-alpine base images
• Require LABEL instructions for image metadata
• Recommend Docker Hardened Images (docker/python instead of python)

Commit the change, open a test PR, and verify the check catches the new pattern.

What you're seeing: These checks are yours to customize. The rules you enforce are whatever matters to your team. Adding a rule is adding a paragraph to a markdown file.

How This Complements Docker Scout

These checks form a pre-build layer. Docker Scout forms the post-build layer:

	Continue Checks	Docker Scout
When	PR time (pre-build)	Post-build
What	Dockerfile syntax, compose config	Built image contents, CVEs
Catches	Policy violations in code	Vulnerabilities in packages

Issues caught at PR time never become images. Issues that slip through get caught by Scout before deployment.

Lab Complete

By the end of this lab you have:

• Two container security checks running on your repo as GitHub status checks
• Seen them handle three scenarios (two catches, one clean pass)
• Optionally customized one with a rule from your own codebase

From here, every PR on your repo gets checked automatically.

Next step: Add .continue/checks/ to your real repo and write checks for the patterns your team actually cares about.