DEV Community: Yaa Kesewaa Yeboah

How I Built, Scanned, and Automated a Docker Pipeline

Yaa Kesewaa Yeboah — Sat, 09 May 2026 15:12:52 +0000

I recently completed a hands-on Docker and DevSecOps lab as part of my learning track, and I wanted to write up the full walkthrough — including the parts where things broke, because that's honestly where the real learning happened.

By the end of this lab, I had:

Pulled and inspected a public container image from Docker Hub
Built a Python Flask web app and packaged it into a secure Docker image
Pushed it to Docker Hub and shared it
Automated the entire workflow with a GitHub Actions pipeline that includes Trivy vulnerability scanning as a hard security gate

This article walks you through each phase exactly as I did it, including the three issues I ran into and how I resolved them. If you're replicating this yourself, this should save you some time.

What You'll Need

Before you start, make sure you have:

Docker Desktop installed and running
A GitHub account
A Docker Hub account
A code editor (VS Code recommended)

You'll also need a Docker Hub Personal Access Token — not your password. Generate one at:
hub.docker.com → Avatar → Account Settings → Security → New Access Token

Give it Read & Write permissions and copy it straight away. You only see it once.

Phase 0 — Pull and Inspect a Public Container

The first phase is simple but important. Before building anything yourself, you act as a consumer — you pull a public image, run it, and observe what happens.

# Pull the lightweight Nginx image
docker pull nginx:alpine

# Run it in detached mode, mapping host port 8080 to container port 80
docker run -d -p 8080:80 --name my-nginx nginx:alpine

# Check it's running
docker ps

# View the logs
docker logs my-nginx

# Clean up
docker rm -f my-nginx

Open http://localhost:8080 in your browser and you'll see the Nginx welcome page.

What just happened? You downloaded a pre-built filesystem (the image) from Docker Hub, and Docker spun up an isolated process (the container) from it. The -p 8080:80 flag mapped port 80 inside the container to port 8080 on your machine, making it reachable from your browser.

This pull-and-run flow is the foundation of everything else in the lab.

Pulling the nginx:alpine image from Docker Hub in the terminal

Phase 1 — Build, Push, Pull & Share Your Own Image

Now you become the image creator. This phase has you build a Python Flask web application, write a Dockerfile, push the image to Docker Hub, and share it.

The Project Structure

your-project/
├── app.py
├── templates/
│   └── index.html
├── requirements.txt
├── Dockerfile
└── .dockerignore

Project folder structure in VS Code showing all the required files

The Application

app.py — A minimal Flask app with a home page and a /health endpoint.

from flask import Flask, render_template, jsonify
import os, datetime

app = Flask(__name__)
APP_NODE = os.environ.get("APP_NODE", "developer")

@app.route("/")
def home():
    return render_template("index.html", node=APP_NODE)

@app.route("/health")
def health():
    return jsonify({
        "status": "healthy",
        "node": APP_NODE,
        "time": datetime.datetime.utcnow().isoformat() + "Z"
    })

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

The APP_NODE variable is read from the environment. This externalises configuration from code — you can inject any identifier at runtime without rebuilding the image.

templates/index.html

<!DOCTYPE html>
<html>
<head><title>Welcome</title></head>
<body style="font-family: sans-serif; text-align: center; padding-top: 5rem;">
    <h1>Hello from <span style="color: #2b6cb0;">{{ node }}</span></h1>
    <p>This container is alive and running!</p>
</body>
</html>

requirements.txt

flask==3.0.0

Pinning the version ensures reproducible builds.

The Dockerfile

FROM python:3.11-slim

LABEL maintainer="your-name@example.com"
LABEL version="1.0.0"
LABEL description="Simple Flask web app for Docker/GitHub Actions lab"

# Create a non-root user — running as root in a container is a security risk
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# Copy requirements first to leverage Docker layer caching
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

RUN chown -R appuser:appuser /app
USER appuser

EXPOSE 5000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
    CMD curl -f http://localhost:5000/health || exit 1

CMD ["python", "app.py"]

Two things worth calling out here:

