DEV Community: Yaa Kesewaa Yeboah

I Made My Docker Container Progressively More Secure

Yaa Kesewaa Yeboah — Sat, 16 May 2026 11:46:11 +0000

I recently completed a structured Docker security lab that walks through five progressively more secure versions of the same minimal Node.js application. Rather than just reading about Docker security best practices, I wanted to observe each vulnerability and its fix directly in the terminal.

This is what I found.

The Setup

The application is deliberately simple — a Node.js HTTP server that reports one thing: the user ID of the process running it. That single output makes security differences immediately visible.

const uid = process.getuid();
const username = uid === 0 ? 'root -- DANGER' : `non-root (uid: ${uid})`;

When uid is 0, the process is root. When it is anything else, it is a restricted user. Every scenario change shows up in that number.

I also created a .env file containing fake credentials:

DATABASE_PASSWORD=super_secret_password_123
API_KEY=sk-live-abc123xyz789
STRIPE_SECRET=rk_live_do_not_share_this

This simulates what exists in almost every real project. You will see exactly what happens to it.

Scenario 1 — The Insecure Default

The starting Dockerfile is what you might write if you are new to Docker and following a basic tutorial:

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["npm", "start"]

Layer Caching Is Real and Measurable

Before worrying about security, I observed something important about build performance. The first build took noticeably longer — every layer ran from scratch with no cache available.

shows the first cold build running each layer sequentially with real timing output

The second build, with nothing changed, was almost instant. Every layer showed CACHED. Docker had stored each layer separately and reused all of them.

shows all layers returning CACHED and the dramatically shorter build time

Then I added a single comment to app.js and rebuilt. The COPY . . layer was invalidated, and so was every layer above it — including RUN npm install. My dependencies reinstalled even though package.json had not changed at all.

shows exactly which layer lost the cache hit and every layer above it re-executing

This matters because the order of instructions in your Dockerfile directly controls how efficient your builds are. The correct pattern is:

# CORRECT — npm install only re-runs when package.json changes
COPY package.json ./
RUN npm install
COPY . .

# WRONG — any code change forces a full reinstall
COPY . .
RUN npm install

Running as Root

curl http://localhost:3000

App is running
User ID : 0
Running as : root -- DANGER

shows the terminal with uid 0 printed, confirming the process is running as root

shows the curl output with "root -- DANGER" in the response body

uid 0 is root. The application process and everything it can touch inside the container has unrestricted access.

The Secret Leak

This was the most striking observation. I opened a shell inside the running container:

docker exec -it $(docker ps -q) sh
cat /app/.env

DATABASE_PASSWORD=super_secret_password_123
API_KEY=sk-live-abc123xyz789
STRIPE_SECRET=rk_live_do_not_share_this

shows all three credentials printed inside the running container with no authentication required

COPY . . had silently copied the .env file into the image. Anyone who can pull that image from a registry can read those credentials. The container does not even need to be running — docker run --rm insecure-app cat /app/.env returns the same output.

Three problems, one basic Dockerfile:

Application runs as root
Credentials are baked into the image
Layer caching breaks on every code change

Scenario 2 — Running as a Non-Root User

One addition to the Dockerfile:

RUN groupadd -r appuser && useradd -r -g appuser appuser
COPY . .
RUN npm install
RUN chown -R appuser:appuser /app
USER appuser

The USER instruction switches the active user. Every subsequent instruction in the Dockerfile — and the process that starts when the container runs — uses this identity instead of root.

App is running
User ID : 999
Running as : non-root (uid: 999)

shows curl output with uid 999, confirming the app is no longer running as root

To make this concrete, I opened a shell inside the running container and tried several things as appuser:

echo "test" > /etc/passwd     # Permission denied
apt-get install curl          # Permission denied (lock file)
touch /bin/backdoor           # Permission denied

shows all three write attempts denied with "Permission denied" errors

An attacker who exploits the application now inherits appuser's restrictions — not root's unlimited access. This is called blast radius reduction. You cannot always prevent exploitation; you can ensure the damage is contained.

What this does not fix: appuser can still read files it has permission to access. The .env file is still inside the image. Running cat /app/.env inside the non-root container still works because appuser owns those files. The secrets problem needs a separate fix.

Scenario 3 — Protecting Secrets with .dockerignore

