Before You docker build: 7 Supply-Chain Checks for Third-Party Repos

You cloned a repo, read the README, and your fingers are already typing docker compose up . Stop. A third-party repository is untrusted input - and the build/run pipeline executes it. Most "it's just a demo repo" incidents I've audited started with a skipped two-minute review. Here are seven checks, in the order that catches the most problems first. None takes more than a few minutes. 1. Read the Dockerfile line by line - especially RUN The Dockerfile is the attack surface. Anything in a RUN instruction executes on your builder (and often inside your runtime): RUN curl -s https://example.com/setup.sh | bash curl | bash in a build is running an unaudited remote script with the builder's privileges. Watch for: - remote scripts piped to a shell ( curl | sh ,wget -qO- | bash ); - downloads without checksum verification; - COPY --from= stages pulling from images you didn't expect; - ARG /ENV values that look like credentials or endpoints you didn't anticipate. If the repo generates its Dockerfile from templates or config (some frameworks do), audit the generator too - injection into generated Dockerfiles is a real vulnerability class, not a theoretical one. 2. Check what the base image actually is FROM python:latest latest means "whatever the registry serves today" - a moving target. Prefer pinned tags, better a digest: FROM python:3.12-slim@sha256:... Quick sanity: does the base image match the project's claimed stack? A "minimal Redis wrapper" building from a full Node monolith image deserves a second look. 3. Audit the compose ports and volumes services: db: ports: - "5432:5432" volumes: - /var/run/docker.sock:/var/run/docker.sock Two classic mistakes: - Publishing ports to 0.0.0.0 that the README says are "internal". Bind to localhost (127.0.0.1:5432:5432 ) unless you truly need exposure. - Mounting the Docker socket into a container. That hands the container root-equivalent control of your host. If a demo needs it, run it on a throwaway VM - not your workstation. Also scan volume mounts for sensitive host paths (~/.ssh , ~/.aws , /etc ). 4. Look at the CI workflows before you trust the badges .github/workflows/.yml run in the project's CI, but a malicious or sloppy workflow can also be a clue about the project's security culture: - actions pinned by hash ( actions/checkout@ ) vs floating tags (@v4 ); - workflows that post secrets to external endpoints; - pull_request_target workflows running untrusted code with write tokens. And remember: green badges prove tests pass, not that the code is safe. 5. Grep the repo for secrets and surprises Sixty seconds that pay for themselves: # obvious secret patterns grep -rnE "(api[_-]?key|secret|token|password)\s[:=]\s*['"][A-Za-z0-9_/+=-]{12,}" . --include='' | grep -v test # remote-exec patterns grep -rnE "curl[^|]|\s*(bash|sh)|wget[^|]|\s(bash|sh)" . # docker socket references grep -rn "docker.sock" . A committed production key is a red flag about the maintainers; a postinstall script that phones home is a red flag about the software. 6. Pin and review dependencies you'll actually run For images you'll run locally: docker compose config # what will actually run, with variables resolved For package manifests, glance at the install hooks - postinstall /prepare scripts execute on install: grep -A3 '"scripts"' package.json | grep -E 'postinstall|prepare|preinstall' You don't need a full dependency audit for a weekend experiment. You need to know whether installing it runs code you haven't seen. 7. Run it like it's hostile Last line of defense - isolation: - run unfamiliar stacks on a VM or a dedicated machine, not your daily driver; - use a separate browser profile/network for any UI it exposes; - don't paste real credentials into a demo you haven't reviewed; - keep the container runtime updated; consider --read-only filesystems and dropped capabilities for anything long-lived. The two-minute habit You won't do all seven every time. But checks 1, 3 and 5 catch the majority of real problems, and together they take about two minutes. Treat every third-party repo the way you treat a binary download from 2005: it doesn't get to run on your machine until you've decided it's allowed to. What's the first thing you check in an unfamiliar repo? I'm collecting war stories - share yours in the comments. Top comments (0)