Non-root user: If the application is ever compromised, an attacker running as a non-root user has far less access than one running as root. It's a foundational security hardening step.

Layer caching order: Copying requirements.txt before the rest of the application code means Docker's build cache is preserved for the pip install layer as long as dependencies haven't changed. If you only modified app.py, Docker doesn't reinstall packages — it reuses the cached layer. This significantly speeds up builds, especially in CI pipelines.

.dockerignore

__pycache__
*.pyc
*.pyo
.git
.env
*.md
Dockerfile
.dockerignore

Without .dockerignore, your entire .git directory and any local .env files would be copied into the image — inflating its size and potentially exposing secrets.

Build and Test

docker build -t my-web-app .
docker run -d -p 5000:5000 --name webapp-test my-web-app

Visit http://localhost:5000 for the home page and http://localhost:5000/health for the health check.

docker build output showing all layers building successfully

Flask app home page loading at localhost:5000

The /health endpoint returning a JSON response in the browser

Push to Docker Hub

docker login -u your-dockerhub-username
docker tag my-web-app your-dockerhub-username/my-web-app:v1.0.0-yourname
docker push your-dockerhub-username/my-web-app:v1.0.0-yourname

The tag format <version>-<yourname> makes your image personally traceable — useful when you're sharing a registry with other learners.

Pushing the tagged image to Docker Hub in the terminal

Docker Hub showing the repository set to public

Pull Your Own Image

To simulate being a new user, delete your local copy and pull it from Docker Hub:

docker rmi your-dockerhub-username/my-web-app:v1.0.0-yourname
docker pull your-dockerhub-username/my-web-app:v1.0.0-yourname
docker run -d -p 5000:5000 --name pulled-app your-dockerhub-username/my-web-app:v1.0.0-yourname

* Pulling the image back from Docker Hub after deleting the local copy*

Running a container from the freshly pulled image

![Testing the pulled image]](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4wwzlfwsj8ejpvb3i632.png) Home page working correctly from the pulled image

Health endpoint responding correctly from the pulled image

The image should behave identically to your local build — which is the point. Portability is a core Docker guarantee.

Phase 2 — Automate with a GitHub Actions DevSecOps Pipeline

This is where it gets interesting. Phase 2 takes everything manual from Phase 1 and automates it in a CI/CD pipeline that runs on every push to main.

The pipeline:

Builds the Docker image
Scans it for vulnerabilities with Trivy
Only pushes to Docker Hub if the scan passes
Runs a smoke test to verify the pushed image works

Set Up GitHub Secrets

Go to your repo → Settings → Secrets and variables → Actions → New repository secret

Add two secrets:

DOCKERHUB_USERNAME — your Docker Hub username
DOCKERHUB_TOKEN — your access token

These must be two separate secrets. More on why this matters in the issues section below.

The Workflow File

Create .github/workflows/docker-build-push.yml:

name: Build, Scan, Push and Verify Docker Image

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

env:
  DOCKER_HUB_USER: ${{ secrets.DOCKERHUB_USERNAME }}
  IMAGE_NAME: my-web-app
  TAG_SUFFIX: yourname

jobs:
  build-scan-push-verify:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build Docker image (load locally, do not push yet)
        uses: docker/build-push-action@v5
        with:
          context: .
          load: true
          push: false
          tags: |
            ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:v1.0.0-${{ env.TAG_SUFFIX }}
            ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:latest

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@v0.20.0
        with:
          image-ref: "${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:v1.0.0-${{ env.TAG_SUFFIX }}"
          format: 'table'
          exit-code: '1'
          ignore-unfixed: true
          severity: 'HIGH,CRITICAL'

      - name: Push Docker image to Hub
        if: success()
        run: |
          docker push ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:v1.0.0-${{ env.TAG_SUFFIX }}
          docker push ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:latest

      - name: Pull image and run smoke tests
        if: success()
        run: |
          docker pull ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:v1.0.0-${{ env.TAG_SUFFIX }}
          docker run -d -p 5000:5000 --name verify-container \
            ${{ env.DOCKER_HUB_USER }}/${{ env.IMAGE_NAME }}:v1.0.0-${{ env.TAG_SUFFIX }}
          sleep 5
          curl -f http://localhost:5000/health || (echo "Health check failed!" && exit 1)
          curl -s http://localhost:5000/ | grep -i "hello" || (echo "Home page missing greeting!" && exit 1)
          echo "All smoke tests passed."

      - name: Remove test container
        if: always()
        run: docker rm -f verify-container || true