.dockerignore is a plain text file placed alongside your Dockerfile. It lists patterns that Docker excludes from the build context before any COPY instruction runs.

.env
.env.*
*.pem
*.key
*.cert
.git
node_modules
Dockerfile*
README.md

After rebuilding with this file in place:

docker run --rm secure-copy-app find /app -type f

/app/app.js
/app/package.json
/app/package-lock.json

shows find output listing only app.js, package.json, and package-lock.json with no .env present

The .env file is gone. I confirmed it:

docker run --rm secure-copy-app cat /app/.env
# cat: /app/.env: No such file or directory

shows the "No such file or directory" error when attempting to read .env

I then created a test.pem file in my project directory and rebuilt. The .pem pattern matched it automatically — no additional configuration needed.

shows test.pem absent from the find output after rebuild, proving the *.pem pattern worked

The critical thing to understand: .dockerignore runs before any COPY instruction executes. Files excluded this way are never sent to the Docker daemon at all. They cannot appear in any layer, not even temporarily. This is different from deleting a file inside the container — deletion still creates a layer, and forensic tools can recover data from earlier layers in the image history.

Scenario 4 — Multi-Stage Builds

After three scenarios, the image still contained compilers, npm, apt, curl, git, and hundreds of other programs the application does not need to serve HTTP traffic. A multi-stage build fixes this.

# Stage 1: builder — uses the full Node.js image
FROM node:20 AS builder
WORKDIR /build
COPY package.json ./
RUN npm install
COPY app.js .

# Stage 2: runtime — uses a minimal image
FROM node:20-slim
WORKDIR /app
RUN groupadd -r appuser && useradd -r -g appuser appuser
COPY --from=builder /build/app.js ./app.js
COPY --from=builder /build/node_modules ./node_modules
RUN chown -R appuser:appuser /app
USER appuser
EXPOSE 3000
CMD ["node", "app.js"]

COPY --from=builder transfers only what I explicitly listed. Everything else — npm, the package cache, compilers — is gone permanently.

The Size Difference

Image	Size
insecure-app	~1.10 GB
nonroot-app	~1.10 GB
multistage-app	~240 MB

shows docker images output with all three images listed side by side, making the 870 MB difference visible

Adding a non-root user does not change image size — it changes who runs the application. The multi-stage build removed roughly 870 MB, an 78% reduction.

Inside the multi-stage container, none of these existed:

npm --version    # sh: npm: not found
curl --version   # sh: curl: not found
git --version    # sh: git: not found
apt-get          # sh: apt-get: not found

shows each tool command returning "not found" inside the multi-stage container

An attacker who achieves code execution inside this container cannot use these tools to download malware, compile attack utilities, or interact with external systems. The tools are not there.

The 870 MB difference is not just storage. It is attack surface that no longer exists.

Scenario 5 — Runtime Hardening

The Dockerfile controls what is inside the image. Runtime flags control what a running container is permitted to do at the operating system level.

docker run \
  --read-only \
  --tmpfs /tmp \
  --memory="128m" \
  --cpus="0.5" \
  --cap-drop=ALL \
  --security-opt no-new-privileges:true \
  -p 3000:3000 \
  multistage-app

Read-Only Filesystem

docker exec -it $(docker ps -q) sh -c "echo test > /app/hacked.txt"
# sh: /app/hacked.txt: Read-only file system

shows the kernel-level "Read-only file system" error rejecting the write attempt

The kernel rejected the write. An attacker cannot persist any file, install any tool, or modify any binary. --tmpfs /tmp provides a small in-memory scratch area if the application needs to write temporary files at runtime.

Resource Limits

docker inspect $(docker ps -q) | grep -E '"Memory"|"NanoCpus"'
# "Memory": 134217728,    (exactly 128 MB)
# "NanoCpus": 500000000,  (exactly 0.5 CPU cores)

shows the Memory and NanoCpus values returned by docker inspect confirming the limits are registered at the kernel level

These limits are enforced by the Linux kernel's cgroup subsystem — not by application code. A compromised container cannot exhaust host memory or CPU.

Linux Capabilities

Linux divides root privilege into roughly 40 distinct units called capabilities. By default, a container receives about 15 of them. --cap-drop=ALL removes every one. The application still served HTTP traffic correctly after dropping all capabilities — it needed none of them.

