Advanced

Local Lab Only

The examples intentionally expose risky CI/CD patterns such as seeded credentials, privileged runners, and Docker socket access. Keep these services on a local Docker network, bind admin consoles to localhost, and remove all volumes after practice.

Lab Runbook

Use this page as a controlled lab build, not a production hardening guide. Validate isolation before running exercises and write down the cleanup command before starting.

High risk Advanced 1-3 hr

Plan

8-16 GB; 50 GB+. Free locally. Isolation: Local Docker network; never bind admin consoles to public interfaces.

Build

- CI server
- Runner
- Seed project

Validate

- Runner accepts jobs
- Registry authentication works
- Secret scanner catches seeded test secrets

Exercise

Run only the exercises tied to this lab and save screenshots, command output, logs, and timestamps outside disposable VMs.

Clean Up

- docker compose down -v
- Delete seeded credentials
- Rotate runner tokens

CI/CD Pipeline Lab Setup

Deploy vulnerable CI/CD pipelines locally using GitLab CE, Jenkins, and Gitea to practice pipeline poisoning, credential theft, secret extraction, and supply chain attacks in a safe environment.

Why CI/CD Labs?

CI/CD pipelines are increasingly targeted in real-world attacks. Codecov, SolarWinds, and 3CX all involved supply chain compromises. Understanding pipeline security is essential for modern red team operations.

Lab Architecture

CI/CD Lab Docker Network

localhost-bound consoles

GitLab CE

Repos, CI/CD, registry. Web UI on localhost:8929.

Jenkins

Pipelines, Groovy, plugins. Web UI on localhost:8080.

Gitea + Woodpecker

Lightweight Git and container-native YAML pipelines.

Shared Build Agent Risk

Any runner with Docker socket or privileged build access should be treated as host-root equivalent until the lab is destroyed.

Option 1: GitLab CE (Recommended)

GitLab CE includes built-in CI/CD, container registry, and code review — making it the most realistic self-hosted lab environment.

bash

# Create docker-compose.yml for GitLab
cat > docker-compose.yml << 'EOF'
services:
  gitlab:
    image: gitlab/gitlab-ce:17.11.1-ce.0  # Verify current supported tag before reuse
    container_name: gitlab
    hostname: gitlab.lab.local
    ports:
      - "127.0.0.1:8929:80"        # Web UI
      - "127.0.0.1:2224:22"        # Git SSH
      - "127.0.0.1:5050:5050"      # Container Registry
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.lab.local:8929'
        # Lab-only bootstrap password. Change after first login and never reuse.
        gitlab_rails['initial_root_password'] = 'LAB_ONLY_ChangeMe_123!'
        registry_external_url 'http://gitlab.lab.local:5050'
    shm_size: '256m'

  gitlab-runner:
    image: gitlab/gitlab-runner:v17.11.0  # Keep runner and GitLab versions compatible
    container_name: gitlab-runner
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - runner_config:/etc/gitlab-runner
    depends_on:
      - gitlab

volumes:
  gitlab_config:
  gitlab_logs:
  gitlab_data:
  runner_config:
EOF

# The Docker socket mount above is intentionally dangerous and lab-only.
# Treat this runner as equivalent to host root until the lab is destroyed.

docker compose up -d
# Wait 2-3 minutes for GitLab to initialize
# Access at http://localhost:8929 — root / LAB_ONLY_ChangeMe_123!
# Create docker-compose.yml for GitLab
cat > docker-compose.yml << 'EOF'
services:
  gitlab:
    image: gitlab/gitlab-ce:17.11.1-ce.0  # Verify current supported tag before reuse
    container_name: gitlab
    hostname: gitlab.lab.local
    ports:
      - "127.0.0.1:8929:80"        # Web UI
      - "127.0.0.1:2224:22"        # Git SSH
      - "127.0.0.1:5050:5050"      # Container Registry
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.lab.local:8929'
        # Lab-only bootstrap password. Change after first login and never reuse.
        gitlab_rails['initial_root_password'] = 'LAB_ONLY_ChangeMe_123!'
        registry_external_url 'http://gitlab.lab.local:5050'
    shm_size: '256m'

  gitlab-runner:
    image: gitlab/gitlab-runner:v17.11.0  # Keep runner and GitLab versions compatible
    container_name: gitlab-runner
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - runner_config:/etc/gitlab-runner
    depends_on:
      - gitlab

volumes:
  gitlab_config:
  gitlab_logs:
  gitlab_data:
  runner_config:
EOF