Two conditional flags worth understanding:

if: success() on the push step — this ensures we never push an image that hasn't passed all previous steps, especially the vulnerability scan.
if: always() on the cleanup step — this guarantees the test container is removed even if earlier steps failed, preventing orphaned processes on the runner.

Push and Trigger

git add .github/workflows/docker-build-push.yml
git commit -m "Add DevSecOps CI pipeline"
git push

Then go to the Actions tab in your repo and watch it run.

The Issues I Ran Into

This is the section I actually want people to read. The happy path above is clean, but this is what happened in practice.

Issue 1 — Docker Hub Credentials Not Set Up as Separate Secrets

The first pipeline run failed at login. The runner couldn't authenticate with Docker Hub.

The problem was that I hadn't properly separated the credentials into two distinct GitHub secrets. The docker/login-action needs username and password as completely separate values:

username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}

Once I added them as two separate secrets — DOCKERHUB_USERNAME and DOCKERHUB_TOKEN — the login step worked.

Key takeaway: Never combine credentials into a single secret, and never use your Docker Hub password here — use the Personal Access Token.

Issue 2 — Trivy Action Version Tag Missing the `v` Prefix

The pipeline got past login and build, then failed at the Trivy step with an "Unable to resolve action" error.

The cause was a missing v in the action version tag:

# Broken
uses: aquasecurity/trivy-action@0.20.0

# Correct
uses: aquasecurity/trivy-action@v0.20.0

GitHub Actions resolves action versions against the actual Git tags in the action's repository. The official release tag is v0.20.0 — without the v, it can't find it.

Key takeaway: Always check the official action repository for the exact tag format. Most actions use v prefixes — a missing v is an easy mistake and produces an unhelpful error message.

Issue 3 — Trivy Flagging HIGH and CRITICAL Vulnerabilities, Blocking the Push

With the version tag corrected, Trivy finally ran — and immediately failed the pipeline. It found HIGH and CRITICAL severity vulnerabilities in transitive dependencies (wheel and jaraco.context) coming from the python:3.11-slim base image.

Trivy scan output listing HIGH and CRITICAL vulnerabilities that blocked the push

This was the pipeline working exactly as intended. The exit-code: '1' setting means any HIGH or CRITICAL finding blocks the push — that's the security gate in action.

The question was how to fix it. The wrong approach would have been to add patching packages directly to requirements.txt — those are transitive dependencies that the application itself doesn't actually use, and bloating the requirements file with them is bad practice.

The correct approach was a base image upgrade. By moving to a more recent patch version of python:3.11-slim, the image inherits upstream security fixes that the Python Docker team had already applied. The vulnerabilities were resolved without touching the application's dependencies at all.

Final successful end-to-end pipeline run with all steps passing

Key takeaway: When Trivy flags base image vulnerabilities, upgrade the base image — don't suppress the finding or patch transitive dependencies directly. Keeping base images current is a core DevSecOps practice, and this is exactly the kind of thing an automated pipeline should surface and enforce.

What This Lab Actually Teaches

Looking back, the manual steps in Phase 1 exist to give you a clear mental model before Phase 2 automates all of it. By the time you write the workflow file, you understand exactly what each step is doing because you've done it yourself.

The pipeline is also a good introduction to what a real supply chain security gate looks like:

The image is built but not pushed
It's scanned before any push happens
A vulnerable image is blocked, not just warned about
The push only happens if everything passes

That ordering matters. It's the difference between security as an afterthought and security baked into the delivery process.

Clean Up

docker rm -f $(docker ps -aq) 2>/dev/null
docker rmi my-web-app your-dockerhub-username/my-web-app:v1.0.0-yourname nginx:alpine 2>/dev/null