shows a capability-dependent command failing inside the container while curl http://localhost:3000 still succeeds, proving the app works without any capabilities

--security-opt no-new-privileges:true prevents any process inside the container from gaining more privileges than it started with, even if a setuid binary is present on the filesystem.

The Full Picture

Scenario	Change	Root?	Secrets in Image?	Build Tools?	Runtime Constraints
1 — Default	None	✅ Yes	✅ Yes	✅ Yes	None
2 — Non-Root	`USER appuser`	❌ No	✅ Yes	✅ Yes	None
3 — .dockerignore	Exclude secrets	❌ No	❌ No	✅ Yes	None
4 — Multi-Stage	Separate stages	❌ No	❌ No	❌ No	None
5 — Runtime	Kernel flags	❌ No	❌ No	❌ No	Read-only, capped, no capabilities

What Surprised Me Most

COPY . . is silent about what it includes. There is no warning when it bundles your .env file. No error. The build succeeds. The credentials are just there, readable by anyone with access to the image. A single .dockerignore file — two minutes to write — prevents this entirely.

Image size and security are directly related. I expected the multi-stage build to be a performance optimisation. I did not expect it to be a meaningful security improvement. But removing 870 MB of programs from an image is the same as removing 870 MB of potential attack tools.

The Dockerfile and the runtime flags protect different things. An attacker who bypasses the application layer still faces constraints from the operating system if the runtime flags are in place. Neither layer replaces the other.

If you are working through Docker security for the first time, run the insecure scenario first and look at the output of cat /app/.env inside the running container before adding .dockerignore. Seeing the credentials appear in the terminal makes the fix feel much more real than reading about it.

I Learned Docker by Running a 3-Container Quiz App

Yaa Kesewaa Yeboah — Sat, 16 May 2026 09:41:12 +0000

I'll be honest: I had read about Docker containers probably five times before anything clicked. The diagrams made sense in isolation, but I couldn't picture how a real application actually used any of it. What does a network between containers look like in practice? What does a volume actually do?

For one of our DevSecOps assignments, we were pointed to Samuel Nartey's DockerQuiz project — a Kahoot-style Docker quiz that is itself a fully containerized 3-container application. The premise was simple and smart: learn Docker by running Docker, not by reading about it.

This is my honest write-up of building it, breaking it, and what I actually learned along the way.

What the Project Is

DockerQuiz is a Flask web app that quizzes you on Docker concepts. But the real lesson isn't the quiz — it's the infrastructure underneath it.

When you run docker compose up, three containers spin up and connect over a private network:

quiz-app — the Flask application serving the quiz at localhost:5000
mongo — a MongoDB instance storing your profiles, scores, and session state
mongo-express — a web UI for browsing MongoDB live at localhost:8081

┌─────────────────────────────────────────────────────────────────┐
│                     quiz-network  (bridge)                      │
│                                                                 │
│   ┌──────────────┐      ┌───────────────┐    ┌──────────────┐  │
│   │   quiz-app   │─────▶│     mongo     │◀───│mongo-express │  │
│   │ Flask :5000  │      │ MongoDB :27017│    │ Web UI :8081 │  │
│   └──────────────┘      └───────────────┘    └──────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Three separate containers. One shared network. One command to start everything.

Getting It Running

Prerequisites: Just Docker Desktop

No Python, no MongoDB, no Node.js installation needed. Everything runs inside containers. That alone felt like a small revelation — my machine didn't need to know anything about Flask or MongoDB. Docker handled all of it.

After cloning the repo and navigating into the project folder, I ran:

docker compose up --build

The first run took a few minutes — Docker was pulling the official mongo:7.0 and mongo-express:1.0.2 images from Docker Hub. After that, every subsequent run took a matter of seconds.

Once the terminal showed quiz-app | * Running on http://0.0.0.0:5000, I opened two tabs:

http://localhost:5000 — the quiz
http://localhost:8081 — Mongo Express

Three containers starting up via docker compose up --build

Playing the Quiz and Watching the Data

I created a profile — name, avatar, role — and started answering questions. What made this different from just reading a tutorial was that I could open Mongo Express on the side and watch my own data appear in real time.

Every answer I submitted updated a document in the quiz_states collection. When I finished, a full result document landed in results. It wasn't abstract anymore — I could see the Flask container writing to the MongoDB container, and browse it through a third container, all on the same local machine.