# The Docker socket mount above is intentionally dangerous and lab-only.
# Treat this runner as equivalent to host root until the lab is destroyed.

docker compose up -d
# Wait 2-3 minutes for GitLab to initialize
# Access at http://localhost:8929 — root / LAB_ONLY_ChangeMe_123!

Register GitLab Runner

bash

# Get registration token from GitLab:
# Admin Area > CI/CD > Runners > Register runner

# Register the runner
docker exec -it gitlab-runner gitlab-runner register \
  --non-interactive \
  --url "http://gitlab:80" \
  --token "YOUR_REGISTRATION_TOKEN" \
  --executor "docker" \
  --docker-image "alpine:3.21" \
  --description "lab-runner" \
  --docker-privileged  # Needed for Docker-in-Docker builds
# Get registration token from GitLab:
# Admin Area > CI/CD > Runners > Register runner

# Register the runner
docker exec -it gitlab-runner gitlab-runner register \
  --non-interactive \
  --url "http://gitlab:80" \
  --token "YOUR_REGISTRATION_TOKEN" \
  --executor "docker" \
  --docker-image "alpine:3.21" \
  --description "lab-runner" \
  --docker-privileged  # Needed for Docker-in-Docker builds

Vulnerable Pipeline Configuration

yaml

# This pipeline has multiple security issues for practice
stages:
  - build
  - test
  - deploy

variables:
  # BAD: Hardcoded secrets in pipeline variables
  AWS_ACCESS_KEY_ID: "AKIAIOSFODNN7EXAMPLE"
  AWS_SECRET_ACCESS_KEY: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  DB_PASSWORD: "LAB_ONLY_seeded_secret_123"

build:
  stage: build
  image: docker:27-cli
  services:
    - docker:dind
  script:
    # BAD: Using untrusted base image
    - docker build -t myapp:lab .
    # BAD: Pushing to registry without scanning
    - docker push registry.lab.local:5050/myapp:lab

test:
  stage: test
  script:
    # BAD: Executing arbitrary code from dependencies
    - npm install  # No lockfile verification
    - npm test
    # BAD: Printing environment (may leak secrets)
    - printenv

deploy:
  stage: deploy
  script:
    # BAD: SSH key in pipeline
    - echo "$SSH_PRIVATE_KEY" > /tmp/deploy_key
    - chmod 600 /tmp/deploy_key
    - ssh -i /tmp/deploy_key root@lab-deploy-target "docker pull && docker restart app"
  environment:
    name: production
# This pipeline has multiple security issues for practice
stages:
  - build
  - test
  - deploy

variables:
  # BAD: Hardcoded secrets in pipeline variables
  AWS_ACCESS_KEY_ID: "AKIAIOSFODNN7EXAMPLE"
  AWS_SECRET_ACCESS_KEY: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  DB_PASSWORD: "LAB_ONLY_seeded_secret_123"

build:
  stage: build
  image: docker:27-cli
  services:
    - docker:dind
  script:
    # BAD: Using untrusted base image
    - docker build -t myapp:lab .
    # BAD: Pushing to registry without scanning
    - docker push registry.lab.local:5050/myapp:lab

test:
  stage: test
  script:
    # BAD: Executing arbitrary code from dependencies
    - npm install  # No lockfile verification
    - npm test
    # BAD: Printing environment (may leak secrets)
    - printenv

deploy:
  stage: deploy
  script:
    # BAD: SSH key in pipeline
    - echo "$SSH_PRIVATE_KEY" > /tmp/deploy_key
    - chmod 600 /tmp/deploy_key
    - ssh -i /tmp/deploy_key root@lab-deploy-target "docker pull && docker restart app"
  environment:
    name: production

Option 2: Jenkins

bash

# Run Jenkins with Docker socket access
docker run -d \
  --name jenkins \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkins/jenkins:lts-jdk17

# Get initial admin password
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

# Access at http://localhost:8080
# Install suggested plugins during setup
# Run Jenkins with Docker socket access
docker run -d \
  --name jenkins \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkins/jenkins:lts-jdk17

# Get initial admin password
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

# Access at http://localhost:8080
# Install suggested plugins during setup

Vulnerable Jenkinsfile

groovy