Resources

If you're working through a similar lab and hit any of the same issues, I hope this saved you some debugging time. Feel free to drop a comment if anything needs more explanation.

10 Linux Security Incidents, Reproduced and Fixed

Yaa Kesewaa Yeboah — Sun, 01 Mar 2026 21:31:44 +0000

There's a difference between reading about Linux security and actually breaking things on purpose. This assignment made me do the latter; 10 real-world incidents, reproduced and fixed one by one.

I'll keep this post high-level. If you want the full commands, screenshots, and detailed documentation, it's all on my GitHub: github.com/Yaa-K/devsecops-linux-assignment

Scenario 1 — Shared Document Deletion Incident

An intern deleted a shared design document. I reproduced it by creating three users, a shared group, and a group-writable directory. As expected, any group member could delete any file inside — regardless of who created it.

The fix was chattr +i, which makes a file immutable at the filesystem level. Even root cannot delete it without explicitly removing the attribute first. This is the key difference between chmod and chattr — one enforces permissions, the other enforces filesystem-level constraints that sit below permissions entirely.

Scenario 2 — Log Overwrite Incident

One accidental > instead of >> destroyed over 100 lines of application logs instantly.

I restored the logs, backed them up using cp -p to preserve timestamps, and applied chattr +a (append-only) so no user — regardless of permissions — could overwrite the file again.

cp -p matters here because timestamps are forensic evidence. Without them, a backup file loses its evidentiary value — you can no longer tell when events actually occurred.

Scenario 3 — Permission & Ownership Drift

Copying files without the -p flag silently resets ownership and timestamps. A file that was dev_user:project_team 600 becomes your user's file after a plain cp. In production that kind of drift can expose secrets without anyone noticing.

The fix: always use cp -p for anything going to production.

Scenario 4 — Relative Path Deployment Failure

A deployment script used a relative path. It worked perfectly from the project directory and broke immediately when called from anywhere else — which is exactly what CI/CD systems do.

Switching to an absolute path fixed it completely. Relative paths are environment-dependent. Absolute paths are not.

Scenario 5 — Monitoring Failure After Log Cleanup

Removing a log file broke a symlink-based monitoring agent. A hard link to the same file survived without any issues.

A symlink is just a pointer to a path — remove the original and the symlink has nothing to point to. A hard link shares the same inode, so the data lives on as long as the link exists. For monitoring tools that need to survive log rotation, hard links are the safer choice.

Scenario 6 — Sensitive Data Exposure Hunt

Scanned an entire directory tree for exposed credentials using grep -r, multiple expressions with -e, and a pattern file with -f. Found passwords, API keys, and tokens sitting in plaintext in both config and log files.

Finding credentials in plaintext means immediate rotation. No exceptions.

Scenario 7 — Shared Directory Stability Controls

Developers were losing files because teammates were accidentally deleting each other's work. The fix was a single command — applying the sticky bit with chmod +t.

The sticky bit means only the file owner or root can delete a file, even if everyone in the group has write access. It's the same mechanism that keeps /tmp working safely on every Linux system.

Scenario 8 — Special Permission Risk Review

This one covered three special bits — sticky, setgid, and setuid — across a nested production-like directory path.

SetGID ensures new files inherit the directory's group automatically, so the whole team always has access without needing manual chgrp after every file creation.

For setuid, the difference between lowercase s and uppercase S is worth knowing. Lowercase means it's active. Uppercase means setuid was set without an execute bit — completely meaningless and always a misconfiguration.

Scenario 9 — Process Anomaly Investigation

A rogue infinite loop process was consuming 100% CPU. I identified it with ps and top, suspended it with kill -STOP, resumed it with kill -CONT, and terminated it gracefully with kill -15.

Always try kill -15 (SIGTERM) first. It lets the process clean up properly. kill -9 forces it dead with no cleanup — in production that can mean corrupted data or stuck locks.

Scenario 10 — Incident Documentation via Heredoc

Generated a structured incident report for all 10 scenarios using a heredoc directly in the terminal — no text editor needed.