The quiz interface at localhost:5000

Mongo Express showing the live database at localhost:8081

_My profile document appearing in the profiles collection
_

My completed quiz result in the results collection

The moment that landed hardest was seeing this line in app.py:

MONGO_URI = "mongodb://mongo:27017/"

mongo isn't localhost. It's the service name from docker-compose.yml — and Docker automatically resolves it to the right container's IP address. That's Docker's built-in DNS. Containers discover each other by name, not by hardcoded addresses. It's the pattern used in virtually every real production deployment, and seeing it in a small project made it finally make sense.

The Experiment That Showed Me What `depends_on` Actually Does

The README has a section called Experiment and Break Things. I tried two of them.

Experiment 1 — Changing the Port Mapping

The first one was clean and immediate. I changed this line in docker-compose.yml:

# Before
ports:
  - "5000:5000"

# After
ports:
  - "8000:5000"

The format is HOST_PORT:CONTAINER_PORT. The container still listens on port 5000 internally — nothing inside Docker changes. But now my machine maps its port 8000 to that container port. So localhost:5000 stopped working and localhost:8000 served the app instead.

The quiz app now accessible at port 8000

Confirming the app loads correctly at localhost:8000

It's a small change, but it made port mapping tangible. The container's internal world is completely separate from what I expose on my machine.

Experiment 2 — Commenting Out `depends_on`

This one surprised me — and the surprise turned out to be the most educational part.

I commented out the depends_on block in docker-compose.yml so that quiz-app would no longer wait for mongo to be ready before starting:

  quiz-app:
    build: .
    # depends_on:
    #   - mongo

I expected chaos. The quiz app starting before the database — surely that would crash everything?

Commented out depends_on

_Terminal output after commenting out depends_on _

It... worked. The app came up fine.

Here's what I learned: depends_on only controls start order, not readiness. It tells Docker to start the mongo container before quiz-app, but it does not wait for MongoDB to actually be accepting connections. In practice, MongoDB often starts fast enough that it doesn't matter.

But the deeper reason everything stayed stable is in the app itself. app.py has a retry loop — it attempts to connect to MongoDB up to 5 times with 2-second gaps between attempts. So even without depends_on, the app just quietly retried until the database was ready. The resilience was already built in.

The lesson wasn't "comments depends_on is safe to remove." It was: retry logic in your application is what actually handles race conditions, not start order alone. depends_on is a hint, not a guarantee. Real-world applications can't assume the services they depend on will be available the moment they start — and this project demonstrates exactly how to handle that.

Stopping and Cleaning Up

# Stop containers, keep your data
docker compose down

# Stop containers AND wipe the database
docker compose down -v

The -v flag removes the named volume (mongo-data), which is where MongoDB persists your data between restarts. Without it, your quiz results survive a docker compose down and come back when you start again. With it, you're starting completely fresh.

Running docker compose down to stop all containers

What I Actually Walked Away Understanding

Before this project, I could define Docker concepts. After it, I understood them:

Container networking — Containers on the same network talk to each other by service name. mongo resolves to the MongoDB container because Docker's internal DNS makes it so. No IP addresses, no host machine involvement.

Port mapping — The container's internal port and the host port are completely independent. "8000:5000" means "my machine's 8000 talks to the container's 5000." Changing the host side changes nothing inside the container.

Named volumes — mongo-data:/data/db means data written inside the container at /data/db is actually stored in a Docker-managed volume on the host. That's why your quiz results survive a restart.

depends_on vs. actual readiness — Start order is not the same as service readiness. Your application needs to handle the case where its dependencies aren't immediately available. Retry logic matters.

Why multiple containers — The separation between quiz-app, mongo, and mongo-express isn't over-engineering. It means you can update the Flask app without touching the database. You can scale the app without scaling the database. You can swap MongoDB for something else without rewriting application code. This is the architecture pattern that shows up in real production systems.

Try It Yourself

The full project is here: github.com/samuel-nartey/devops-labs

Navigate to Docker & Containers/Running Your First Container/running docker compose, run docker compose up --build, and play through it yourself. Then open docker-compose.yml and start experimenting. The experiments in the README are genuinely worth doing — even when (especially when) they don't produce the failure you expected.

Docker clicked for me when I stopped reading about it and started running something real. This project is exactly that.

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.