pipeline {
    agent any

    // BAD: Credentials in environment block
    environment {
        DB_CREDS = 'admin:SuperSecret123'
        API_KEY  = 'sk-live-abc123def456'
    }

    stages {
        stage('Build') {
            steps {
                // BAD: Arbitrary Groovy execution enabled
                script {
                    def output = sh(script: 'whoami && id', returnStdout: true)
                    echo "Running as: ${output}"
                }
                sh 'docker build -t app:lab .'
            }
        }

        stage('Test') {
            steps {
                // BAD: No dependency verification
                sh 'pip install -r requirements.txt'
                sh 'python -m pytest'

                // BAD: Dumping credentials for debugging
                sh 'echo $DB_CREDS'
            }
        }

        stage('Deploy') {
            steps {
                // BAD: Remote code execution via SSH with embedded key
                sh """
                    sshpass -p 'root123' ssh root@production \
                    'cd /opt/app && git pull && docker compose up -d'
                """
            }
        }
    }
}
pipeline {
    agent any

    // BAD: Credentials in environment block
    environment {
        DB_CREDS = 'admin:SuperSecret123'
        API_KEY  = 'sk-live-abc123def456'
    }

    stages {
        stage('Build') {
            steps {
                // BAD: Arbitrary Groovy execution enabled
                script {
                    def output = sh(script: 'whoami && id', returnStdout: true)
                    echo "Running as: ${output}"
                }
                sh 'docker build -t app:lab .'
            }
        }

        stage('Test') {
            steps {
                // BAD: No dependency verification
                sh 'pip install -r requirements.txt'
                sh 'python -m pytest'

                // BAD: Dumping credentials for debugging
                sh 'echo $DB_CREDS'
            }
        }

        stage('Deploy') {
            steps {
                // BAD: Remote code execution via SSH with embedded key
                sh """
                    sshpass -p 'root123' ssh root@production \
                    'cd /opt/app && git pull && docker compose up -d'
                """
            }
        }
    }
}

Option 3: Gitea (Lightweight)

Gitea is a lightweight self-hosted Git service. Pair with Woodpecker CI (Drone fork) for a minimal pipeline lab that uses fewer resources.

bash

cat > docker-compose.yml << 'EOF'
services:
  gitea:
    image: gitea/gitea:1.23.7
    container_name: gitea
    ports:
      - "127.0.0.1:3000:3000"    # Web UI
      - "127.0.0.1:2222:22"      # Git SSH
    volumes:
      - gitea_data:/data
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__server__ROOT_URL=http://localhost:3000

  woodpecker:
    image: woodpeckerci/woodpecker-server:v3.2.0
    container_name: woodpecker
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - woodpecker_data:/var/lib/woodpecker
    environment:
      - WOODPECKER_OPEN=true
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=http://gitea:3000
      - WOODPECKER_GITEA_CLIENT=your-client-id
      - WOODPECKER_GITEA_SECRET=your-client-secret
      - WOODPECKER_HOST=http://localhost:8000
      - WOODPECKER_SECRET=woodpecker-secret-key

volumes:
  gitea_data:
  woodpecker_data:
EOF

docker compose up -d
# Access Gitea at http://localhost:3000
# Access Woodpecker CI at http://localhost:8000
cat > docker-compose.yml << 'EOF'
services:
  gitea:
    image: gitea/gitea:1.23.7
    container_name: gitea
    ports:
      - "127.0.0.1:3000:3000"    # Web UI
      - "127.0.0.1:2222:22"      # Git SSH
    volumes:
      - gitea_data:/data
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__server__ROOT_URL=http://localhost:3000

  woodpecker:
    image: woodpeckerci/woodpecker-server:v3.2.0
    container_name: woodpecker
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - woodpecker_data:/var/lib/woodpecker
    environment:
      - WOODPECKER_OPEN=true
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=http://gitea:3000
      - WOODPECKER_GITEA_CLIENT=your-client-id
      - WOODPECKER_GITEA_SECRET=your-client-secret
      - WOODPECKER_HOST=http://localhost:8000
      - WOODPECKER_SECRET=woodpecker-secret-key

volumes:
  gitea_data:
  woodpecker_data:
EOF

docker compose up -d
# Access Gitea at http://localhost:3000
# Access Woodpecker CI at http://localhost:8000

Vulnerable-by-Design CI/CD Labs

CI/CDGoat

Intentionally vulnerable CI/CD environment by Cider Security. Includes GitLab, Jenkins, and Gitea with 11 challenges covering pipeline poisoning, credential theft, and more.

bash

git clone https://github.com/cider-security-research/cicd-goat.git
cd cicd-goat
docker compose up -d
# Access at http://localhost:8080 (Jenkins)
# and http://localhost:3000 (Gitea)
git clone https://github.com/cider-security-research/cicd-goat.git
cd cicd-goat
docker compose up -d
# Access at http://localhost:8080 (Jenkins)
# and http://localhost:3000 (Gitea)