What I Took Away

A few things that genuinely stuck with me:

chattr is underused. For files that should never be touched, it's a stronger guarantee than chmod — it sits below the permission layer entirely.

> vs >> matters more than people realise. In log management this is the difference between preserving forensic history and destroying it. Default to >>.

Uppercase S on a file is always a misconfiguration. Don't ignore it.

Absolute paths in scripts are not optional in production. They work from anywhere. Relative paths don't.

Hard links and symlinks are not interchangeable. Symlinks are convenient but fragile. Know when to use each.

This assignment was genuinely useful. These are not contrived scenarios — they reflect real incidents. If you want to dig into the full commands and evidence for each one, everything is documented on my GitHub: github.com/Yaa-K/parocyber-linux-assignment

Completed as part of the ParoCyber Linux Assignment, facilitated by Samuel Nartey Otuafo at ParoCyber LLC.

I Thought I Knew Linux. This Lab Proved Me Wrong.

Yaa Kesewaa Yeboah — Fri, 20 Feb 2026 21:57:19 +0000

I've been using Linux for a while. Commands like useradd, chmod, grep — I knew them. I could navigate the terminal without panicking. So when I started my first assignment in the ParoCyber DevSecOps Bootcamp, I figured it would be straightforward.

It wasn't. And I mean that in the best way possible.

What the Assignment Was About

The lab had two scenarios. The first was a password state investigation — find users on a system with no passwords set, understand where Linux stores that information, and remediate it. The second was a full onboarding simulation: create users, assign them to department groups, configure a CI/CD service account, manage sudo access, and safely offboard a user.

On paper, it sounds like basic sysadmin work. In practice, it forced me to think like a security engineer — and that changed everything.

The Moment That Reframed Everything

In Scenario 1, the task said: "You are not told where Linux stores password state. Finding it is part of the task."

I knew about /etc/passwd. Everyone who has touched Linux knows /etc/passwd. But when I ran cat /etc/passwd, the password field just showed x. A placeholder. I had seen that a hundred times and never thought twice about it.

That x means the actual password data lives somewhere else — /etc/shadow. And when I inspected it, I saw something that stopped me:

audit_test:!:...

That ! in the second field. One character. That single character is the difference between a secured account and a vulnerability sitting open on your system. I had been using Linux without ever knowing that file existed, let alone what it meant.

Then I tested whether a normal user could read /etc/shadow:

cat /etc/shadow
# Permission denied

And that's when it clicked. The fact that /etc/passwd is world-readable but /etc/shadow is root-only isn't an accident — it's a deliberate security design. Two files, one visible to everyone, one locked down. I had been looking at half the picture this whole time.

Scenario 2: Access Control Is a People Problem Too

The second scenario was about onboarding eight new staff members across four departments — dev, security, QA, and ops. Each team gets its own group. Each group gets access to what it needs and nothing more.

What struck me here wasn't the commands. It was the reasoning behind them.

When I created the ci_runner service account with a non-login shell:

sudo useradd -r -s /usr/sbin/nologin ci_runner

The trainer's question wasn't "did you run the command" — it was "do you know why this matters?" A service account with an interactive shell is an open door. Automated pipelines don't need to log in. Humans shouldn't be logging in as them either. That shell setting is a security decision, not a configuration detail.

Same with removing a user at the end. I used:

sudo userdel yaa

Not userdel -r. The -r flag would have deleted the home directory too. But in a real environment, that directory might contain evidence — scripts, logs, files that matter in an investigation. Deleting it immediately could mean destroying forensic data. That's not a Linux lesson. That's a security operations lesson.

What I'm Taking Away

I came into this thinking DevSecOps was Linux plus some security tools on top. What I'm leaving with is a different understanding — security isn't a layer you add. It's a lens you apply to every decision, including the ones that look purely technical.

The commands I ran in this lab weren't new. The questions behind them were.

Why does this file have these permissions? Why does this account need this shell? What happens to this data when this user is gone? Those questions are what separate someone who uses Linux from someone who secures it.

This is assignment one. I'm already thinking differently. Looking forward to what's next.