GitHub: cicd-goat →

Top 10 CI/CD Risks

OWASP Top 10 CI/CD Security Risks framework. Each risk maps to real attack techniques you can practice in this lab.

• CICD-SEC-1: Insufficient Flow Control
• CICD-SEC-3: Dependency Chain Abuse
• CICD-SEC-4: Poisoned Pipeline Execution
• CICD-SEC-6: Insufficient Credential Hygiene
• CICD-SEC-9: Improper Artifact Integrity

OWASP CI/CD Top 10 →

Practice Exercises

Exercise 1: Secret Extraction

Find and extract hardcoded secrets from pipeline configurations. Use tools like trufflehog and gitleaks to scan repositories.

Exercise 2: Pipeline Poisoning (PPE)

Modify a CI config file in a feature branch to inject commands. Fork a repo and submit a PR that runs malicious build steps.

Exercise 3: Jenkins Script Console RCE

Access the Jenkins Script Console (/script) and execute Groovy code to read files, spawn reverse shells, or access credentials.

Exercise 4: Container Escape from Runner

Exploit Docker socket access in a CI runner to escape the container and access the host system.

Exercise 5: Dependency Confusion

Set up a private registry and demonstrate dependency confusion by creating a public package with a higher version number.

Troubleshooting FAQ

GitLab taking too long to start

GitLab CE needs 4-8GB RAM and takes 2-5 minutes to fully initialize
Check progress: docker logs -f gitlab
Increase Docker memory limit in Docker Desktop settings
Use Gitea instead if resources are limited — it starts in seconds

GitLab runner not picking up jobs

Verify runner registration: check Admin > CI/CD > Runners in GitLab UI
Runner must be able to reach GitLab: docker exec gitlab-runner ping gitlab
Check runner logs: docker logs gitlab-runner
Ensure project has the runner assigned (Settings > CI/CD > Runners)

Jenkins plugins failing to install

Check internet connectivity from the container: docker exec jenkins curl -I https://updates.jenkins.io
Update Jenkins to latest LTS before installing plugins
Some plugins have Java version requirements — check compatibility
Try installing from the CLI: docker exec jenkins jenkins-plugin-cli --plugins plugin-name

Go Deeper After Setup

CI/CD Supply Chain Turn the lab into pipeline attack-path practice. Source Code Review Pair pipeline testing with code and dependency review.

Operational Safety Baseline

Apply these rules before running any lab command on this page.

Work only on systems you own or have explicit authorization to test.
Keep vulnerable services off your home LAN and off public interfaces.
Take clean snapshots before every exercise and before every vulnerable configuration change.
Use dedicated cloud accounts, subscriptions, and projects with billing alerts before deployment.
Write down the teardown command before you run the setup command.

Validation Checkpoints

-Runner accepts jobs
-Registry authentication works
-Secret scanner catches seeded test secrets
-No Docker socket access outside the lab

Cleanup And Rollback

-docker compose down -v
-Delete seeded credentials
-Rotate runner tokens
-Prune local images

Practice Next

CI/CD Supply Chain Source Code Review

Token And Volume Cleanup

Rotate or delete every lab token after each exercise, then remove disposable CI/CD state with docker compose down -v or equivalent volume cleanup. Do not keep vulnerable runner configs around for later reuse.

Lab Runbook

Plan

Build

Validate

Exercise

Clean Up

CI/CD Pipeline Lab Setup

Lab Architecture

CI/CD Lab Docker Network

GitLab CE

Jenkins

Gitea + Woodpecker

Shared Build Agent Risk

Option 1: GitLab CE (Recommended)

Register GitLab Runner

Vulnerable Pipeline Configuration

Option 2: Jenkins

Vulnerable Jenkinsfile

Option 3: Gitea (Lightweight)

Vulnerable-by-Design CI/CD Labs

CI/CDGoat

Top 10 CI/CD Risks

Practice Exercises

Exercise 1: Secret Extraction

Exercise 2: Pipeline Poisoning (PPE)

Exercise 3: Jenkins Script Console RCE

Exercise 4: Container Escape from Runner

Exercise 5: Dependency Confusion

Troubleshooting FAQ

Go Deeper After Setup

Operational Safety Baseline

Validation Checkpoints

Cleanup And Rollback

Practice Next

Related Topics

CI/CD Supply Chain Security

Container Security

Source Code Review

Cloud Lab